Hi, Paul.

PE> PE> Where's the 80 bytes, Bob? What do we do if it goes like this:

PE> PE> tearline
PE> PE> fred nerk was here
PE> PE> Origin

PE> BL>   At last... something to answer.

PE> BL>   Reading backwards from Origin, the CR's (or CRLFs) are not
PE> BL> contiguous. If you find "CR--- " you know you have
a false one. The

PE> Pardon?

Yes, I have 2 problems with that. Surely the VERY FIRST thing you'll
find if you do that (in most cases) is the genuine tear line just before
the origin line, "CR---"!

The second thing is this "reading backwards". There's either something
more complicated about processing packets than I've yet realised, or I'm
missing the point in some other way.

PE> BL> same would apply if the reader did not add an EOT and someone added
PE> BL> one near the top of the message. Your reader would then delete most of
PE> BL> the message...

PE> So?

The difference is that ^aEOT can't occur as normal user typed text.
Three hyphens can.

PE> PE> And I explained step-by-step why you are a dork.

PE> BL>   Yes... you insulted me rather well but you didn't refute what I
PE> BL> said.

PE> I did.

PE> BL>   If we assume that an Origin line exists...

PE> You aren't even allowed to assume that.

That is certainly a valid possible reading of that spec. I bet most
people *don't* read it that way, but it only takes one. :-)

PE> BL>   If we assume that both a Tearline and EOT may or may not exist:

PE> That is true.

PE> BL>   It is always possible to identify the true Tearline, by counting

PE> No it isn't.

I agree, but I don't think I care - why on earth do you want to
identify the tear line?

PE> BL> back from the Origin (or SEEN-BY if Origin is faulty) a short line (80
PE> BL> bytes) as specified in FTS-4.

PE> Nowhere does it say that "short" means less than 80, but even if it
PE> DID...

PE> BL> Blank lines are ignored.

PE> You pulled that one out of your arse TOO.

PE> BL> The "CR--- "
PE> BL> found is then a true Tearline.

PE> You don't KNOW that.  That could have been the last line in the
PE> message, on a system which does not generate tearlines.

PE> BL> If other lines than blank lines are
PE> BL> found between, the Tearline is false.

PE> Says who?  Where does it say that there are no other control lines

So read blank as blank-or-control, in the above?

PE> allowed to go between tearline and origin?  Ever heard of "#
Origin"?
PE> Where does it even say that the tearline comes before the origin
PE> line?

There's certainly an strong implication, and I think that's a
reasonable assumption. Not cast in stone like a standard should be writ,
but reasonable.

PE> When you receive a message without SOT/EOT, you just have to take
PE> one big guess.  When you receive a message with SOT/EOT, you know
PE> that it follows a set of rules to enable to you find the user-entered
PE> text.

But the majority of messages don't have it. So you have to include rules
for those cases anyway. And the originating software could have
generated tag-origin lines instead of ^aEOT, and those rules would
handle it

PE> BL>   The problem with EOT is that if it is missing (the usual case) then
PE> BL> the scan  backwards takes the full length of every message. It is not

PE> What scan backwards?  Scan backwards to do what?

Yes, here I am also confused.

PE> BL> possible to scan forward and combine it with the search for the null.

PE> It isn't?

Well *I* think it is, and will be doing so in my reader once you've
replied to my long message - in case I really am missing something
fundamental.

PE> BL> The undefined text could contain a EOT line. One has to scan forward
PE> BL> to find the null, and then backward to find the missing EOT. In the
PE> BL> case of no EOT (the usual case), a false one near the head of the
PE> BL> message will truncate the message, even conting backwards.

PE> Bob, I have written a mailprocessor, I've maintained a PKT to QWK
PE> converter, I have enhanced a message reader.  The mailprocessor
PE> didn't need any logic for SOT/EOT, although having them in the
PE> message prevents problems, the PKT to QWK converter required no
PE> extra logic, the message reader works fine with the extra logic.
PE> This "terrible scanning backwards" is a feature of your own mangled
PE> "mind" trying to come up with an algorithm.

PE> BL>   If you don't answer this I assume it is because you have no answer.
PE> BL> Please do not write insults. I'm better at it than you but it becomes
PE> BL> wearing after a while.

PE> Nice faking, Bob.  I answered every technical point you ever put
PE> forward, although it became wearing after a while, so I just use
PE> "Poor old Bob" on repeats.  BFN.  Paul.

Sure, but I don't think it helps. What I would really like to
understand, for example, is this "reading backwards" thing. I don't
think it's necessary, I get the impression you don't think it's
necessary, but I'd really like to see what Bob's doing.

Regards, fIM.

 * * I'm incredibly jealous, but still glad for you.
@EOT:

---