BL> The "fields" are actually strings, and anyone who used a 
BL> 72-byte buffer with no guaranteee that it wouldn't overflow 
BL> deserves all he gets. That could do *anything*. Don't be 
BL> dishonest, Paul.

AWL> They are not strings. They are 72 byte fields. Such things were common in 
AWL> the long ago. Back when a serious commercial machine had a 24k TPA, and my 
AWL> *serious* developers desktop machine had a 50K TPA (and dual processors, 
AWL> one for IO), allocating mucking huge buffers like 128 bytes was something 
AWL> you avoided where you could. Besides, fixed length fields are the norm in 
AWL> most older languages, as were fixed length records.

PE> You can put control lines in the body, and in fact, some 
PE> people do exactly that for the internet, having 
PE> RFC-SUBJECT: .

BL> Yair... but that breaks the standard, doesn't it? The 
BL> standard has to grow, and hopefully with minimum change that 
BL> affects the least mailers. that would affect *every* 
BL> mailer.

AWL> Not as drasticly as 

It doesn't

The answer is "No".

AWL> changing the length of a fixed length field (or the 
AWL> layout of a bitfield)...

The From/to/subject are not fixed length fields in the PKT format.  
They do have a maximum length though.

BL> You did not explain how the Subject is used to send a Freq. 
BL> It is totally obscure in your "standard.". The original 
BL> FTS-0001 is better, but it was one of the things that needed 
BL> clearing up. You didn't do it. 

AWL> Most Freqs are nothing to do with the subject line. That is a 
AWL> Tosser/Mailer function. Most FidoTech File REQuests are sent as a text 
AWL> file. I'm not sure what would happen on most sytems if you sent a message 
AWL> with a file request flag set...

I think FTS-1 mailers will acknowledge it.

BL> "It is highly recommended that if data follows the
BL> keyword, a leading space is inserted, otherwise no leading 
BL> space is inserted.   can be either one of  or 
BL> .  The
BL> use of  for  is an obsolescent feature 
BL> that may be removed in a future version of this document."

BL> This is dreadful! You can't be argumentative or uncertain 
BL> in a standard, or the bloke reading it things he is free to 
BL> try anything. If it can be two ways, say so! Don't 
BL> apologise. In writing a standard, you have to think of 
BL> yourself as god, like this:

BL> "There may be a space before data, or not. Newline can be 
BL>  or ."

AWL> But that means that a person reading it may assume it is OK to not put in 
AWL> a space, and that  is OK. Both are used but are
being discouraged. 
AWL> The standard has to both define what you should send, and what you can 
AWL> expect to recieve.

Yeah.

BL> That is all your paragraph says, and it is clearer, 
BL> shorter. If you must explain, do it in a separate note.

BL> You did a similar thing with your ^a fiasco, calling the 
BL> majority "exceptions to the rule". Standards don't have 
BL> exceptions. You say it, and it is so.

AWL> They are not the *majority* of kludge lines. They are the old ones that 
AWL> predate the ^A flag, and they can't be defined away. However because they 
AWL> are found in (almost) every message, they take pride of place in the 
AWL> standard :-(

Yeah, I haven't got down to answering the detailed one yet, but
that is my sentiments.  I fail to see that documenting exceptions
to the normal format is a crime.  BFN.  Paul.
@EOT:

---