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. 

BL>   I assumed that because the FTS-0001 fields are variable strings with
BL> a maximum size, that mail processors would not bother checking
BL> lengths. 

You have to check them all to be able to decide that, including
ones where the author died 5 years ago.  Unless you're planning
on forcing those people out of fidonet if they don't switch
software, because there is no other technical way to achieve what
you are trying to achieve.

BL> If I am wrong, then my idea sucks and can't work.

Your idea sucks and can't work.  Basically, there are a lot
of things you can do when programming on the offchance that
you don't find a NUL when you expect one.  One is to print
out a message and say "packet is corrupt", one is to abend,
one is to pass it through OK, and store it truncated in your
*.MSG, Squish file etc.  Another is to store it truncated, and
then export it (this used to be the most common way of doing
mailprocessing).  You have to check ALL the mailprocessors in
use in fidonet, including ones on the Amiga, etc etc.  We
don't manage revolutions in fidonet very well.

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. 

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

You can add a new kludge, such as "LONGSUBJECT" any time you want,
and mailprocessors will pass it through without complaint.  That's
how we make changes in fidonet, via kludge lines.  Haven't you
noticed all the kludges (SOT/EOT for example).  Not documented in
FTS-1.

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?

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

So long as the control lines don't exceed 256 characters, right?
And so this is an attempt to get control characters such as x'01'
to be used in the text area?  ROFL!  And what are you going to
do about x'00'?  You have to come up with a NEW format if you 
want to do something like that, and there are PLENTY of those
around, take a look at them in the FSC's.  However, if you want
something to worth within the existing FTS-0001 framework, you
need to come up with a different solution.  One such solution is
UUENCODE.  You could have a control line called GIF that 
automatically signals to message readers (or whatever) that they
should auto-convert it into a picture, or whatever.  These
solutions already exist, I think it's called "MIME", but don't
quote me on that, because I don't care.

BFN.  Paul.
@EOT:

---