Subject: Re: [apps-discuss] RFC2045 terminology [was: APPSDIR review of draft-ietf-appsawg-media-type-regs-07]

From: Ned Freed <[email-masked]>
Date: Sat, 02 Jun 2012 16:43:46 -0700 (PDT)

> On 17/05/2012, at 2:24 AM, Ned Freed wrote:

> >> * Throughout, "media type" is used somewhat freely to mean all of: a complete
> >> media type label, the format that it identifies, and a top-level type. This is
> >> needlessly confusing. It would be extremely helpful to explicitly define terms
> >> and use them consistently throughout. In particular, "top-level type" is used
> >> sometimes, whereas the plain "media type" is used elsewhere. "content type"
> >> sneaks in sometimes too (again, inconsistently).
> >
> > Some of this is intentional. In particular, the term "media type" is used
> > interchangeably (or, if you prefer, sloppily) to refer to media types in the
> > abstract and to the label for a media type. I've tried writing it the other
> > way, and the resulting prose is stilted and confusing.

> Just to put a pin in this, I was e-mailed this morning about what a "media
> type" is on the type parameter in RFC5988, and went to 2048 as a reference,
> where I came across:

> > 5.  Content-Type Header Field
> >
> >    The purpose of the Content-Type field is to describe the data
> >    contained in the body fully enough that the receiving user agent can
> >    pick an appropriate agent or mechanism to present the data to the
> >    user, or otherwise deal with the data in an appropriate manner. The
> >    value in this field is called a media type.
> >
> [...]
> >
> >    The Content-Type header field specifies the nature of the data in the
> >    body of an entity by giving media type and subtype identifiers, and
> >    by providing auxiliary information that may be required for certain
> >    media types.  After the media type and subtype names, the remainder
> >    of the header field is simply a set of parameters, specified in an
> >    attribute=value notation.  The ordering of parameters is not
> >    significant.

> [...]
> >    In general, the top-level media type is used to declare the general
> >    type of data, while the subtype specifies a specific format for that
> >    type of data.  Thus, a media type of "image/xyz" is enough to tell a
> >    user agent that the data is an image, even if the user agent has no
> >    knowledge of the specific image format "xyz".

> This demonstrates at least three different meanings of "media type." Note
> that the first paragraph explicitly defines a media type as "anything in the
> Content-Type header field value", including parameters.

This is what I tried to explain to you in my original response.

> Now, while a very careful reading of this in isolation makes it clear what's
> going on, what is a third party who wants to reference what a "media type" is
> for use in another field supposed to do?

That can be a very difficult question to answer, but in practice the difficulty
has *nothing* to do with the multiple meaning of the term "media type".

Rather, the difficulties in practice lie in the interaction between type and
parameter syntax, field syntax, and the underlying protocol. For example, there
are cases where a type/subtype name can be supplied but not any parameters.
(This one is a real problem, BTW.) There are cases where there are hard length
limits. There are cases where only a subset of the top-level types can be used.
There are cases where the transport imposes restrictions on the type content
(and encoding cannot always be used to address the issues). There are cases
where the list of allowed types must be explicitly enumerated.

As for issues of understanding, there are many. People often don't understand
what parameters are really for. (And it seems that absolutely nobody has even
heard of media features.) People put stuff under the wrong top-level type.
People try and register standards-tree types directly with IANA.

The issues list goes on and on and on. I've encountered all of these in
practice, quite a few of them multiple or even many times. But the one thing I
have yet to encounter - and I've been doing this for over 15 years - is any
real confusion caused by the *definition* of the term "media type".

To be sure, people have shown up who are confused what a media type is. But in
these cases it's quite clear they haven't read *any* of the relevant
specifications. And it's quite difficult to write a specification that canveys
knowledge without someone actually reading it.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Jun 2012 11:26:20 +1000

> knowledge without someone actually reading it.

Well, it's pretty clear we feel differently here; it's all moot until a 2045bis starts, if it does.

Cheers,

--
Mark Nottingham   http://www.mnot.net/