Eric A. Hall <ehall@xxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf