BL> Why do you need an EOT to define the end of a message when you have
BL> a tear line and origin line *following* the EOT that are part of the
BL> message anyway! The tear line can define the end... or the origin line.

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

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

Nope, not the message body, the text the user enters. THATs what the
SOT and EOT do thats different, a completely rigorous and unambiguous
start and finish of the user text that any message processing software
can be quite sure contains nothing that it needs to analyse for header
detail wise.

The principle is fine, the problem is introducing that now when most
messages dont use them.

BL> SOT and EOT are also "header type stuff", so they don't change that,

That misses the point completely. The delimit the user text.

BL> and the EOT on the end actually interfers with the Origin
BL> line that *has* to be displayed in the message to give an
BL> address for netmail replies.

Not in the situation where SOT and EOT are routinely used it doesnt.
It in fact indicates where the user text finishes and the remainder
of the header type detail starts, the stuff thats physically at the
end of the message. The problem with the message format pre SOT and
EOT is that there is no one unique string that delimits where the
user text stops and where the rest of the crap in the message starts.

RS> If you choose to optimise the alg for the traditional PKT format, coz
RS> no one uses SOT and EOT, all you have to do is check for those AFTER
RS> you have identified the message body and drop them. Dead easy to do.

BL> Yes... but unnecessary!

Nope. Just consider the design of the message format as if it was
being done from scratch and everyone would start using the new format.
The EOT is indeed a much better way than the current way because it
provides a completely unambiguous end of the user text and the start
of stuff which a message processing system may need to analyse.

The only problem with SOT and EOT is that you cant mandate its use
universally on a particular date say.

BL> It simply adds to the processing time and gives nothing in return.

Nope, its much easier to have something which is guaranteed to be
the end of the user text. Anything else is farting around detecting
when the user text stops and when trailing header detail starts.
Particularly for stuff like forwarded messages which may well
have stuff like real origin lines in the user text.

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

BL> I have to read right through every message to find them.

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

The only problem is that SOT and EOT are not mandated so you have a
real problem when most mail doesnt have them. BUT, like I say, thats
easy enough, just process mail today without relying on them. If they
ever do become universal you can do it differently.

BL> In fact, I have decided to erase all the ^a lines in one go,
BL> but that only confirms how useless SOT and EOT are - if I
BL> actaully *want* to dump them without using them first.

You are silly completely confusing the question of whats appropriate
when hardly anyone uses SOT/EOT with whether the principle is useful.

BL> I identify the start of the actual message with "AREA:" knowing its
BL> spacing to the previous field as a double-check, and I identify the
BL> end of the text with the origin line, in order to protect the seenby
BL> line. It's a pity its proximity to the message null terminator is not
BL> defined - so there is no double-check, just a fallback if the Origin
BL> is missing, but EOT is no different. If I use EOT, I have to read the
BL> tear line and origin line as well, and add them to the message later.
BL> It's simpler to just wipe all the ^a lines in one go.

Sure, but thats all just talking about whats appropriate when SOT and
EOT arent used much in mail. I said before that you dont have any choice
but to just ignore them for now when almost everyone doesnt use them.

RS> You really dont have much choice while almost no one uses SOT and EOT.

BL> Only Paul...

BL> The tear line is no more than free advertising for the mail processor.

Yes, but its clearly not normal user text. Its essentially header stuff
which has been kludged on later.

BL> I'd like to see it removed,

Doesnt matter what you would like, the world clearly uses them.

Ditto for taglines. Many people think they are a waste of bandwidth.
Fact remains, heaps use them and THATs what matters.

BL> and the position of the origin line specified wrt the null terminator,
BL> so that the seenby becomes a protected, fixed-length de-facto footer.

And the reason its not very useful for that is because you have what is
clearly not normal user text above it. Thats the way the system has grown
over time and there is absolutely nothing you can do about that now.

--- PQWK202