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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf