RS> It does make considerable sense to ALSO allow those between
RS> an SOT/EOT pair just because that makes the system more
RS> robust, its not hard to insert say some data that you are
RS> commenting on program not working well with, or something.

PE> Even if I wanted to, I couldn't do that.  I would then be
PE> violating FTS-1 and FTS-9 if I were to say "don't worry, you're
PE> allowed to include those kludges if you want to, they will be
PE> ignored", because it will be incompatible with programs that search
PE> for them anywhere. I cannot pit my spec against FTS-1 and win.

RS> You are having a brain fart there. You ALREADY do that
RS> stuff with the other stuff like the embedded origin line
RS> and --- etc. It makes no difference to include the MSGID etc too.

PE> No, the spec, in this case FTS-4, does not actually
PE> say that you can't have "---" etc in the message itself.
PE> It just says that you should tack one on the end.

Thats faking Paul, particularly on the other
stuff you do allow between the SOT/EOT.

PE> However, there are tossers that don't handle that very well.

Ditto embedded origin lines between an SOT/EOT pair. No reason at
all why the new kludges, the vast bulk of which tossers done even
use, can be allowed between the SOT/EOT pair by the same logic.

PE> Rod, it is OPTIONAL to generate a PATH. I was
PE> NOT generating a PATH. I was not out of spec.

RS> Nice theory, pity that once it left Daves system, the
RS> PATH that was on the message THEN didnt meet the specs.

PE> Hey Rod, if you think about that for more than 1 second,
PE> you would realise that that would make PATH *not* optional.

Hey Paul, if you think about that for more than 1 second,
you would realise that you are faking away like mad and that
however it happened, that produced an out of spec message.

Yes, thats one very real deficiency in allowing
something like the PATH to be optional.

RS> Luckily for you, no one upstream of Dave was just silently
RS> binning entire PKTs because a particular message was 'out of spec'

PE> Since the PATH is optional, no-one is required to generate
PE> it, and no-one on the way is required to update it.

Fact remains, whatever was or was not required, it ended up with
an out of spec PATH line, and THEN it was out of spec, and it didnt
make the slightest sense to silently bin the entire PKT it was in.

The same applys to embedded origin lines too, it ALSO
doesnt make the slightest sense to silently bin entire
PKTs which have a message with one of those in it either.

Or a message which has a dud system ID in the origin line either.
@EOT:

---