[Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]

[ned.freed at mrochek.com]

> Here's my thinking. Given the choice between breaking applications that
> rely on different end-of-line sequences versus breaking one or more of the
> specifications, I've got to favor breaking the apps. Besides which,
> checking for end-of-line strings and adapting/converting isn't exactly
> rocket science.

> Therefore, the major media-type for mbox files should be application.

> I'll clarify in the spec that the canonical end-of-line sequence is
> UNIX-specific and that applications MUST only transfer mbox files in that
> format, but SHOULD be prepared to receive files in other formats for the
> sake of robustness, and that any local processing and/or conversion is up
> to the application[s].

> I'll also add a statement up front that message/digest is preferred since
> it doesn't have problems with eol, charsets, etc.

> Everybody okay with that?

No. If you're going to specify a single line terminator sequence it needs to be
CRLF so that 7bit and 8bit encodings can be used. Forcing the use of
quoted-printable or base64 on all transfers of mbox material is the wrong thing
to do.

Mbox files are mailed around using 7bit and 8bit encodings all the time.
A media type that is incompatible with this very common usage is either
(a) Not going to get used, making it worthless or (b) Will be used in a way
that violates your MUST, which will break interoperability.

The choice of CRLF as the preferred line terminator for email was made
long ago. It cannot be changed now, and specifying types that conflict with
this is a really bad idea.

				Ned