Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote on Thu, 12 Aug 2004
08:45:24 -0400:
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.
That's correct; this is a tag definition, not a format specification.
Others should note that RFC2048 is designed to facilitate registrations --
more definitions for common data-types are widely preferred over a
proliferation of "x-foo" media-types that result from high registration
barriers (read the intro to 2048 if you don't believe me) -- and that's
the limited objective of this proposal.
There are a few places where this tag is necessary or useful. Online
downloadable archives of mailing lists would be easier to import, search
and otherwise manipulate if a media-type were defined and which allowed a
transfer agent to bridge the data to a local content agent (most of the
IETF archives are in mbox format, and I'm aware that certain cellular
email systems allow for downloadable SMS/email logs via mbox, not to
mention the proliferation of web/local mail systems that use mbox files
which are often transferred back and forth). Local actions such as
importing or opening a local mbox file would also be easier to perform if
there was a media-type that the OS could use (I have many mbox files of
project-specific archives and would appreciate better OS/messaging
integration with these files [such as opening and searching folders the
same as I can with message/rfc822 file objects], but need an OS-level
media-type to get there). And so forth.
A definitive authoritative specification for all variations of the mbox
database format is explicitly not the objective, for several reasons. For
one thing, such a definition is outside the IETF's purview, the same as a
definition for Outlook or Eudora or other vendor/platform-centric database
formats would be. Second, if the IETF *did* try to write such a
definition, it would quickly settle on the fact that multipart/digest
already exists for such purposes, and that defining an mbox format would
be redundant. If development proceeded beyond that (unlikely at best),
then the spec would necessarily conform with other messaging definitions,
and would end up declaring that mbox files SHOULD/MUST be compliant with
RFC2822 messages at a minimum, which ignores the reality of eight-bit
content, long lines, untagged charsets, EOL variations, etc. Other folks
can start a bof/wg and go through this process if they want to, but
frankly I'm happy just registering the media-type (the purpose of the
process, and the objective of this I-D).
On top of all that, mbox parsers need to be aware of the limitations and
variations on the content, and this cannot be adequately handled with a
media-type definition.
Suggestions about parameters has come up before (John Klensin suggested it
to me a couple of months ago). Unfortunately, these kind of helper tags
attempt to define content rules rather than transfer rules, and therefore
represent a non-trivial layer violation. They are analogous to using a
"version=" tag for app/postscript and relying on that meta-information
instead of embedded clue data. Obviously, content agents should be aware
of the content formatting rules. [what happens when the helper meta-tags
are lost? should the content agent NOT look at the content to make a
determination? that's where the logic belongs in the first place, so
putting it into the transfer layer is not only irrelevant it is possibly
harmful.] This data should not be overflowed to the transfer agent except
where it affects the transfer process proper, which is not the case with
any of the suggested tags.
however I don't think this should be up for PS, as the standards track
is intended for protocols that can be subject to interoperability tests,
and this is just a label. Informational seems more appropriate to me.
I'll go along with that. 2048 only requires IESG approval, but does not
require standards-track, and dropping to informational gets us there.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/