Regarding the CTE issue in this thread, I think we've
again missed a significant but subtle characteristic of MIME:
it is processed off-line. We've gone to great lengths to ensure that
encoded streams survive the various gyrations they get put through,
but we still as a group seem to think of MIME as an on-the-wire thing.
But in my experience it is most often NOT processed on-line.
We might seem to be in danger of overstepping our charter.
IETF standards typically define the interactions between Internet hosts,
which would imply SMTP rather than MIME. Nevertheless, what gets
carried over SMTP (eg: MIME) clearly impacts the effectiveness of SMTP.
And we MUST leave the IMPLEMENTOR the FREEDOM to process MIME as s/he
sees best on whatever platform s/he is coding (on-line or off-line).
So MIME might be a TCP creature, or it might not.
Looking at NVT, lines of text consist of printable ASCII
[here you can substitute a wide range of character sets] delimited by
CR/LF. It is convenient for Microsoft that their definition of a
plain text file looks the same. On UNIX, this is not the case;
lines are ASCII delimited by NL (or LF). I am fond of a particular
system where the character set is NOT ASCII, nor any of its variants,
and lines are delimited out-of-band. VMS defines lines (records) OOB
though it again uses good old ASCII. Embedded ESC, TAB, BS, etc. are
generally allowed and sometimes required.
Keep this in mind when you think about how new types
will get processed. Not all the world is an MS-DOS filesystem.
</soapbox>
--
Rick Troth at La Casita, Houston, Texas, USA
"We build our computers the way we build our cities --
over time, without a plan, on top of ruins.
-- Ellen Ullman, "The Dumbing Down of Programming"