PE> Not kludge lines I didn't.

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 was
PE> saying that sending ASCII data was what concerned me.

Sure but again, thats not the same as saying that kludge lines arent
allowed, and when the whole argument was about accidental inclusion
of control stuff, you have to actually say that explicitly, coz the
question of real binary data is quite different to say including some
stuff like say even a basically ascii file with a few odd control chars.

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

Essentially I am saying that there is a hell of a difference
between full binary support and just not scanning for kludge lines
between an SOT/EOT pair. Makes no sense to scan for them particularly
an app which has no interest in the body of the message at all,
just wants to see where it starts and where it stops.

RS> AND I didnt misunderstand the message where you said you planned
RS> to silently bin entire PKTs which had a message which you regarded
RS> as out of spec. One particular message says that very unambiguously
RS> indeed, no misunderstanding of that message is possible.

PE> THAT was in the situation where I had warned you
PE> about a problem and you did nothing to fix it.

OK, that certainly makes sense.

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

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

PE> Do not let that happen!  I have told you how to avoid that
PE> problem, it's up to you what you do to solve the problem.

Still makes a hell of a lot more sense to allow them between an
SOT/EOT pair. Not just kludges either, even just odd non printing
chars too. Its not hard to get an embedded FF for example.

PE> PQWK260 will now not create an invalid
PE> fixed header because of an embedded MSGID.

Yeah, thats what I meant. You appeared to
be saying that that was fixed with 2.60.

I still see no sense in binning an entire PKT that
has an control char between an SOT/EOT pair tho.

RS> Luckily for you, the systems upstream of you
RS> have a HELL of a lot more sense than to do that.

PE> I don't recall I ever sent out-of-spec messages to
PE> Dave. Certainly I don't recall being notified by him.

RS> Yes, it was out of spec. Clearly his
RS> system didnt give a damn about that wart.

PE> What was out of spec, Rod?

I forget the detail, the PATH didnt have your address in it from memory.

PE> I send a relatively small amount to Dave that I send to you guys,
PE> so I might have checked the packets manually before sending them.
PE> In fact, I'm certain that I would have, on the first run of Tobruk.
PE> And I would have remembered Dave telling me about out-of-spec messages too.

I never said DAVE said anything. *I* told you that someone had told ME
about it, and you fixed it, next day from memory.

PE> Just where did you get your information from?

I'm talking about what you refer to below.

RS> I had no way of seeing how long your system had been doing that
RS> without going and getting mail from somewhere else to see how long
RS> its been going on for. It would have to be a system past Dave.

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. 

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

You cant have it both ways.
@EOT:

---