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