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

[Mark Nottingham <[e-mail]>]

On 17/05/2012, at 10:55 AM, Ned Freed wrote:
> 
>> I'm not talking about re-defining the concepts, I'm saying that a quick,
>> non-normative summary of what they are, along with pointers to more detailed
>> information elsewhere, would help readers.
> 
> Then feel to suggest text.

Replace section 1 (Introduction) with:

"""
Recent Internet protocols have been carefully designed to be easily
extensible in certain ways. In particular, many protocols, including but
not limited to HTTP [RFC2616] and MIME [RFC2045], are capable of carrying
arbitrary labeled content.

The mechanism used to label such content is a media type, consisting of a
top-level type and a subtype, which is further structured into trees.
Optionally, media types can define companion data, known as parameters.

For example, 

  text/plain; charset=utf-8
  
has a top-level type of "text", a subtype of "plain", which places the media
type in the standards tree. Here, the "charset" parameter is serialised as it
would be in HTTP.

A registration process is needed for these labels, so that that the set of
such values are defined in a reasonably orderly, well-specified, and public
manner.

Therefore, this document defines media type specification and registration
procedures that use the Internet Assigned Numbers Authority (IANA) as a
central registry.

The media type registry managed by the procedures defined here can be found at
<http://www.iana.org/assignments/media-types/>.
"""

Just a suggestion, of course; I'm sure it can be improved upon.


>>>> * 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.
> 
>> I made such a proposal below ("Media types MUST function as labels for actual
>> media formats.") -- are you really saying that this is "stilted and
>> confusing"?
> 
> As a matter of fact, yes, that text is quite confusing. It implicitly says that
> the term "media type" refers to a label rather than an abstraction, and that
> contradicts other usage throughout the document.

Clearly, we're not going to agree on this, so I'll just let the various comments regarding terminology stand for consideration.


> Then I'm the one who is confused, because what in this text:
> 
>  In the case of registration for the IETF itself, the registration
>  proposal MUST be published as an RFC.  When the RFC is in the IETF
>  stream it is an IETF Consensus RFC <xref target="RFC4844"/> , which
>  can be on the Standards Track, a BCP, Informational, or Experimental.
>  Registrations published in non-IETF RFC streams are also allowed, and require
>  IESG approval.
> 
> is new terminology? "IETF stream" (4844), "IETF Consensus RFC" (2026 and 4844),
> "Standards Track", "BCP", "Informational", and "Experimental" (all 2026) are
> all well defined and widely used terms.

None of "IETF Consensus RFC", "IETF Consensus" or "Consensus RFC" occur in 2026 or 4844 AFAICT.

By definition, when an RFC is published "for the IETF itself", it is on the IETF stream, so the first and second sentences aren't well-aligned. 


>>>> * In Section 4.1, it cautions against transfer encodings being registered,
>>>> yet I see application/zlib being registered now
>>>> <https://datatracker.ietf.org/doc/draft-levine-application-gzip/>. Does this
>>>> need to be reconsidered, or that registration rejected?
>>> 
>>> No and not our call. Gzip is an exceptional case for various reasons. Of course
>>> it is entirely possible that the IESG will reject it on this basis.
> 
>> Yes. However, right now there's a MUST requirement in there. Is GZIP so
>> exceptional that a MUST can be violated, or should this be a SHOULD?
> 
> This is unchanged from RFC 4288, so it isn't new. And since GZIP is currently
> functioning as a media format in widespread real world practice, the MUST isn't
> really being violated. The part that's arguably breaking the rules is the part
> about it being "better thought of" as an encoding. Had we actually managed to
> define gzip-base64 at some point we have a real case against application/gzip,
> but we never managed to do that.

OK. I'll leave it to the IESG to worry about setting a precedent.


>>>> * Section 5.4 directs people to send comments on registered media types to
>>>> IANA. Isn't it more appropriate/straightforward to send them to the change
>>>> controller, optionally CC:ing the types list?
>>> 
>>> No, I don't think so. Sending it to IANA insures that it gets tracked.
> 
>> Is there an expectation that the comments will be collected, or that there
>> will be metrics for comments on a media type, or...? I don't see the benefit of
>> giving IANA yet another thing to do here.
> 
> That's the whole point - if the comment seems sensible, it gets added to the
> registration. If we send comments to change controller, I think there's a fair
> chance that's as far as they will go.

So, IANA becomes the arbiter of what's an applicable comment here? Is the assumption that they'll consult with the DE as appropriate?


>> I see. In that case, I'll add a comment that separating the provisional and
>> permanent registries doesn't work well, IME; we have a similar situation in the
>> Message Header registry, and forcing people to look into two lists makes it
>> confusing. I'd recommend a single, authoritative list, using the status field
>> to distinguish them.
> 
> I strongly disagree. I think the problem of provisionals being seen as real if
> they are intermixed, no matter how well they are labelled.


Once they're registered, they are real.


Thanks,

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