--On Tuesday, 17 August, 2004 13:05 -0400
Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu 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