Eric A. Hall <ehall(_at_)ehsco(_dot_)com> 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf