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.

BL>   The "fields" are actually strings, and anyone who used a 72-byte
BL> buffer with no guaranteee that it wouldn't overflow deserves all he
BL> gets. 

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

BL> That could do *anything*. 

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

BL> Don't be dishonest, Paul.

Don't break existing programs, Bob.

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.

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

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

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.

Plenty of Type-3 proposals to do all this and more.  I'm documenting
a Type-2 proposal.

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

BL>   Yair... but that breaks the standard, doesn't it? 

No.  Try quoting something that says ^ARFC-SUBJECT is illegal.

BL> The standard has
BL> to grow, and hopefully with minimum change that affects the least
BL> mailers. that would affect *every* mailer.

Mailprocessor.  And RFC-SUBJECT doesn't affect ANY mailprocessor.
Just the same as the PID that you and I are both generating is
sent fine.

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.

BL>   I see Fido and the Internet coexisting. IMO, the kiddies will go
BL> play on the Internet, and serious mail will stay on Fido. I think we

Sure you haven't got that the wrong way around?

BL> have to put a limit on messages to stop a dickhead "doing an
Internet"
BL> with a 2Mb message that stuffs everything. As I said earlier, we ought

Stuffs what?  People have large file echos, why shouldn't 
messages be able to transport the info?  Message size restriction
should be done at the OPTION of the SYSOP, not have the standard
or the programs impose stupid limits.  What possible disadvantage
is there in letting the sysop decide the maximum length of 
message he will allow through, rather than the standard?

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.

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

You don't "must have a number", but failing to specify one makes
it infinite instead.  Your 256 is just as arbitrary as 72.  The
difference is that the 72-character one is already with us.  Even
if you did upgrade every single mailprocessor to make sure there
was no problem with the >72 characters, you then run into another
problem.  Some sysops store their messages by going from PKT to
*.MSG and then *.MSG to PKT.  *.MSG (see FTS-1 for specs) has
those 72-character subject limitations built into the format.
You would then make the sysops doing this suddenly violate the
specs too.

Anyhow, upgrading the spec is not what I am attempting to do.  I
am just trying to define it, so that developers don't need to
guess.

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

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

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

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

BL> totally obscure in your "standard.". The original FTS-0001
is better,
BL> but it was one of the things that needed clearing up. You didn't do
BL> it. 

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

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

I thought I was as definite as I could be under the circumstance.

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 space
BL> is inserted.   can be either one of  or
.  The
BL> use of  for  is an obsolescent
feature that may
BL> 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 anything.

Existing practice DOES have  in some messages.  There
just aren't very many of them, which is why I say that it is
an obsolescent feature.  The ISO C standard does the same thing,
it has comments about "Future Language Directions".  FREQ
ANSI_C.* from 3:711/934 and take a look.  *THAT* is my idea of
a decent standard.  Absolutely beautiful.  If I could do as good
a job as them, I would be EXTREMELY happy.  That is one thing I
have not been able to fault (unless you count 3 "bugs" that I
found in the ISO version).

BL> If it can be two ways, say so! Don't apologise. In writing a standard,
BL> you have to think of yourself as god, like this:

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

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

I can see your point, that is far more concise.  I will look at
doing that.

BL>   You did a similar thing with your ^a fiasco, calling the majority
BL> "exceptions to the rule". Standards don't have exceptions.
You say it,
BL> and it is so.

BL>   Don't say the "very first" character when you mean the first
BL> character; it only weakens it. Don't talk about "lines" in one
BL> paragraph and doing away with  in another paragraph. A standard
BL> has to be consistent, right through.

Ok, I'll try again.

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.

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

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.

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

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

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

BL> 1. SCOPE

BL> 1.1 Scope  This standard defines Fido pkt format

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

Ok, sounds good.

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

Ok, I'll try again.  BFN.  Paul.
@EOT:

---