I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see  <http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate>).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-appsawg-media-type-regs-07
Title: Media Type Specifications and Registration Procedures
Reviewer: Mark Nottingham
Review Date: 2012-05-16

Summary: This draft is almost ready for publication as a Best Current Practice RFC, but has a few issues that should be fixed before publication.

Major Issues: 

* 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).

I'd suggest that in common use, "media type" means the entire label, which leads to a set of terminology something like:
 * "media type" -- e.g., "text/plain"
 * "subtype" -- e.g., "plain"
 * "major type" -- e.g., "text" (currently called a "top-level type" sporadically)
 * "media format" -- i.e., the format identified by the media type (or "content" -- just pick one)

* In Section 4.2.4: "Note that although in general this document strongly discourages the mixing of multiple media in a single body..." This kind of architectural advice seems out of place in this document. Recommend either justifying this position, or removing it.

* Section 4.2.8 introduces structured suffixes. These may be very popular, but I don't see any description of their value, nor appropriate vs. inappropriate use (and I suspect there are many opportunities for abuse here). Also, I suspect that having many of these will be very counterproductive, and therefore wonder whether DE is the appropriate registry policy here.

* Section 4.4, the second and third paragraphs contradict each other. The former says that a public specification MUST exist, and MUST have sufficient detail for interop, whereas the latter gives permission to avoid this. Either turn them into SHOULDs or otherwise refine the MUSTs.

* Section 4.4 covers patents but not copyrights. Given that some people now believe it's possible to copyright an API, and media types form a key portion of some styles of APIs, it would seem prudent to have guidelines here. At a minimum, I'd expect that I wouldn't have to worry about copyright issues when using a media type in the standards tree.


Minor Issues: 

* It would be useful to start the document with a section explaining what a media type is, and it's basic structure (type/subtype, organised into trees, with optional parameters). Right now, it jumps right in to registration procedures, citing terms like "tree" and "subtype" without identifying them (in sections 2 and 3, respectively). This need not be long; one or two small paragraphs would suffice.

* In Section 3.3:

"""
   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, 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.
"""

This is confusing, and it uses a number of terms without defining or referencing them. Suggest:

"""
Registrations on behalf of the IETF are published as RFCs in the IETF Document Stream [RFC4844], thereby representing IETF consensus. Registrations published as RFCs in other Document Streams are also allowed, but require IESG approval.
"""

* In Section 3.3: "Media types in the standards tree are normally denoted by names that are not explicitly faceted..."  It seems like there should be a requirement here; although it's understood that there are cases where this isn't true, it would be useful to give clear guidance.

* 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? 

* In Section 4.2.3, add "The subtype names the specific audio format."

* Section 4.2.5 cites application/postscript in such a way as if it defines *the* security considerations for active content; it's really an example, and should be labeled as such.

* Section 4.3 would do well to note that third parties cannot arbitrarily add parameters to existing types without going through the appropriate process; this comes up quite often, as people assume that there's a default "ignore" rule here.

* Section 4.5 calls for interoperability considerations sections to be "subject to continuing evaluation." This seems like an excellent opportunity to introduce a per-registration wiki page; has this been discussed? (not that it'd be necessary to require it in the draft, more just curious)

* Section 4.6: "All registrations MUST state whether or not they employ such "active content"..." Is it reasonable to expect this? I.e., will the DE be rejecting requests that don't have a boilerplate "This format does not employ active content."?

* Section 4.6: "Types not requiring such services SHOULD document this in their security considerations." Is the "not" here intentional?

* 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?


Nits: 

* Section 4.1 "Media types MUST function as actual media formats." --> "Media types MUST function as labels for actual media formats."

* Section 4.2 "While it is possible for a given media type to be assigned additional names..." --> "While it is possible for a given format to be assigned additional media types..."

* Section 5 is quite deeply buried in the document. Adding a reference from the introduction would give an opportunity to highlight it to the audience that needs it.

* Section 5.2.1 "Provisional registrations MAY be updated or abandoned at any time." How does this happen? How is it reflected in the registry? "OBSOLETE"?

* Section 5.5: Similar to comments above, the URL for the registry is important enough to be higher in the document (e.g., the introduction), rather than buried down here. 

* Section 5.6: Move the last paragraph to be after the second, to make it more clear how a registration is obsoleted (the intervening two paragraphs talk about reassignment).


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