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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf