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

[ned.freed at mrochek.com]

> On 5/18/2004 9:24 AM, ned.freed at mrochek.com wrote:

> > 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.

> Of course this statement is correct in multiple contexts. But we're not
> talking about "mail" here -- mbox files are mailstore-specific databases,
> and not collections of "Internet mail" in general. They need to be treated
> in the same way that (say) Eudora or OE databases would be handleded.
> Whether any specific mbox file happens to contain sequences of Internet
> messages and is easy to parse as text is somewhat irrelevant, since it
> could just as easily contain locally addressed messages of undeclared
> eight-bit character data. The database needs to be treated as opaque, and
> the end-point applications that use it should be responsible for any
> necessary prior agreements and arrangements.

I don't know what handling is "needed". What I do know is that these files are
in practice handled as text files, with all that implies.

> > 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.

> I can make explicit allowances for that if it would make people more
> comfortable. Since the database content has to be negotiated out-of-band
> anyway ("download the archive of message/rfc822 objects", or "these
> messages are all big5"), folks certainly should be able to match an
> appropriate encoding to the content.

The appropriate encoding in practice is going to be no encoding.

				Ned