Answering msg from Bob Lawrence to Paul Edwards,
on Friday February 16 1996 at 08:11

 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. That could do *anything*. Don't be dishonest, Paul.

If you used a field larger than 72 characters, you would overshoot the
*static* size of the field in many messagebase formats. A good tosser would
handle this elegantly, but don't expect others to be able to.

The original message format used FTS-0001 *.MSG, which has static length
fields. AFAIK most common messagebases (Hudson, JAM, Ezycom, Squish) also
use a static size.

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

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

No it wouldn't. Your idea of over 35/72 characters would affect us all,
since names would be truncated, making routing of mail with older
mailers/tossers completely impossible.

 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
 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
 BL> to be looking at a way to send simple graphics, but inside a 12-30K
 BL> limit.

Policy and specifications are two entirely separate issues. What *you*
think is reasonable in *your* network may be entirely different in another.
What if a business chain wishes to utilise fidonet echomail technology to
send graphical images (uuencoded or MIMEd) to several of their franchises.
Oops, someone made a political decision designing the software, it's
useless for us, we'll have to use something else.

 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.

Who in their right mind would

  a) Have a subject line of 3 and a bit lines
  b) Be bothered to read it?

 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.

I'd see Paul's attempts as the rationale to FTS-0001 and many other
documents, rather than a standard. A document which complements, rather
than obsoletes, existing documents. This may or may not be what Paul is
trying to achieve.

Anyways just my $0.02 . . . I commend Paul on his efforts.

---