Eric A. Hall <[EMAIL PROTECTED]> writes:
...
>I also note that the digest media-type is already specified and is the
>appropritate interchange format if you actually do have a collection of
>well-formed 2822 objects. But if you have an mbox file, you have to
>exchange it as an opaque database, and you have to delineate any internal
>assumptions through out-of-band negotiations. The mbox media-type is for
>use with tagging and identifying the data being exchanged ("here is an
>opaque database of unspecified message objects") only.
...
>This is not intended to serve as an authoritative reference to the mbox
>database format, but is only intended to provide an identifier for the
>database-type when it is transferred. Out-of-band negotiation is necessary
>in all cases anyway, and I don't really think it's appropriate for the
>IETF to define an application-specific database format anyway.If there are no defined semantics for the content of an application/mbox part, how does the type differ from application/octect-stream? In both cases you have to look to out-of-band info to interpret the data. Indeed, there appear to be no requirements at all on the content. If successful uses of this content-type effectively requires private arrangement, why does it need a standard content-type instead of each such exchange using a content-type tailored to the circumstance and taken from the "vnd.", "prs.", or "x." trees. How does use of application/mbox over application/octet-stream or some other content-type improve interoperability? ... [regarding creating a spec for a mailbox file format] >I'd like to see one, and I'd like to see whatever *NIX consortium is >responsible for such things get together and define one. At that point, would application/mbox be updated to refer to said spec, rendering non-compliant some chunk of the previous uses, or would a new content-type be specified? Philip Guenther _______________________________________________ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
