PE> you included someone else's MSGID.

RS> That stuff is INSIDE the SOT/EOT which
RS> is supposed to be THERE for that stuff.

PE> No it isn't.

RS> Fraid so, you SPECIFICALLY mentioned the advantage when someone
RS> included an entire other message inside the body of the message
RS> and claimed that the SOT/EOT would protect against that producing
RS> and embedded origin line, in the body of the text, apart from the
RS> true origin line at the bottom of the message.

PE> Yes, that is correct, I'm not worried about the origin line in the
PE> middle of the text, except that PQWK 2.50 couldn't handle it due to a
PE> bug. If you read the quote above, it was about MSGID, not origin line.

If you read the above with your brain in gear you would be able to grasp
that the SOT/EOT wasnt JUST for an embedded origin line, it should allow
ANY of the stuff thats normally part of the control information of a
message like the origin line or the line starting with --- to be in the
body of the message, between the SOT/EOT. Thats the WHOLE POINT OF IT.

PE> Only kludges that are meant to mark up
PE> text are meant to go in the text portion.

RS> Welp, thats fucked. Because quite apart from a true kludge like
RS> MSGID, the whole point of the SOT/EOT was so you could have ^As
RS> on the front of lines in the text you wanted in the message, not
RS> as kludges at all, but because you wanted that in the body of text,

PE> No it wasn't.  ^As are not part of text, they are control lines.

Thats crap Paul, the whole point of delimiting the body of the
message with the SOT/EOT is so you can have stuff that would
otherwise be seen as control information in the body of the message.

RS> usually because you have inserted some non pristine text in the body
RS> of the message for some reason, say including code code etc to be
RS> viewed without having to explicitly ensure that stuff like --- on the
RS> front of the line was edited out, because it was between the SOT/EOT.

PE> The "---" is fine.

So should an extra MSGID as long as its between the SOT/EOT. It makes no
sense whatever to allow lines starting with --- and embedded origin lines,
but not the other stuff that would otherwise be treated as kludge lines.

Thats the whole POINT of the SOT/EOT pair, essentially saying
anything that processes the message 'dont look between the
SOT/EOT pair for any control information belonging to this message.

PE> This is in violation of both FTS-9 and FSC-0500.

PE> Please do not put kludge lines in your messages.

RS> It certainly wasnt deliberate. The system should handle it elegantly.

PE> Feel free to send me the code diffs for an improved product.

RS> Feel free to go and fuck yourself.

PE> I don't care what you do, so long as you send me in-spec messages.

Soorree, you have the nuttiest ideas about what constitutes an in
spec message. And the nuttiest ideas about what to do with you first
see one you regard as out of spec, silently bin the entire PKT.

Luckily for you, those upstream of you have more sense.

RS> *I* wasnt the one proclaiming that its absolutely mandatory
RS> to strictly to adhere to all FTSs and FSCs in existence, and
RS> it cant be done anyway, some of them are mutually exclusive.

PE> It is with the FTSs, and the FSCs you
PE> should either not use, or conform to.

Odd that you included an FSC in what you proclaimed it broke. And
YOUR software broke an FTS and the systems upstream of you had enough
sense to not silently bin any PKT which had a message which did.

RS> In fact in this particular case we are actually talking about
RS> the design of the SOT/EOT handling, YOUR code. It appears you
RS> have mangled the concept considerably if it doesnt allow stuff
RS> that is normally part of the message non body text to be included
RS> between the SOT/EOT without the user having to manually edit that
RS> stuff out. That was supposed to be the WHOLE POINT of having the
RS> SOT/EOT in the first place, or atleast thats what you said.

PE> I do.

So its completely silly that it doesnt also allow an
embedded kludge line between the SOT/EOT for the same reason.

RS> I'm quite sure you specifically mentioned that with the --- and the
RS> origin line, that you could have those included between the SOT/EOT safely.

PE> That is fine.

And it would be much finer if it allowed kludge lines between
the SOT/EOT too. It is in fact the only thing that makes sense.

PE> I HAVE provided a way for you to use it safely,
PE> and it is to NOT stuff around with kludges.

RS> Missing the point utterly, no one was stuffing around with any kludges,

PE> You were.  By using a no-default option in PKT2QWK.

Soorree, that FSC says nothing whatever about anything remotely like that,
it in fact says that you can include stuff which would otherwise be treated
as control information between an SOT/EOT pair in the body of a message.

RS> just quoting a message, and THAT including some of that
RS> stuff. That was the WHOLE POINT of the SOT/EOT, marking
RS> an area where that stuff would not be searched for.

PE> Nope, not on ^A lines.

Welp, thats fucked. Pointless to treat those separately.

PE> They should have been stripped by PQWK unless
PE> you deliberately overrode the default setting.

RS> Nope, I use the QWK2PKT command switches specified in the README apart
RS> from the -T. Needless to say the switches arent actually listed clearly.

PE> They should have been stripped by PKT2QWK, not QWK2PKT,

RS> Oh get fucked. You dont get to proclaim that
RS> the kludge lines be stripped as they are receive,

PE> Rod, I don't care what you do, so long as you send me in-spec messages.

So your rave on above was a massive brain fart.

RS> PARTICULARLY stuff like MSGID which has
RS> some uses for threading and dupe checking.

PE> Rod, I don't care what you do at your end,
PE> just don't send the MSGIDs back to me.

Pity it makes a HELL of a lot more sense to not look for them between the
SOT/EOT pair. The term fucked by design springs to mind for some reason.

PE> so they would never have been an issue in the first place.

RS> Soorree, you dont get to proclaim that everyone
RS> must strip MSGIDs on messages they receive,

PE> No, I don't care what you do your end,

You did actually, you were raving on about the version of PKT2QWK used.

PE> I only care what you send me.

And you should instead not check for kludge lines between SOT/EOT pairs.

RS> PARTICULARLY when the vast bulk of messages
RS> have them now. Thats mindless fascism.

PE> So you mean Maximus is also mindless fascism, because
PE> it strips the MSGIDs before sending them to you?

*IT* doesnt proclaim that everyone must strip them YOU did.

PE> Get real, Rod.  It's how it was designed.

Yes, they get to make choices like that, YOU dont get to proclaim that
no QWK can ever have the kludges included. Plenty do too, whatever
Maximus may choose to do, because some QWK systems do elegantly handle
the MSGID/REPLYID pair. Whatever you proclaim on that.

PE> QWK was never meant to have kludges,

Soorree, you dont get to be Fuhrer on how QWKs are done.

PE> that's why your stupid QWK reader doesn't know what to do with them.

Soorree, thats tripe, some do.

PE> But like I said, I don't care WHAT you do, so long as you
PE> come up with some mechanism to send me in-spec messages.

Yes, and it might just be handy to point out what you do regard
as out of spec because you have some rather novel ideas on that.
Silently binning entire PKTs which contain a message you claim
is out of spec is just plain nuts, as you would have found if
the systems upstream of you had adopted your approach on that.

And it STILL makes no sense to not allow kludge lines between the
SOT/EOT pair because PRECISELY the same logic applys to them as it
does to the --- lines and the origin lines etc. You will NEVER be
able to ensure that ALL message creation software will ensure that
you cant have that in a message body. So it makes a hell of a lot more
sense to have an SOT/EOT pair between which you dont scan for any of that.
@EOT:

---