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

[Ned Freed <[e-mail]>]

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

I want to start by reiterating a point I've made repeatedly in the discussions
of this draft, but seems to have missed in this review: This is a registration
process BCP. It is not a protocol specification, nor is it a specification of
either media types or media type suffixes. Media types were specified in RFC
2046 (in considerable details) and protocol suffixes were specified in RFC 3023.

As such, it is entirely inappropriate for this document to spend time carefully
defining terms, justifying choices, or introducing new terminology. For one
thing, it's a violation of what's supposed to be in a BCP. And for another,
process documents need to focus on the *process*. Detailed specification
material is simply extraneous detail to someone just looking to use the
process. And this is plenty long enough already; making it longer in order to
include such material would be profoundly unhelpful.

Now, it is necessarily the case that when the underlying specification is old
(as is the case with RFC 2046), or is being expanded on or generalized (as is
the case with the current specification of media type suffixes) that some
liberties need to be allowed, and some have indeed been taken here. But this is
an unavoidable consequence of the way our processes work. The right way to
address such issues is to revise the core documents and bring them up to date,
but the reality is there's huge cost associated with prying open core documents
to update them in regards to this sort of stuff.

If someone wants to fix that, I respectfully suggest that they work towards
defining some sort of carefully scoped updating process that doesn't require
forming a working group, because something like that is what it's going to
take to address several of the issues raised here.

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

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'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"

The correct term here is indeed "media type", and this case constitutes the
vast majority of usage.

>  * "subtype" -- e.g., "plain"

"subtype" usually followed by "name".

>  * "major type" -- e.g., "text" (currently called a "top-level type" sporadically)

The word "major" currently appears nowhere in the document. As such, this would
be introducing a completely new specification term, and per the above, that's
should not happen unless there's simply no alternative. The current text uses
either type name or top-level type name, depending on whether or not there's a
possibility of confusion with the full name of a media type, and that's how it
needs to stay.

I'm not particularly fond of top-level type name myself, but it's what we have.

>  * "media format" -- i.e., the format identified by the media type (or "content" -- just pick one)

Media type format or format is used in most places. There are some places where
media type content is used for slightly different purposes; this is an
intentional distinction.

Anyway, I did a pass through the document and changed some of these - there
some that were indeed incorrect. If you object to any of the usage after I post
an update, you're going to have to specify changes you want on a case by case
basis.

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

First of all, the "this document" in this text is simply incorrect. RFC 2046 is
the specification that imposes this restriction, and I'll change the text to
make that clear.

But per my initial point, this is a registration process, and changing or
removing a specification restriction here is not allowed. This document does
not and cannot update RFC 2046. (I personaly happen to think the restriction is
a little silly at this point, but that's also irrelevant.)

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

This document didn't introduce them; RFC 3023 did. See above for why the sort
of text you're asking for doesn't belong here.

As for this being the right registration process, that's a consensus issue, not
a document editing issue, and certainly not at this stage. I've heard no
objections other than this one, and if past experience is any indication,
worries about "opening the floodgates" have rarely proved to be well founded.
If fact we usually end up with the opposite: Overly onerous processes that
prevent people from getting things done.
 
Anyway, if you want to try and get consensus that the current process is
insufficiently restrictive feel free to do so. But until such a consensus
emerges I'm not going to change it.

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

They do no such thing. The former paragraph is talking about standards tree
registrations, and explicitly states that this is what it is doing. The latter
is talking about vendor and personal tree registrations, and it is also
explicit about that.

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

I kind of agree, but this issue should have raised long before last call.
Constructing text to deal with a new IPR issue, especially one which AFAICT
isn't really addressed by BCPs 78 and 79, ***FAR*** exceeds anything that
should be attempted by a document editor on their own during last call.

The only way to handle this would be to push the document back to the working
group with the specific agenda to address copyright issues, and in this case
given the state of our core IPR documents even that might not be sufficient.

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

Per the above, this is inappropriate.

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

I'll add a reference to RFC 4844, but I like the original text a lot better.
In particular, the term "Document Stream" is nowhere near as familiar as the
terms used in the original text.

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

I thought about doing this. The problem with making it a MUST is that
you then have to qualify it, and that drags in a bunch of issues and results
in repetitive text.

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

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

Seems reasonabl. Added.

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

Seems reasonable. Changed.

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

This falls out of the rules for who can do updates. If you really think
something needs to be added, you'll need to suggest text.

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

It's been mentioned, but at this point this is an issue for IANA, not for this
document. I see no consensus to require that IANA set up such a thing and no
apetite for specifying how it should work. (Since this seems to transcend media
types perhaps it would make more sense as part of the HAPPIANA work.)

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

That's not how the rules work, since there's the "not assessed" escape
hatch, but yes, if you elect not to use the hatch, you have to include
that, and it is enforced.

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

Yes it is, but the opposite also holds, so I'll reword it.

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

> Nits:

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

Not appropriate.

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

Not appropriate.

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

Good idea; added.

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

Provisional registrations are not in the registry. It's up to IANA as to
how to implement the details.

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

I don't really see why.

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

Seems reasonable. Done.

				Ned