RS> Very simple really, the SOT and EOT bracket the message text
 RS> body. All the stuff outside that is header type stuff, even if
 RS> it trails.

 BL> The message is *already* bracketed by the compulsory "AREA:"
 BL> line and the "* Origin" origin line.

 RS> Nope, not the message body, the text the user enters.

  If you want to define "message body" that way, it is *already*
delimited by nulls, front and back. Paul's SOT and EOT don't change
that, since they are inside the nulls.

  Paul's SOT and EOT merely bracket the text... that once the ^a lines
are removed, is already bracketed by the first null or AREA line at
the top, and the Origin line at the bottom. The SOT does nothing, as
there is nothing but AREA: and other ^a lines in front of it, and the
EOT excludes the tear line and origin line that have to be added to
the message anyway.

 RS> The problem with the message format pre SOT and EOT is that
 RS> there is no one unique string that delimits where the user text
 RS> stops and where the rest of the crap in the message starts.

  This is wrong. The unique string is AREA (or the delimiter null if
not found) at the start, and " * Origin" at the bottom. The only 
difference with Paul's proposal is that he adds another ^a line to 
the others that may or may not be there. If you have to assume that 
it may not be there, then whatever you write as a fallback serves 
just as well.

  The AREA line (or null), and the * Origin line are added by the
mailer, so we can identify the text by looking for the null or AREA
to mark the beginning, and the last " * Origin" string to mark the
end. We have to throw out all the ^a lines anyway, so it's easier to
do it first.

  If someone writes "AREA:" on the first line, or " *
Origin" on the
last line, it hardly matters. The mailer will write another AREA: in
front, and another * Origin behind. All we have to do, is read the
first one, and the last one, and we get exactly the same result as SOT
and EOT. You are wrong.

 RS> Nope. Just consider the design of the message format as if it
 RS> was being done from scratch and everyone would start using the
 RS> new format.

  You're kidding! Add kludges in the message field? Wot rot! I would
set up a fixed header with spare fields for expansion, and that's it!
The necessary origin line would be constructed from one of the header
fields, and added on at the bottom of the message, along with anything
else that the user wanted to see. He could write anything he liked in
that message field, including 0x00, 0x01, and graphics.  

  It's interesting that QWK does it that way (unfortunately without
the null delimiters), and pads with spaces. When the QWK messages are
written, they are 10% larger than the packet messages, but when the
QWK packet is compressed, it turns out 7% smaller than the original
packet archives! All the spaces compress very well.

  I'd use the fixed 128-byte fields of QWK (less ndx), coupled to the
more clever non-ascii header of PKT.

 RS> The SOT EOT approach allows totally unambiguous delimiting of
 RS> user text which can be complete ignored when looking for header
 RS> data.

  Using the AREA line and the Origin line does exactly the same thing.
Write the code and you'll see. You end up with exactly the same code,
dupicated. Just eliminate SOT and it works the same; eliminate EOT
and it's better! That was what I finally did.

 RS> Even thats not right. You process thru the header detail at the
 RS> top, picking up what you want to use header details wise. You
 RS> hit the SOT, you just then keep skipping lines till you hit the
 RS> SOT and then you can look for more header details.

  That's what I mean by "reading right through." In my final program,
it takes 30mS to convert a message. 15mS of that is spent converting
the PKT cr's to Pi in QWK. 5mS is spent erasing SOT and EOT, or their
little ^a friends. The guts of it takes 10ms, writing ndx files and
all! In converting PKT to QWK, you use hardly any header detail; just
date/time, To, From, and subject. It breaks my heart to waste so much
time dodging kludges.

  What the point of converting the CR's to Pi, anyway? I'm tempted to
leave it out, and send the QWKs with embedded cr's.

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

---