The canonical form of any MIME text type MUST represent a line
break as a CRLF sequence. Similarly, any occurrence of CRLF
in text MUST represent a line break. Use of CR and LF outside
of line break sequences is also forbidden.
Good. Good for on-the-wire.
Let me restate this: we need to look at MIME as an off-the-wire
concept. MIME is *great*, and the spec is *great* as long as we stay
on-the-wire, and that's fine. But people are using MIME off-the-wire
and looking at the same on-the-wire spec. This needs to be, at least,
clarified, better, formally addressed.
All Internet standards ever address is what happens on-the-wire. Not only are
off-wire matters not addressed, in the past work to specify off-wire aspects of
various protocols has been rejected as being out of scope. (Standardization of
POP3 and IMAP4 nearly didn't happen because of this, believe it or not. We had
to argue that mailbox access operations needed to be standards across the
Internet before the groups were approved.)
I think Ned convinced me that as an IETF specification,
it is properly focused at on-the-wire operation. Is there a way
we can, without ruffling too many feathers, put in some wording
that will make the MIME spec a better fit for these off-the-wire
square pegs?
Sure. Write a document that goes along with the existing MIME specification
that addresses off-wire issues. Then, once you have a document in hand,
approach the IESG about it and see if you cannot get it onto the standards
track. (The composition of the IESG has changed significantly if not completely
in the past few years so things that were impossible before may be possible
now.) If you can, great, and if not, you can always publish it as an
informational RFC.
I don't think it makes sense to talk about such things without a concrete
example in hand.
The best reason I could think of was to keep sanity when crossing gateways
that routinely remove content-transfer-encodings, but that does not strike
me as the most compelling thing in the world.
More fundamental and basic than that: let plain text
be plain text. Let plain text on the EBCDIC systems be converted
into ASCII when it goes out into SMTP.
Quite true -- use of ASCII-based material is preferable on the wire but says
nothing about how you store things locally.
Ned