BL> BTW, how do you know where to add your EOT? Read the
BL> Tear line, do you? If that's the case, what's it doing
BL> that the Tear line doesn't do? Your EOT logic is loony.

FM> Actually, that's a very good point. If an automated
FM> process can determine where to place a SOT/EOT pair,
FM> then by trivial proof a SOT/EOT pair ain't necessary.

RS> You've had a brain fart. That doesnt apply to what is CREATING the
RS> message, say taking what an external editor hands it as user text,
RS> bracketing that with the SOT/EOT pair, and THEN doing whatever it chooses
RS> to with control info outside the block of user text its not concerned with.

RS> Its just as true if its got an internal editor too.

FM> Yeah, I appreciate that. If you're the original creator
FM> of the message you know where to stuff the SOT/EOT.

RS> And THATS what the SOT/EOT is about, the original creator
RS> of the message. Avoiding producing a message which can
RS> cause problems with stuff like embedded origin lines etc.

FM> Yes, I know that. But...

FM> But Paul is presumably doing so, by an automated
FM> process (I don't *think* he's personally inside my
FM> computer) in QWK2PKT, and Bob in whatever he's doing.

RS> And THATS where you are having your brain fart, thats NOT what the
RS> SOT/EOT is primarily designed to be used, so the fact that its got
RS> some blemishes in THAT situation says nothing useful whatever about
RS> whether its useful for the original creator of the message.

FM> ... I know that's the original intention. My point is, IF
FM> (and I don't know) it is possible for a subsequent program
FM> to determine where to put those, then they aren't necessary.

You havent established that thats actually true in the worst case
where the message does not have a perfect end of message detail,
and its also got some of that stuff embedded in the message body
coz the user has inserted another message in the message body etc.
Or something that looks like it like the --- line start.

And you STILL havent established that even it it IS always
possible to do it with an automated process, and it isnt, that
it isnt a very considerable improvement to make it EASIER to work
out where the message body is by bracketing it with the SOT/EOT pair.

In the simplest case where the SOT/EOT pair is in all messages, that
saves all mail processing code having to fart around working out what
the message body is by the more complex alg, even if its possible.

RS> So your 'isnt necessary' has imploded.

FM> Do I make it clearer in the above?

You are still having a brain fart IMO.

FM> And of course it maybe easier coming from QWK, if it doesn't have
FM> kludge lines anyway. But hang on, I get the opinion from your current
FM> discussion with Paul on this that it's not the ^a kludge lines which
FM> are the problem, it's the 'text' kludge lines (like ---) which are.
FM> And surely they're still a potential problem coming from QWK.

RS> Pity that if the SOT/EOT has some value with original creators of
RS> PKTs, your 'isnt necessary' has imploded tho. Its not about QWKs.

FM> I know that, it's about PKTs.

FM> SO. If it's possible for an automated process to do
FM> it, it ain't necessary. Except perhaps for efficiency.

RS> Pity that thats ONLY an automated QWK/PKT convertor Frank.

FM> Of course it is. Is it possible, in general,
FM> to scan a PKT and work out where to put SOT/EOT?

No, not with imperfect messages. Consider the --- line for example.
If the message doesnt have one, and there is one in the message body,
you are fucked. And even if you add more rules on how far it is away
from the origin line etc, its clearly still a lot simpler to just
look for the EOT to determine where the end of the message body is.

FM> If not why not, what stuffs you up from doing that?

Its considerably more messy than looking for a EOT atleast.
@EOT:

---