FM>   AREA:
FM>   SEEN-BY:

FM> In some of your messages and also in "the below" you include the
FM> tear-line, and maybe some blank lines, as "control" lines,
because (if I
FM> understand you correctly) they were not written by the user but
FM> generated by software. 

That is correct.  The whole point of SOT/EOT is to distinguish what
is the user's text (as defined by the FTS specs).  Tearlines governed
by FTS-4, and blank lines generated by software to get the tearline
specified by FTS-4 to be away from the end of user text, are both
control lines.

In actual fact, the info on the tearline can be put into a ^aPID
instead, ref FSC-0046.  And you'd have to be pretty game to call
^aPID anything other than a control line.  If tear + origin had
had ^a in front of them, there wouldn't have been any debate.
But because the author of FTS-4 fucked up, now everyone else is
confused as well.

FM> (But you could validly argue that logic which says "write a ^aSOT: line
FM> if I haven't written any other 0x01 lines before the user text, and I
FM> haven't written an area line because it's a netmail message" is OK too.

Sure.  Easier to just be consistent though.

FM> What about a user who types a line starting with SEEN-BY: as the last
FM> line of his message? (And that's not so unlikely, maybe he's imported
FM> another message including the seen-bys.) I note your comment that FTS-4
FM> doesn't actually require that there be an origin line, nor mandate the
FM> order of origin and seen-by lines. So we have 3 cases: new software
FM> which we can make do it "right" (say by generating ^aEOT,
or putting the
FM> origin & seen-by in the "accepted" order); old
software which follows
FM> the accepted order; and old software that doesn't (and maybe doesn't
FM> even generate origin and/or seen-bys).

FM> There is nothing you can do about the last case. There is nothing you
FM> need to do about the second case. 

You've neglected to mention the tearline.  There is new software 
which is not generating tearlines, because the author says they
are optional.  Without a spec that makes them compulsory, the idea
is that they could at least have the courtesy of adding SOT/EOT.
And you've neglected blank lines.

Also, you have said that origin + seenby are in the "accepted" order.
There is nothing that says what that accepted order is.  Not until
SOT/EOT.

FM> 9) As a packet reader you treat any line starting with SEEN-BY: as a
FM> valid seen-by line if it's followed by no lines other than other
FM> seen-bys, 0x01 lines, or blank lines.

There is no spec that says that SEENBY will contiguous.  Except 
SOT/EOT and FTS-0501.  The later came a year or so after the 
former.

FM> it's followed by nothing except what's in the above paragraph.

What about a Ctrl-Z?  What about "# Origin"?

FM> And you treat any line starting with --- as a valid tear line if it's
FM> followed by nothing except what's in the above 2 paragraphs.

Then you may be classifying as a tearline, what is in fact the last
line of an Ada program.

FM> If you do the above the only circumstance which will catch you out is a
FM> line(s) of his text, and is using software which does not create tear,
FM> origin or seen-by lines. And you can't do anything about that anyway
FM> except ask him to update his software.

At least if it is bracketed by SOT/EOT you KNOW that you have not
got confused.  If it isn't bracketed by SOT/EOT, then you can
only guess.

FM> There is no case for ^aEOT:. You should generate tear and origin lines
FM> in that order at the end of your message, and add seen-by lines to the
FM> end of a message.

How many blank lines should be added, BTW?

PE> Also some people have
PE> seen fit to exacerbate the problem with control lines such as
PE> "# Origin".

FM> I didn't know that. Should one look for
Origin: as well as
FM> Origin:?

Who knows.  That's just one proposal.  If they can propose that,
then others can propose putting "Fred Nurks Was Here" between
Origin and SEENBY too.

Basically it is a complete abortion.  SOT/EOT gives a standard for
people to follow, which leaves no room for ambiguity.  There is no
ambiguity on whether a blank-line is user-text or control line,
no ambiguity on whether a tearline is user-text or control line,
no ambiguity on the dimension of the origin line, no ambiguity on
whether other stuff is permitted, no ambiguity on the order,
etc etc.

And like I've said, all along, if you make origin, tear and a
single blank line compulsory, there is no need for EOT.  In fact,
I was trying to get the FTSC to do just that, but they are dead.

PE> 5. FTS-4 does not specify the format of the address in the
PE> origin line.

FM> So one should look for "nD", n = 2..5?  And generate what?

Look for 5d (and throw away the 5th dimension), generate 4d.  

PE> 10. FTS-1 does not specify any maximum length for kludge lines.
PE> This means that every man and his dog defines an artibrary
PE> maximum (and no, it isn't 10 gigabytes) when they write their
PE> program.

FM> Does this actually matter? If a kludge line is one you don't understand,
FM> or it's one you do but is longer than you're prepared to handle, just
FM> bin it or pass it straight to the output, depending on what sort of
FM> program you're writing.

What if it's one you do know about and need to parse and generate?
Like SEENBY.

PE> 11. FTS-4 does not specify a maximum length for the AREA,
PE> SEENBY, tear and origin lines.

FM> I thought seen-by was specified? 69 or something? Same as path?

Not by FTS-4.  FTS-0501 does, but that is more recent than SOT/EOT.

PE> SEENBY - start searching from the bottom of the message.  Go back
PE> one line at a time until you get a SEENBY.  Then go back one line
PE> at a time until you get a line that DOESN'T start with SEENBY.

FM> Well I wouldn't do *that*. Reading backwards is for the birds, and
FM> unnecessary. But I understand what you're saying and agree with your
FM> logic - I just wouldn't be reading backwards, it's not necessary.

You'd rather parse the entire user text instead of skipping to the
bottom and going backwards?  Up to you.  If they've included a 
message with SEENBY lines in it, you would be parsing that, and then
searching every user line, checking to see whether you need to 
throw away the results of your scanning.  BFN.  Paul.
@EOT:

---