BL> I think your FTS-0501 is a great idea. It's about time someone
 BL> put it all together, but I would make a few extra changes:

 PE> The document describes a CURRENT protocol, it does not attempt
 PE> to create a new one.

  I realised that.

 BL> 1. Remove the length restrictions on the To, From, Sbj strings.

 PE> That is not existing protocol.

  But it would still be compatible. When you change a protocol, it has
to be compatible because there is a period of overlap. We probably
need a bigger string for To, From for the Internet, and the Sbj string
with its no restrictions (except NUL) opens up a whole raft of
enhancements for the future. You could put control lines in there, for
instance.

 BL> 2. Restrict the length of the message text (12-30Kb).

 PE> That is not existing protocol either, there are mailprocessors
 PE> that do a lot more than this, and should do too.

  Again, it is compatible if we limit messages to 12-30K (pick a
number). In the beginning, those who did not conform *may* have the
back end put in another message... or not.

 PE> Not to mention it is completely bizaare that you want to make the
 PE> "subject" go from 72 characters to infinity, but reduce the
 PE> message text down to just 12k.

  What would be the point of an infinite Subject line? Why limit
something no one will ever use?

 BL> 3. Define characters allowed in message text (all but control
 BL> codes).

 PE> True, this one should be defined, one way or the other, whether
 PE> control characters are allowed.

  Yes. The existing FTS-0001 ignores it, and assumes no 0x00 or 0x01.
I agree we ought to exclude control codes, but what about hi-ascii? I
think it's just as important to allow that. Either that, or specify
6 bits 32-128.

 BL> Also, you forgot to define FREQ, either in Sbj string or as
 BL> separate file.

 PE> I did define FREQ, in the subject string. The "separate file"
 PE> is not a PKT, but a .REQ file. I am only documenting the
 PE> former.

  No you did *not* define freq in the subject string. You need to...
and why not the .req file too? Isn't that part of the protocol?

 BL> There are comments I have on the language and layout, but that
 BL> will take more time. I'll post a revised document tomorrow for
 BL> comment.

 PE> I look forward to it! I am interested in seeing how it can be
 PE> better structured. BFN. Paul.

  I think I've probably stuffed it up. There's too much writing and
not enough pictures. Standards are boring enough as it is. Maybe you
could do those little drawings in the original standard, with the
wordy-description following. 

  I agree with your concept of pulling the standard together. I
liked you idea of the control lines spelled out in one place. My main
criticism is that you are too argumentative. A standard should be like
the word of god - definite: Thou shalt...

  Perhaps you could do it in two parts: the "thou shalt" part and then
an addendum like the "interpretations" they publish separately from an
actual standards document.

  And what you really need to check your language, is someone who has
never studied it to read it, and see how much of it they understand
first time.

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

---