PE> I know I already creamed you guys comprehensively last time
PE> we discussed SOT/EOT, but I thought I'd post this anyway, just
PE> to rub it in.  BTW Andrew, the least you could do is admit that
PE> you just made up that "can't guarantee that my system conforms
PE> to all of the SOT/EOT spec" rubbish.

rc>     Actually I agree with him, it is almost impossible to conform to every 
rc> bloody little thing in your spec. You don't just define SOT/EOT: you also 
rc> attempt to redefine how we should format a message.

Give me an example of something that is almost impossible to
conform to.  SOT/EOT is designed to be simple to generate.

PE> amazing fact that MSQ305 will manage to do C program in -> C
PE> program out, but alas, this is the exception, not the norm in
PE> fidonet today!

rc>     This is where your ideas clash with mine. Obviously you think that an 
rc> origin line is an unimportant piece of control information: you do not let 

Then you are wrong.  It's as important as the INTL + FMPT lines.

rc> the user modify it from message to message; you do not even SHOW it if 
rc> viewing of control lines is disabled, I believe!

No, the user can't modify it in the same way that they can't modify
their INTL line.  And if they disable control lines, they don't see
it the same way that they don't see the INTL line.  In both cases
(netmail + echomail) the from address is extracted from the 
appropriate control lines and displayed next to the "from name".
How come I never hear you complaining that you can't see the INTL
line and that you can't modify it?

rc>     Plus, I thought SOT/EOT was for your tosser to consume, not your 
rc> message reader ...

SOT/EOT is designed to bracket the user-text.  Your tosser can use
this information to get the control information (SEENBYs etc).
Your editor can use it to display just the user-text in the user-text
presentation display.  BFN.  Paul.
@EOT:

---