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

 Ro> If you used a field larger than 72 characters, you would
 Ro> overshoot the *static* size of the field in many messagebase
 Ro> formats. A good tosser would handle this elegantly, but don't
 Ro> expect others to be able to. The original message format used
 Ro> FTS-0001 *.MSG, which has static length fields. AFAIK most
 Ro> common messagebases (Hudson, JAM, Ezycom, Squish) also use a
 Ro> static size. 

  I assumed that because the FTS-0001 fields are variable strings with
a maximum size, that mail processors would not bother checking
lengths. If I am wrong, then my idea sucks and can't work.

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

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

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

  I put that badly. I meant that *fewer* tossers would be affected if
you just changed the length of the string. Adding a new control line
means that *all* of the existing tossers will have to be modified
to work. But if they all have a 36-byte limit anyway, then it won't
work.

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

  I agree. IMO, Fido needs to update to enable simple graphics. If we
assume that the world has gone Windows and is not coming back, then
the basically ascii/DOS Fido standard is already obsolescent. We need
a system that goes part of the way towards a Windows environment, but
does not increase mail costs too much... so that Fido remains as a
"free" system run by hobbyists.

  I am repelled by the idea of a commercial Internet.

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

 Ro> Who in their right mind would

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

  It would be a good place to put control lines, and leave the message
area free to use any ascii characters. 

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

  I think he is trying to write a replacement FTS-0001 standard that
incorporates all the changes now in other documents. You have to read
4 documents, at present, and they contradict each other a little.

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

  So do I. It's a dirty job, but someone has to do it.

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

---