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

Keith, very nicely put. I am in complete agreement with everything you
say here.

				Ned

> 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

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