Hi Bob, I'll answer your main commentary later.

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

PE> That is not existing protocol.

BL>   But it would still be compatible. When you change a protocol, it has

No it isn't.  Any PKT processor that has been written with the
length 72 for subject in mind, and prints out "corrupt packet"
and terminates if their buffer is overflowed, or defines a 72
byte buffer, and then says "read from file until NUL", and then
gets their buffer overflowed, and starts corrupting surrounding
variables, will be broken.  You have no idea what that will
cause to happen.

BL> to be compatible because there is a period of overlap. We probably

This "period of overlap" is something to do with introducing
a new standard.  There are many proposals for new standards
already, I am not attempting to add one.

BL> need a bigger string for To, From for the Internet, and the Sbj string
BL> with its no restrictions (except NUL) opens up a whole raft of
BL> enhancements for the future. You could put control lines in there, for
BL> instance.

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

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.

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

In other words you want to break existing implementations.  No,
that is not what I am trying to do.  And it's totally ridiculous
anyway.  The internet will send 2 meg messages when they have
something big to post, and there is no reason we should have a
restriction on message length either.

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.

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

You're the one who wants to remove the 72 character restriction,
not replacing it with another number, which thus makes it 
infinite.

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.

BL>   No you did *not* define freq in the subject string. You need to...

Do a search on "0800" and then apologize.  :-)

BL> and why not the .req file too? Isn't that part of the protocol?

No it isn't.  The .PKT standard is documenting the .PKT file, not
documenting the .REQ file.

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

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

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

The ANSI C standard had a "rationale" that came with the standard,
but the official document is only the first bit.  Everything IS
spelt out in the official document, the rationale is more of a
tutorial.

BFN.  Paul.
@EOT:

---