I agree with all of this except the last sentence. The MIME systems I deal
with that use NL conventions all do it within just the text body parts.
Hence, your statement is not true for such systems.
What about the ends-of-line that surround MIME boundary markers? Is
the EOL before a boundary marker in a non-text part represented as
CRLF or LF? How about the one after the boundary marker?
If you're not *very* careful, you'll end up with something which
"looks" exactly like MIME, but is incompatible with it. There's been
enough problems with various systems (including attmail) that look a
lot like 822 but aren't compatible with it. Seems like we would want
to avoid that problem the second time around.
My take on MIME in environments where EOF != CRLF is that you use the
content-transfer-encoding to decide whether you are in transparent
mode or local-newline-mode. So if the c-t-e is binary then EOF is
CRLF within that body part; otherwise EOF is the local newline.
This needs to be nailed down before people start shipping product
that makes one assumption or another.
Keith