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.

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

Not as drasticly as changing the length of a fixed length field (or the
layout of a bitfield)...

 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. 

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

 PE> Well, I have to be compatible with existing systems. The
 PE> trouble is how to define what existing systems do.

 BL> I was discussing your use of language. For instance....

 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 ."

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

 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.

They are not the *majority* of kludge lines. They are the old ones that
predate the ^A flag, and they can't be defined away. However because they
are found in (almost) every message, they take pride of place in the
standard :-(
   
 BL> 2.2 Byte  Four paragraphs defining what everyone already 
 BL> knows. 

 BL> This formal layout helps when the standard is modified, oir 
 BL> when you write your "interpretations" or tutorial.

Yeah, it is one of the things the FidoTech standards need. Bloody awful
things some of them. However others (like Avatar) are very well done.

...Alex.
(Pagan & Proud)

---