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.

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

BL> If you want to define "message body" that way, it is *already*
BL> delimited by nulls, front and back.

Nope, particularly at the start.

BL> Paul's SOT and EOT don't change that, since they are inside the nulls.

Nope, particularly quite different at the end of the user text.
You dont have to fart around backup up from the other end.

BL> Paul's SOT and EOT merely bracket the text... that once the ^a
BL> lines are removed, is already bracketed by the first null or
BL> AREA line at the top, and the Origin line at the bottom.

Thats missing the point severely. The whole point of the SOT and EOT
is to make it easy for the code to work out the boundarys of the user
text without all the farting around of backup up from what appears to
be end the market, and deleting the kludge lines etc. Obviously you
can do it the crude way, thats obviously what is being done now. The
whole point of the SOT and EOT is to make it much easier to do and
to allow for the stuff like origin lines in user text which have got
there on a forward or a quote etc. Ditto stuff like SEENBYS. The SOT
and EOT allows you to know totally unambiguously that they are real
origin lines etc, coz that are absolutely certain to be user text
coz they are inside the SOT EOT pair. THATs the whole point of them.

BL> The SOT does nothing, as there is nothing but AREA: and other
BL> ^a lines in front of it, and the EOT excludes the tear line
BL> and origin line that have to be added to the message anyway.

Using that theory there is no point in SOT and EOT at all and
thats crap. There is some problem with it being introduced now,
but its quite silly for example to suggest that it gives no
benefit if it had been say part of the original design.

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
RS> text stops and where the rest of the crap in the message starts.

BL> This is wrong. The unique string is AREA (or the delimiter
BL> null if not found) at the start, and " * Origin" at the bottom.

Thats not user text.

BL> The only difference with Paul's proposal is that he adds
BL> another ^a line to the others that may or may not be there.
BL> If you have to assume that it may not be there, then whatever
BL> you write as a fallback serves just as well.

You are completely mangling the question of the value of that
approach with what you have to do if its added later, when no
one is currently using it.

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

THATs just talking about whether its feasible for the code to work
with the original design. Of course it is, people have been using
it. Says nothing useful at all about whether the SOT EOT is an
improvement on that tho.

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

Nope, an origin line in user text does indeed break some mail
processors and the unambiguous delimiting of user text with SOT and
EOT allows you to know very easily that its just a quoted origin line.

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

BL> You're kidding! Add kludges in the message field? Wot rot!

They arent in the user text, they precede and terminate it.
And they explicitly forbid any other kludge lines between then.

BL> I would set up a fixed header with spare fields for expansion,
BL> and that's it!

That approach doesnt work because it inevitably breaks when you
have exhausted that fixed header. Thats precisely the problem
with the current QWK format, its fixed, its not readily expandable.
If you want to enhance it you have to get more of an abortion with
new files in the QWK archive.

BL> The necessary origin line would be constructed from one of
BL> the header fields,

Thats got some advantages for the fixed fields in it, the node
details, but doesnt help with the rest.

AND your idea isnt readily usable in tandem with the current system
anyway. Yes, its possible to design a whole new message format from
scratch, but we arent looking at one of those and how to do it, we
are actually looking at something which can enhance and be used with
the current one. Coz a whole new one from scratch has buckleys of
ever getting everyone switching to it. And if you are going to make
a complete step away from the current one, you first have to show
that one of the true standards like X.400 isnt usable. No point in
generating a whole new one if it is.

BL> and added on at the bottom of the message, along with anything
BL> else that the user wanted to see. He could write anything he
BL> liked in that message field, including 0x00, 0x01, and graphics.

Thats a different question. There is some argument for say having the
SOT have a length field which specifys the length of the following user
text, then the user text can be literally anything you like. But then
presumably you also need a new field so the format of the user text can
be specified too, so you know its say an ACAD diagram without having to
fart around trying to analyse it to work out what it is. Thats a whole
nother step again tho and it makes a lot more sense with that stuff to
use what is used with say the fancy file formats which specify what the
file actually is content wise like that.

BL> It's interesting that QWK does it that way

Yes, and is almost completely unexpandable except in even cruder
ways of just including other files in the QWK archive with no
information about them at all in the main data file.

BL> (unfortunately without the null delimiters), and pads with spaces.

Its just one of those universals of computing, you can either delimit
or you can specify the size or you can have a fixed size and pad.

BL> When the QWK messages are written, they are 10% larger than the
BL> packet messages, but when the QWK packet is compressed, it turns
BL> out 7% smaller than the original packet archives! All the spaces
BL> compress very well.


(Continued to next message)

--- PQWK202