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