Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard

On Aug 17, 2004, at 8:38 PM, Dave Crocker wrote:

>  If someone can summarize where
> this thread is going and/or should go, I'd appreciate it.

my recommendation to the author -

- do another edit on the draft, mostly for nits and clarity, and 
resubmit for Informational

- don't try to specify the application/mbox format in this document at 
all.  instead, point to various published definitions and descriptions 
(man pages, web pages, whatever) such as exist.

- for that matter, don't try to specify how best to generate mbox 
files.  that's out of scope.

- explicitly point out that there are varieties in how the format has 
been implemented which can affect interoperability.  (this should not 
be a showstopper, as there are varieties in how almost any other 
MIME-labeled format is implemented which can affect interoperability.)

- my preference is to not have parameters describing format variants at 
all, as they're highly unlikely to be used correctly and even less 
likely to be generated correctly.  if you must have parameters, make 
them optional.

- you might want to point out that a wide variety of mbox-reading tools 
generally manage to make sense of mbox files despite the variations.  
and yes, they barf sometimes.  some implementations' heuristics are 
better than others.  again, this is also true of Word, PDF, JPEG, 
PostScript, or any other format you could care to look at.  it's useful 
to be able to distinguish mbox files from other kinds of files, even if 
saying something is an mbox file is not perfectly precise.

- point out that the existence of an application/mbox label is not a 
recommendation that mbox files be used to transport groups of messages 
-  at least, not without first defining a new variant of mbox files 
that is transparent (no >From), reliable (no message boundary 
synchronization errors),  immune to variations in line terminator, and 
doesn't use character or line counts (no content-length).

- recommend base64 encoding as a default for transport of mbox files 
over email, since the encoder typically has no idea about the message 
contents and whether they might contain binary data.

my recommendation to everyone else -

let's wait for the revision and look at it then.  meanwhile, let's 
realize

- that having a way to label mbox fiiles is much more useful than not 
having one;

- that perfectly precise labels for anything are almost nonexistent in 
practice;

- that having an imprecise MIME label for mbox files probably won't 
degrade interop significantly over what it already is

- that there are probably better uses of our time (individually or 
collectively) than to define the perfect label for mbox files.

Keith

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf