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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf