(Continued from previous message)


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

BL> Who gives a stuff? What is the point of excluding a tear
BL> line and origin line if we have to put them back in again?

They have information that some message processing systems may
CHOOSE to use. Like for example an elegant automated netmail
reply system like Rod has put in his QWK reader. IT needs to
be able to find a node number etc in the Origin.

Even a fancy system where the user could just pop up a status
screen which uses the number in the origin line to lookup the
nodelist details and display those on request would need it.

BL> The only advantage I can see is that if we were then able to enter
BL> graphics in the message area - but EOT doesn't let us do that.

There is a hell of a lot more to message formats so you can have
an elegant totality of message capability for those that want to
implement it than just graphics in user fields Bob. The ease with
which they can be implemented depends on having a relatively robust
message format. The SOT/EOT adds some robustness to the current
design. It really is that simple.

Not that YOU are ever likely to be able to see it |-)

BL> Paul's argument that SOT/EOT makes it easier falls in a heap when
BL> it may bot be there, and offers no advantage ever the existing
BL> system in the case of SOT and a positive handicap with EOT!

Thats quite wrong too if the alg is done properly. If for example
you use the EOT as totally unambiguous flag to stop scanning back
thru user text, and its missing, you will eventually hit the SOT
and know damned well its a fucked message. Ditto for the reverse,
a message with a missing SOT, you initially assume its a message
with no SOT or EOT, you find an EOT when back scanning up from
the end of the message, its GOT to be a fucked message too.

BL> If a mailer has a problem identifying "SEENBY" correctly,
BL> then rewrite the mailer or use a different one!

The point you are missing totally is that there are some situations
where NO alg can handle, a false SEENBY in user text. NO alg really
knows if its false or not. If its got an EOT after it, its totally
certain that its a false one, in fact you wouldnt even notice it
since you STOP scanning back at the EOT.

BL> The only time to change the system is when it is
BL> *impossible* to correctly identify the correct
BL> "SEENBY" or the correct "AREA" at the top.

And thats reality NOW, you can indeed get false control stuff in normal
user text and the SOT/EOT utterly umambiguously protects against that.

BL> I don't mind ^aSOT so much. It's harmless because
BL> there is no need to change the mailer code,

Precisely the same thing can be said about EOT too. Must be, all our
mail gets out with them being included. Cant get more harmless than that.

BL> and it does offer an advantage if you process mail the way Paul
BL> does, by reading the address in the header first, and if the
BL> address is not yours, passing it on without reading the "AREA:"
BL> line at the top of the message to see if the "AREA:" is valid.

And the same is true of EOT, if a system chooses to use it to
totally unambiguously delimit the end of user text, fine, if
it chooses to ignore it, that will work precisely the same as
if no EOT was there at all too. BUT it allows extra capability,
totally unambiguously deciding on what is false trailing header
text in user text if the code author chooses to use it.

THATs where you are repeatedly brainfarting.

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

BL> I can do that...

Yes. And thats the whole point.

BL> if I know they are there, but what about existing mailers?

The whole point of kludge lines is that if you understand what
a particular one is there for, you can use what its there for.
If you dont, you can ignore it with impunity. For example the
MSGID, it doesnt matter a stuff what its used for a mailer can
just ignore it totally. Thats the whole point of that technique
for providing an expansion capability in a format.

BL> That takes care of ^aSOT with the other ^a lines at the top
BL> of the message, but what about ^aEOT at the foot of the message?

Makes no difference at all, it can just be ignored if you dont
understand it. It must work, the mail still gets thru now that
its in use. QED, its an expansion technique which gives total
backward compat. Thats the whole point of it.

BL> If I drop ^a kludges I will lose "^aPATH:" that I may find
of interest.
BL> If I read my message by finding the origin line, ^aEOT will be inside
BL> that, and shown on the screen unless I change my algorithm. Do you like
BL> looking at the little red EOT's? They drive me to distraction! The only
BL> way to get rid of EOT is to drop *all* ^a kludges.

Basically the traditional solution is to either make the kludge lines
visible to the user or not, as he prefers. The better systems allow
that behaviour to be toggled. By definition kludge lines can ALWAYS
be dropped before user text is shown to the user. Thats the whole point
of them, the ^A flags that they are control stuff, not usually of any
interest to the user and safe to drop before its shown to the user.

Thats SAFE, which is a different issue to whether the user may like
to see them at times. Which is why its toggleable in a decent reader.

BL> Personally, I find "PATH:" of interest.

Yes, I do too, and I dont care for the SEENBYS. I like to see the
stuff like product codes etc too myself. No reason why a decent
reader cant allow you to list the ones you want to have displayed
and/or the ones you want to never see and the what to do about ones
which arent in either list.

And like I said, the growth over time has fucked the format quite
a bit coz strictly speaking the origin and tearlines and stuff like
that should ALL have a consistent 'this is control stuff' flag of a
proper kludge line instead of being pseudo user text. Too late for
that now tho.

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.

RS> You can right now.

BL> How?

The most obvious is the various ways of UUCODING etc. You can
file attach to a message too, but obviously not in echomail.

RS> And you go on about a completely fresh design. Thats utterly

(Continued to next message)

--- PQWK202