moore(_at_)cs(_dot_)utk(_dot_)edu (Keith Moore) wrote on 12.08.04 in
<7AA3E945-EC5D-11D8-B09E-000393DB5366(_at_)cs(_dot_)utk(_dot_)edu>:
This proposal needs to be sent back for further consideration, either
by a
WG, or at least by some mailing list of those with knowledge of the
format.
It has just missed too many opportunities, including the opportunity to
document the mbox format once and for all (and warts and all).
uh, no. this is an application for a media-type. it's not trying to
define the mbox format, it's just trying to define a label for the mbox
format that can be used in contexts where MIME media-type labels are
required. the intent is clearly that this label should be usable with
the variety of mbox files that exist, not with one specific variant of
mbox file.
But to do that, it needs to specify which variant of mbox the data is, and
to do that, there needs to be at least a description of the various
variants.
there are lots of media types for which there isn't a description of all of
the variants available. we find it useful to label things even without
those descriptions.
From looking at the formail man page (just something quickly found on my
machine), I see mention of a variant using Content-Length:; a "traditional
Berkeley mbox format"; and a "BABYL rmail format" (*is* that mbox?).
no, BABYL format is not the same as mbox format.
trying to write a definitive specification for the mbox format is not
the same thing as trying to define a label for that format. nor is it
the same thing as trying to document existing practice. many authors
and groups get these confused, with frequently unfortunate results.
However (again), it *does* need to provide a way to identify the variants
in actual use. If it doesn't tell me which variant of mbox it is, it might
as well just say "application/octet-stream".
lots of tools seem to be able to make use of mbox files without knowing
precisely which variant they're reading.
Keith