On 8/10/2004 10:59 PM, Philip Guenther wrote:
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.
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Ietf mailing list