RS> Yes, but that was the usual problem with you being far too cryptic.
RS> I dont recall you even mentioning that kludge lines werent included in
RS> that concept, in the long series of messages where it was being discussed.

PE> You may recall that Bob was saying that if it wasn't
PE> designed to allow binary data, it was useless, and I
PE> was saying that sending ASCII data was what concerned me.

RS> Sure but again, thats not the same as saying that kludge lines
RS> arent allowed, and when the whole argument was about accidental
RS> inclusion of control stuff, you have to actually say that explicitly,

PE> I actually do say explicitly in the spec that only
PE> kludges that are designed to mark up text, and there
PE> are VERY few of them, should appear between the SOT and EOT.

Yes, I was referring to the discussion tho, you were too cryptic there.
Because if you had said that explicitly, I would certainly have pointed
out that it makes no sense to exclude stuff like the MSGID. PRECISELY
the same logic applys as it does with the origin line and ---, it makes
sense to allow those between an SOT/EOT pair as well.

PE> That's what it USED to say anyway, then I changed it to make
PE> it "between the initial block of kludges and the EOT", because
PE> I can do what I want to do with that definition, no need to force
PE> everyone to make sure SOT is the very last kludge, just recommend
PE> it. Changing it that way enabled others to generate SOT without
PE> worrying about their tossers adding a TID on the end.

I still think the logic is rather mangled. Essentially
the SOT/EOT pair delimits a block which something like
a tosser should not scan for any control information.

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.

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

PE> It is STILL possible for an embedded MSGID to escape!

RS> Well, I still think it makes a lot more sense to allow
RS> those between an SOT/EOT pair, tho I certainly dont want
RS> to include any on purpose. Its just more robust like that.

PE> I can't allow them, even if I wanted to, as I said.

Thats a brain fart, as I said. You already do
allow an origin line. Which flouts the 'specs'

PE> And anyway, I don't scan for a MSGID at all in Tobruk, it has
PE> no use for it.  I would be happy to have GMD scan for those
PE> though. Or happy to have more validation done in Tobruk too.

Its pointless, the SOT/EOT pair should delimit the block which
should NOT be scanned for stuff like origin lines etc. MSGIDs too.

PE> Are you talking about my node not going into the PATH line?  In that
PE> case, it was a bug, but it wasn't out-of-spec, PATH being optional.

RS> Come on Paul. YOU just told me that while the FTS-09 does say that MSGID is
RS> optional, that if it appears it has to be done the way that FTS-09 specifys

RS> You cant have it both ways.

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

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

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

---