--On Tuesday, 17 August, 2004 13:05 -0400 Valdis.Kletnieks@xxxxxx wrote: >... > So - where is the *one true canonical* definition of an mbox > that actually answers all these basic questions that an > implementer *needs* to know the answer to? Or, as an alternative, where is the set of required parameters and values that would give the recipient at least a strong clue as to which of many definitions and variations is in use? To be clear about this, I think there are three choices which we might prefer in descending order: (1) There is a single canonical "wire" format in which these things are transmitted. It is the responsibility of the sender to get from whatever is used locally into that form and the responsibility of the recipient to get from that form into whatever is needed locally. And the wire format is precisely defined, without handwaving or system-specific variations. (2) The content-type specifies a conceptual form ("application/mbox") but has _required_ parameters that specify the specific form being transmitted. The recipient does not require either out of band information or heuristics on the body part content itself to figure out what was received and whether local facilities exist to decode it. (3) These might as well be sent with application/octet-stream, with optional file name, etc., information. I just don't see any other options that are consistent with the media type model. john _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf