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

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

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

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

  I know, but I just don't agree with you. It's not compulsory to
agree with you.

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

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

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

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

  I see Fido and the Internet coexisting. IMO, the kiddies will go
play on the Internet, and serious mail will stay on Fido. I think we
have to put a limit on messages to stop a dickhead "doing an Internet"
with a 2Mb message that stuffs everything. As I said earlier, we ought
to be looking at a way to send simple graphics, but inside a 12-30K
limit.

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

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

  Make the limit 256 bytes, if you must have a number.

 BL> No you did *not* define freq in the subject string. You need
                                  ^^^^^^^^^^^^^^^^^^^^^ 
 PE> Do a search on "0800" and then apologize. :-)

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

  As for the apology... get fucked. I spent time trying to improve
what I actually thought was a good idea, and you, you pathetically
silly prick, are trying to win points. You don't have to agree with
what I am saying, but the least you could do is *read* it properly.

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

  Fair enough.

 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.
 BL> My main criticism is that you are too argumentative. A standard
 BL> should be like the word of god - definite: Thou shalt...

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

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

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

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

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

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

  You did a similar thing with your ^a fiasco, calling the majority
"exceptions to the rule". Standards don't have exceptions. You say it,
and it is so.
  
  Don't say the "very first" character when you mean the first
character; it only weakens it. Don't talk about "lines" in one
paragraph and doing away with  in another paragraph. A standard
has to be consistent, right through.

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

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

  That's right. A standard is meant to be read just the way it is
written. Only the notes are not legally binding. The "interpretations"
are a guide, as you say.

  My other criticism was the layout (that I didn't improve much, btw).
It is usual to have sections numbered, such as...

1. SCOPE

1.1 Scope  This standard defines Fido pkt format

1.2 Application  This standard applies to all mailers operating Fido
(or whatever, etc).

2. DEFINITIONS

  For the purpose of this standard, the following definitions apply:

2.1 Dickhead   Paul Edwards shall be the standard dickhead, measured
by asking him random questions not exceeding ten words in length. His
reply shall be known as the standard dickhead's response to simple
questions.

2.2 Byte  Four paragraphs defining what everyone already knows. 

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

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

---