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

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

I actually do say explicitly in the spec that only kludges that are
designed to mark up text, and there are VERY few of them, should
appear between the SOT and EOT.  That's what it USED to say anyway,
then I changed it to make it "between the initial block of kludges
and the EOT", because I can do what I want to do with that definition,
no need to force everyone to make sure SOT is the very last kludge,
just recommend it.  Changing it that way enabled others to generate
SOT without worrying about their tossers adding a TID on the end.

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

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

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.

I can't allow them, even if I wanted to, as I said.  And anyway, I
don't scan for a MSGID at all in Tobruk, it has no use for it.  I
would be happy to have GMD scan for those though.  Or happy to have
more validation done in Tobruk 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 
RS> specifys.

RS> You cant have it both ways.

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

In this message that I am replying to, you did NOT generate a MSGID.
That is fine, it is OPTIONAL for you to do so.

In the message I was complaining about, you DID generate a MSGID, and
it WAS out-of-spec.  BFN.  Paul.
@EOT:

---