RS> The SOT and EOT allows you to know totally unambiguously that
RS> they are real origin lines etc, coz that are absolutely certain
RS> to be user text coz they are inside the SOT EOT pair. THATs the
RS> whole point of them.

BL> I've been through this with Paul so many times I'm getting sick of it.

How do you think WE feel with such graphic evidence of you brain farting
away like mad ? |-)

You're just doing your usual, playing silly buggers and purporting to
believe what you dont even believe when you say it. A complete wank.

BL> The *last* origin line is the real one.

STILL missing the point utterly. The SOT EOT is MUCH easier to use
as the borders of the user text that that sort of farting around.
BUT there is a problem when hardly anyone uses SOT EOT. SO you have
to write the code without relying on them UNTIL they are widely used.

I've deleted you repetition of you utterly missing the point on all
the rest. NO ONE is saying that PKTs CANT be processed with the
deficient design, JUST that the addition of SOT and EOT is much
BETTER, because it absolutely unambiguously delimits user text.

BL> I don't really object to adding a SOT, because it doesn't do anything,

Thats crap.

BL> but the EOT actually interfers with the Origin line that *has*
BL> to be shown in the message field.

And so is that. Like I said, there is absolutely NO reason why NOW,
you cant just process the PKT the way you would do if SOT and EOT
did not exist at all. Just drop them as unknown kludges lines. That
has ABSOLUTELY NO penalty.

BL> Faced by Paul's EOTs in his packets, the first thing I do it erase
BL> them!

Yes, and I have said over and over again, while hardly anyone is using
them, that is indeed the most productive approach. BUT that says nothing
useful at all about whether the detection of what is user text is much
easier if most messages use them.

BL> I agree that we need a protected message area, but only because
BL> I look forward to the time when we transmit graphics over the BBS.

You can right now.

And you go on about a completely fresh design. Thats utterly pointless
Bob, we are talking about whats a viable improvement to the current
extensible design. And if we are going to contemplate a completely
fresh design, we need to FIRST decide why we cant use one of the
CURRENT completely fresh designs like X.400

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

BL> Ahh... that's a different question. The problem with PKT
BL> format is that the message header does not allow room for:

BL>   Area identification
BL>   Netmail identification
BL>   Origin and destination Zone
BL>   Origin and destination Point
BL>   SEENBY
BL>   PATH

More accurately the current PKT design does not have a rigid separation
between the header data and the user text, some of the stuff is outside
the true header, some with its own weird flagging that its header data
like the origin line, some much more standardised like the kludge lines.

Yes, it would have been better if ALL the stuff which isnt in the true
header was much more rigidly flagged and much more consistently too.
BUT its too late for that now.

BL> All this should go in the header, with room for expansion.

You are now just sitting down and redesigning PKT how you think it
should have been done in the first place, a different matter entirely.
AND if you are going to do that now you have to FIRST show why one of
the current standards for messages like X.400 cant be used before you
go inventing a whole new one all over again.

BL> It is interesting to compare it to the 128-byte QWK fixed
BL> headers padded by spaces. When you zip QWK, it ends up smaller
BL> than a zipped PKT because the spaces compress to nothing.

Thats mostly got nothing to do with the format of the header,
its mostly just that quite a bit is dropped from the PKT to
get the QWK, particularly the PATH and SEENBY stuff.

Yes, you can indeed get weird effects. Someone proposed a binary
format for nodelists for size reasons. Turns out that once you
archive it its marginally BIGGER than the text one archived.

BL> If we allowed a fixed 256-byte message header in PKT, padded
BL> by spaces, it would give tons for future change, and clear out
BL> the message field so that only message was in there.

Yes, its a possible approach, but its far far too late for that now.

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

BL> It has to show a benefit, or no one will use it.

In fact the movement to a new standard from an existing one with
no backward compat needs far far more than 'show a benefit' to get
people to shift.

BL> If we base a new standard around graphics,

You STILL have to consider why a CURRENT ONE cant be used like X.400 FIRST.

BL> then anyone using the ^a kludges in the massage field would be
BL> inmcompatible for graphics, but able to use text.

Even thats not right. If you have for example a size field which is
included in a ^A kludge line which precedes that block of graphics
data, there is no limit on what you can have in that graphics block
And its readily backward compat. A message reader which doesnt want
to bother to display the graphics chunk can just skip over it. You
can even use a format ID kludge to specify the format of whats in
that graphics block.

BL> This is the way changes should be made... like colour TV.
BL> It doesn't take long before everyone upgrades.

Thats crap Bob, software standards are nothing like that. You wont
be getting the whole of Fido adopting your new mail standard just
because you say 'hey you can include graphics in a message with this'
It doesnt work like that.

You want to contemplate whats done with READMEs etc. They are fucking
medieval linear text files. And its far far easier to move away from
that primitive approach with say shareware, its dead easy to include
a hypertext viewer or whatever in the archive. Getting a new mail
format adopted for Fido mail is far far more difficult when it affect
every single mail processor on ever single Fido node. You have fucking

(Continued to next message)

--- PQWK202