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

[Mark Nottingham <[e-mail]>]

Hi Ned,

Some responses inline.

On 17/05/2012, at 2:24 AM, Ned Freed wrote:
> 
> 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.

I disagree; for better or worse, this will be the only document that many people refer to when thinking about media types, especially since 2046 is a MIME document, and media types (as already pointed out in the document) are bigger than MIME.

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.


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

Note that I'm not suggesting any new terms be introduced here; the draft already uses "label" and "media format"; it just doesn't use them consistently.


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

That's fine, but it's not used consistently now. Picking a random example, 4.2.1 starts with:

   The "text" media type is intended for sending material that is
   principally textual in form.

When a much clearer rendering would be:

   The "text" top-level type is intended...

or better yet:

   Media types with the "text" top-level type are intended...


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

Thanks, understood.


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

It sounds like a reference will fix this.


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

As is entirely proper.


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

Ah, apologies; I misread that. Comment withdrawn.


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

These are review comments for the IESG; I'm not necessarily asking you to change it, merely noting a potential (and very timely) problem.


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

Agreed, on both counts.


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

See above.


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

As you point out above, having this document introduce its own terminology doesn't do anyone any good. "Familiar" is of course relative to the reader.


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

[ sorry, that should be 3.1]

I was thinking more of a SHOULD. E.g.,

"Media types in the standards tree SHOULD NOT have faceted names, unless they are grandfathered in using the process described in Appendix A."


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


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

New paragraph at the end of 4.3:

"""
Changes to parameters (including the introduction of new ones) is managed in the same manner as other changes to the media type; see 5.6 Change Procedures.
"""

(normally I wouldn't suggest adding this kind of redundant "reminder" information, but IME this is not well understood)


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

That's not clear, because the requirement starts with "All registrations MUST state..."

I'd suggest:

"A security analysis MUST state..."


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


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

See above. 


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

See above.


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

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.


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


Because a reader familiarising themselves with the registry might want to actually find it.


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