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. 

 PE> No he doesn't. His program is designed to process FTS-1
 PE> packets, and it does.

  Are you saying that it's okay to lock the computer if he gets 73
bytes? Strange idea of programming. You have no concept of failsafe.

 PE> Only if you are sending it crap. Lots of programs abend if you
 PE> send them crap. An earlier version of Tobruk abended if you
 PE> sent it more than 2000 characters of control information. I had
 PE> no protection against more than that.

  No wonder our submarines keep running into wharves.

 PE> You don't agree that I shouldn't be creating a new standard, or
 PE> you don't agree that I am creating a new standard by doing
 PE> something different with greater latitude than FTS-1?

  I don't agree with you at all. I don't even like Hitler.

  I do agree that FTS-0001 needs to be rewritten to tie it together, 
rather than to exist in bits and pieces, none of which are compulsory. 
We need a standard.

 BL> You did not explain how the Subject is used to send a Freq.

 PE> 0x0800 - subject specifies name of file to file-request

 PE> That's all there is to a FREQ as far as the PKT format is
 PE> concerned.

  Not so. How long are the file names? What about multiple files? The
existing FTS-0001 specifies that the filenames may not have the three
separator characters defined. You define nothing. I much prefer the
existing words in FTS-0001. You are supposed to be improving it, not
making it more obscure.

 PE> The original FTS-1 also has the communications side defined, ie
 PE> the FTS-1 negotiation done by MAILERS. I have not documented
 PE> that protocol AT ALL. That is another problem, and one that I
 PE> may document when I come to write a mailer.

  I agree with your leaving that out, but the Subject field is
clearly part of the PKT format and *must* be defined.

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

 BL> This is dreadful! You can't be argumentative or uncertain in a
 BL> standard, or the bloke reading it things he is free to try
 BL> anything.

 PE> Existing practice DOES have  in some messages. There
 PE> just aren't very many of them, which is why I say that it is an
 PE> obsolescent feature.

  You don't make those comments part of the standard. If you must make
comments, use notes, or an interpretation. In most cases, the notes
and the interpretations are the best part of standards.

 PE> The ISO C standard does the same thing, it has comments about
 PE> "Future Language Directions". FREQ ANSI_C.* from 3:711/934 and
 PE> take a look. *THAT* is my idea of a decent standard. Absolutely
 PE> beautiful.

 PE> If I could do as good a job as them, I would be EXTREMELY
 PE> happy. That is one thing I have not been able to fault (unless
 PE> you count 3 "bugs" that I found in the ISO version).

  I agree. A well written standard is a joy.

 PE> The C standard has footnotes, which are usually
 PE> interpretations, and future library directions, and a
 PE> rationale.

  Great! There is a trap in this however. You have to be incredibly
careful not to contradict the actual standard. I've always thought it
would be better for *one* person to write the standard. They are
usually written in committee, and they sort-of wander a bit.

 PE> Even the footnotes are not part of the standard proper (they
 PE> say so at the front, in the ISO and ANSI standards, they missed
 PE> that bit out of the Australian Standard).

  Quite right. I only found that out myself, recently. Notes are not
binding, either as footnotes or in the body of the text itself.

 PE> Ok, I'll try again. BFN. Paul.

  I think it's worth it. It'd be really nice to have a cast-iron and
clear standard for pkt format.

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---