Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard

--On Tuesday, 17 August, 2004 13:05 -0400
Valdis.Kletnieks@vt.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

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf