Keith Moore wrote:
I don't believe that the creation of a new content-type is likely to
result in a lot of new mbox readers or writers.
There is however a new issue, viz. that readers and writers are likely
to be on separate systems, with possibly different conventions.
Well, I can't speak for your experience, but mine has been that once you move
past the very common case of a single piece of software that contains both a
reader and a writer, the next most common case is the use of mbox as a means of
exchanging material between different systems. The reason for this is simple:
It is very common for software to provide the ability to read mbox files, so if
you want to export, say, a VMS MAIL mailbox, mbox is a pretty reasonable
exchange format to use.
It would have been nice if multipart/digest had assumed this role, but in
practice it has not.
I don't expect a media type label to change this reality much if at all.
And I do believe that
whatever new software is written to read or write mbox files will be
similar to existing software that reads and writes mbox files. If most
existing software doesn't need knobs to deal with format variation, I
don't suppose that most new software will need it either.
The UW imap formats document mentioned earlier in this discussion
lists at least 5 distinct flat file formats, identified and parsed
separately, with variations ("knobs") in the two areas already
specifically suggested for parameters, namely separator line format
and line ending conventions.
UW IMAP supports several formats that have nothing to do with any variant of
mbox format out of the box, and this doesn't even take the various drivers
that have been written to handle even more bizzarre stuff.
Ned