From: "Eric A. Hall" <ehall(_at_)ehsco(_dot_)com>
If there are no defined semantics for the content of an application/mbox
part, how does the type differ from application/octect-stream?
It provides an identifier for the content, so that transfer agents can
perform specific tasks against the data (such as importing or searching a
remote mailstore, or handing the data to an agent that knows what to do
with it). The agent still needs to deal with content-specific issues like
determining the EOL markers, applying default domains to relative
addresses, and so forth. That's a pretty common separation of powers;
application/postscript doesn't relieve the system from needing a
postscript interpreter, and we leave things like ~version tags for the
content agent to worry about instead of the transfer agent.
[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?
Given that the current proposal specifies minimal formatting (essentially
being limited to the likely presence of some kind of From_ line), I'd
think that a reasonably authoritative spec could be referenced in an
update to this proposal. It would depend in large part on the depth and
comprehensiveness of the specification, I'd imagine.
I cannot understand that except as saying that this document explicitly
and intentionally does not provide enough information for the recipient
of a message defined by the document to decode the message. I understand
that statement as saying that the data is essentially opaque.
Isn't the point of any RFC on the standards track to promote
interoperability? What good is an RFC that says "consult as yet
unwritten specifications from undetermined sources to handle the data
standardized by this RFC"? Isn't the first sanity test of a standard
whether one can determine if an implementation is compliant? As far
as I can see, Eric Hall is saying that compliance of senders and
receivers of such messages could not be determined until some.
Aren't there already enough opague application data MIME types?
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf