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

It does, the examples above.

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.

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

No, the whole point was to attempt to allow VALID ASCII characters
to get transmitted without people complaining they are kludge lines.
It does NOT allow you to send binary data, which you are attempting
to do.  Kludge lines are not for users to use, they are for software
to generate.

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

It makes perfect sense.  You should be able to send any ASCII
characters you want, without them being interpreted as control
lines.  The spec was not designed for users to "roll-their-own"
kludge lines whilst typing a message.

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.

Rod, I've already told you how to use PKT2QWK and QWK2PKT properly.
If you choose to ignore that, the onus is squarely on your shoulders.

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

No, they're not yours to use.

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.

RS> So your rave on above was a massive brain fart.

No, I'm just telling you how the software was designed to work, you
choosing not to use it that way, thus the onus being squarely on you.

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

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

PE> I only care what you send me.

They are related Rod, even if you can't grasp the relationship.
YOU DELIBERATELY choose to stuff around with kludges, so YOU are
responsible for any out-of-spec messages they cause.

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

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

It just does it, Rod, you don't get any choice.  I only added the
"keep kludges" option in PKT2QWK for Rod Gasson.  I would assume
that his QWK reader knows what to do with them.

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

True.  What I consider to be self-evident often turns out to be 
not so.  Ok, here's an excerpt from FTSCDCH.TXT...


STANDARDS
---------

Standards are those publications that are expected to be adhered
to to the letter.  Non-compliance to the standards will result
in the system being in FTSCD BREACH.  You are not expected to ever
be in FTSCD BREACH, but if you are, and you have been alerted to
this situation, you are expected to fix the situation IMMEDIATELY.
Under normal circumstances, police action (see below) will be 
deferred until one month after notification.  All standards are
published with names starting FTS-05xx, and the official place to
get them from is the FTSCD Chair.

PROPOSALS
---------

Proposals are those publications which have been submitted by
developers.  You are not obliged to follow any of them.  However,
in the situation where a developer introduces a new keyword, no
further proposal may alter the use of that keyword in any way.
In addition, if you wish to use any such keyword introduced by a
proposal, you are required to adhere to the proposal to the
letter.  Non-compliance to these keyword-specifications will
result in the system being in FTSCD PROPOSAL BREACH.  You are
not expected to ever be in FTSCD PROPOSAL BREACH, but if you
are, and you have been alerted to this situation, you are expected
to fix the situation AS SOON AS POSSIBLE.  Failure to fix the
situation within 6 months results in you being in FTSCD BREACH,
without any further leniency period.  All proposals have names
of FSC-05xx, and are available from the FTSCD Chair.

POLICING
--------

Anyone found to be in FTSCD BREACH will have any disciplinary
actions that the political organization cares to muster applied.
That is determined by the organization itself.  It may involve
expulstion from the network, or it may simply be that individuals
choose to not provide you with an echomail feed.
@EOT:

---