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

--On Friday, 13 August, 2004 11:33 -0400 "Eric A. Hall"
<ehall@ehsco.com> wrote:

>...
> Suggestions about parameters has come up before (John Klensin
> suggested it to me a couple of months ago). Unfortunately,
> these kind of helper tags attempt to define content rules
> rather than transfer rules, and therefore represent a
> non-trivial layer violation.

Whoops!   Whatever the other issues here,  content-type does
define content rules and not transfer rules (transfer rules are
captured in C-T-E), and parameters/hints on content-type are
just more content rules.   So I don't have any idea what you are
talking about when you refer to a layer violation.

To restate that position more generally, the purpose of having
content types is to permit the recipient  to figure out how to
parse/process the content.  To repeat Bruce's point from a
different perspective, if all that is intended is "here are some
nice bits, which someone has decided to call "mbox" without any
real semantics, and any information you are going to get about
how to process them is coming out of band and by agreement among
the communicating parties", then application/octet-stream is at
least nearly adequate.  From that point of view, if you want an
IETF type, you should either have to claim that all (or nearly
all) of the applications that process MBOX format critters can
process all variations on the format, or there really need to be
clues in either the type or the parameters.  Otherwise, you are
just creating a "gotcha" situation, and that is not what content
types are supposed to be able.

> They are analogous to using a
> "version=" tag for app/postscript and relying on that
> meta-information instead of embedded clue data. Obviously,
> content agents should be aware of the content formatting
> rules. [what happens when the helper meta-tags are lost?
> should the content agent NOT look at the content to make a
> determination? that's where the logic belongs in the first
> place, so putting it into the transfer layer is not only
> irrelevant it is possibly harmful.] This data should not be
> overflowed to the transfer agent except where it affects the
> transfer process proper, which is not the case with any of the
> suggested tags.

Again, in the context of MIME media type definitions, I have no
idea what you are talking about.

     john

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