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

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 May 2012 15:52:21 +1000

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/

---

From: Ned Freed <[email-masked]>
Date: Wed, 16 May 2012 09:24:15 -0700 (PDT)

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

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

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

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 May 2012 22:17:44 +0100

Hi Ned,
Commenting on one specific point:

> how to implement the details.

I didn't get the "not in the registry" part. I suspect this is not entirely clear in the document.

---

From: Ned Freed <[email-masked]>
Date: Wed, 16 May 2012 14:26:07 -0700 (PDT)

>From the section on provisional registries:

  Upon receipt of a provisional registration, IANA will check the name and
  contact information, then publish the registration in a separate provisional
  registration list.

Note the use of the term "separate".

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 May 2012 22:34:34 +0100

Hi Ned,

> Note the use of the term "separate".

I read "separate list" as still being a part of the registry. Question: did you envision that IANA might decide not to make this separate list public (as one of the options)?

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 May 2012 10:33:00 +1000

Hi Ned,

Some responses inline.

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

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

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

> an update, you're going to have to specify changes you want on a case by case

Thanks, understood.

> a little silly at this point, but that's also irrelevant.)

It sounds like a reference will fix this.

> emerges I'm not going to change it.

As is entirely proper.

> is talking about vendor and personal tree registrations, and it is also

Ah, apologies; I misread that. Comment withdrawn.

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

> given the state of our core IPR documents even that might not be sufficient.

Agreed, on both counts.

> Per the above, this is inappropriate.

See above.

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

> you then have to qualify it, and that drags in a bunch of issues and results

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

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

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

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

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

> types MUST function as labels for actual media formats."

See above. 

>> assigned additional media types..."

See above.

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

>> important enough to be higher in the document (e.g., the introduction), rather

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

---

From: Ned Freed <[email-masked]>
Date: Wed, 16 May 2012 17:21:31 -0700 (PDT)

> I read "separate list" as still being a part of the registry.

Well, in a key sense it is: The namespace is shared. There's no point to
provisional registrations if it isn't. Whether you want to call it one single
registry containing two separate lists or two registries sharing a namespace is
syntactic detail I just can't get excited about. And none of this is relevant
to the original point anyway.

> Question: did you envision that IANA might decide not to make this separate
> list public (as one of the options)?

This is now getting silly. Of course the list is public. And no, there is no
need to state that explicitly. Have you ever seen a statement in an IANA
considerations section saying "this information needs to be made public"? I
seriously doubt you can point to even a single example.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Wed, 16 May 2012 17:55:33 -0700 (PDT)

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

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

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

No, it uses them when a disctinction needs to be made. That's not
inconsistency.

> That's fine, but it's not used consistently now.

I never said it was. In fact I explicitly said the opposite.

> Picking a random example,
> 4.2.1 starts with:

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

That's one of the changes I've already made. (Similar changes need to be
made in all the similar sections, of course.)

> It sounds like a reference will fix this.

Well, it really doesn't fix the underlying problem, but it's the best we can
do here.

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

So timely that AFIAK the court has yet to rule ;-) Anyway, that's entirely
reasonable - if the IESG feels this needs attention either here or elsewhere
they can figure how to deal with it. I'm just glad I don't have to deal with it
now.

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

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.

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

On further consideration, this approach actually allows us to use a MUST
without dragging in a lot of additional text. (There was a point when this
material was in a couple of other places in the text.)

There may be an issue with normative language in an appendix, but (a) This
doesn't change that, and (b) That can be addressed easily if someone objects.
And I can get rid of the bit about what an unfaceted name is now that that's
explained elsewhere.

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

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

Added.

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

Fair point.

> "A security analysis MUST state..."

I don't really see how that addresses the issue, but it also seems harmless, so
... added.

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

> See above.

Ditto.

> See above.

Ditto.

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

> Because a reader familiarising themselves with the registry might want to

Feel free to include that in your provided text.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 May 2012 17:13:37 +1000

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

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

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

> but we never managed to do that.

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

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

> they are intermixed, no matter how well they are labelled.

Once they're registered, they are real.

Thanks,

---

From: t.petch <[email-masked]>
Date: Thu, 17 May 2012 10:02:52 +0100

----- Original Message -----
From: "Mark Nottingham" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cc: "IESG IESG" <[email-masked]>; "IETF Apps Discuss"
<[email-masked]>;
<[email-masked]>
Sent: Thursday, May 17, 2012 8:13 AM

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

Don't know if it is an improvement, but I look to remove adverbs from
formal writing, and put the action into verbs; applying the latter, I
would say

"This document defines  the procedures to be used to register media
types  in the Internet Assigned Numbers Authority (IANA) central
registry."

More generally, I think that your points about comprehension are well
made, that the target audience is one that may not be familiar with
nuances of the IETF, IANA and MIME etc - in fact, they may not have a
clue about MIME or HTTP - and so being consistent and clear in
terminology is needed.  (I find it a common problem when experts write
for experts that the terminology is used loosely, something that experts
cope well with, others do not).

Taking Ned's point about this is about registering, nothing more, I
would spell that out explicitly, adding to the end of your text,
something like

"This document specifies the procedures for registering media types, and
is not concerned with the nature or specification of those types; for
the latter, see such documents as RFC2046."

And yes, I do believe it is worth getting the Introduction as right as
we can; for me, it is not nit-picking to fine tune the words there, as
it might be in, say, the Security Considerations.

Tom Petch

> snip>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 May 2012 09:06:23 -0400

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

That text is Ned's original as tweaked by my suggestion, so it's at
least half mine.  Let me explain, and we can see if there's a better
way to say it.

Look above that, and see that we have cases 1 and 2: case 1 involves
IETF registrations, and case 2 involves registrations by other SDOs.
There are then two paragraphs that say, "the first procedure" and "in
the second case", also referring to (1) and (2).  I think you're OK
with that.  Now, this text is again referring to the first case (and
the next graf addresses the second).  The bit about "the IETF itself"
is meant to be as opposed to other SDOs, and is meant to include the
IAB, IRTF, and even Independent streams.

As I look at it again, I think it might be better to fold these two
paragraphs into the previous two.  How does this look, replacing the
four paragraphs after the two numbered bullets?:

-------------------------------------
   The first procedure is used for registering registrations from IETF
   Consensus documents, or in rare cases when registering a
   grandfathered (see Appendix A) and/or otherwise incomplete
   registration is in the interest of the Internet community.  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.

   In the second case the IESG makes a one time decision on whether the
   registration submitter represents a recognized standards body; after
   that, a Media Types Reviewer (Designated Expert or a group of
   Designated Experts) performs the Expert Review as specified in this
   document.  Subsequent submissions from the same source do not involve
   the IESG.  The format MUST be described by a formal standards
   specification produced by the submitting standards body.
-------------------------------------

Ned might prefer that the documentation requirements remain in their
own paragraphs, in which case we might just replace "In the case of
registration for the IETF itself" with "In case (1), above," or some
such.  But I kind of like the version that merges these paragraphs.

What do yous guys think?

Barry

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 May 2012 18:25:17 -0700 (PDT)

> > stream, so the first and second sentences aren't well-aligned.

Actually, that's not true. As noted below, the IAB stream is a different stream
yet pretty clearly part of the IETF. But it is entirely possible for a document
in the Independent Stream to be produced and published at the instigation of
the IETF and intended for the IETF's benefit.

> such.  But I kind of like the version that merges these paragraphs.

No, this is better because (1) It's shorter and (2) It groups the materal
relevant to a particular procedure together. However, it orphans the next
paragraph that also discusses IETF documents. But there's no problem making
that part of the first paragraph, which gives us:

   The first procedure is used for registering registrations from IETF
   Consensus documents, or in rare cases when registering a
   grandfathered (see Appendix A) and/or otherwise incomplete
   registration is in the interest of the Internet community.  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.  A registration can be either in a standalone
   "registration only" RFC or incorporated into a more general
   specification of some sort.

I could maintain the split of the first paragraph, but beyond that ... please
consider the audience. This is not talking to some random person who wants to
register something; it's talking to people who involved in a standards process.
For better or worse, a barrier every standards process I've ever seen - and
I've been involved in several - imposes on participants is a basic
understanding of that process. So all this wordsmithing is accomplishing ...
what, exactly?

Anyway, modulo the paragraphing, I'm now going to regard this as closed 
unless someone comes up with a *really* cogent argument to make further
changes.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 May 2012 21:01:55 -0700 (PDT)

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

With the exception of the example, which I think is unnecessary, this basically
seem fine to me. I don't see it as much of an improvement to be honest, but the
one thing it does do that I like is that by talking about the location of the
registry I can eliminate the section that does that.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 May 2012 14:15:19 +1000

I'm OK with removing the example.

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 May 2012 21:05:43 -0700 (PDT)

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

Of course they will. That's how IANA works. Please remember that it was IANA
that started the whole outside reviwer process; the IETF started writing it
down *long* after it was the norm. But I suppose there's no harm in adding a
clause making it explicit.

In any case, since the procedure has been in place for long time and AFAIK it
has never been used, the bigger problem is likely to be that IANA will have no
idea how to actually make the comment visible on the site, assuming a comment
is ever actually made.

> Once they're registered, they are real.

No, they most certainly are not. They aren't supposed to be deployed. That's
what real means to me in this context.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 May 2012 22:00:11 -0700 (PDT)

> types  in the Internet Assigned Numbers Authority (IANA) central

Seems reasonable to me, but now that I look closely, it needs a bit more
tweaking because this document both lays out the registration requirements
as well as specifying the actual procedure. I ended up with:

   This document specifies the criteria for media type registrations and
   defines the procedures to be used to register media types (Section 5) in
   the Internet Assigned Numbers Authority (IANA) central registry.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 May 2012 15:10:58 +0100

Hi Ned,

On 17/05/2012 01:21, Ned Freed wrote:
>> Hi Ned,
>>
>> On 16 May 2012, at 22:26, Ned Freed<[email-masked]>  wrote:
>>
>>>> Hi Ned,
>>>> On 16 May 2012, at 17:24, Ned Freed<[email-masked]>  wrote:
>>>>>
Actually it is relevant in my mind. IMHO, if provisional registrations 
are listed on the same page as permanent registrations, then abandoning 
a registration shouldn't cause the entry to just disappear.
> This is now getting silly. Of course the list is public.
Ok, maybe it is silly. But I've heard IANA people talking about private 
registrations of things like port numbers, which are hidden from the 
world until the product associated with such private registration is 
released.

But anyway, I do think that Section 5.2.1 is underspecified, in 
particular handling of abandoned registrations. But to settle this 
discussion I think we should ask Michelle from IANA about whether she 
understands what is required from IANA in case of provisional 
registrations.
> And no, there is no

---

From: Ned Freed <[email-masked]>
Date: Thu, 24 May 2012 09:49:09 -0700 (PDT)

> world until the product associated with such private registration is

I ask again: How many registration setup specifications have you seen that make
a point of stating that the information they cantain is supposed to be public?
You have yet to provide a single example. And a particularly relevant
counterexample is RFC 3864, which set up the provisional header field registry.
Nowhere did the IANA directions in that document say that the registry needed
to be public, yet it ended up that way. So the default is clearly public and an
explicit statement is required for a registry to be private.

But that said, this nonsense needs to stop, and if changing the wording is the
only way to accomplish that, so be it. How about:

  Standardization processes often take considerable time to complete. In order
  to facilitate prototyping and testing it is often helpful to assign
  identifiers, including but not limited to media types, early in the process.
  This way identifiers used during standards development can remain unchanged
  once the process is complete and implementations and documentation do not
  have to be updated.

  Accordingly, a provisional registration process is provided to support early
  assignment of media type names in the standards tree. A provisional
  registration MAY be submitted to IANA for standards tree types. The only
  required fields in such registrations are the media type name and contact
  information (including the standards body name).

  Upon receipt of a provisional registration, IANA will check the name and
  contact information, then publish the registration in a separate publicly
  visible provisional registration list.

  Provisional registrations MAY be updated or abandoned at any time. When this
  happens the media type is no longer registered in any sense; it can
  subsequently be registered just like any other unassigned media type name.

This intentionally leaves open whether or not any indication of abandoned
registrations should be visible. That can and should be IANA's call.

Does this work for you?

				Ned

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 May 2012 13:47:53 -0400

--On Thursday, May 24, 2012 09:49 -0700 Ned Freed
<[email-masked]> wrote:

>> Ok, maybe it is silly. But I've heard IANA people talking
>> about private registrations of things like port numbers,
>> which are hidden from the world until the product associated
>> with such private registration is released.
> 
>...
 
>...
>...

FWIW, it works for me.

Also FWIW, IANA used to accept "hidden" or private entries in
some registries.  For them, either only the identifier was
visible to the public or nothing at all was visible but the name
or number would not be available for reuse or use by others.  In
those cases, IANA required documentation supporting the
registration and descriptions of what it was for, but was
willing to keep those confidential (under NDA) for some
negotiated period of time.

As far as I know, that practice ended with the transfer of IANA
responsibility from USC-ISI to ICANN.  Answers to questions in
the first half of the last decade indicated that it was no
longer being done; if that has changed more recently to
reinstate the older practice, I don't believe the community (or
even the IAB) has been told about it and believe that both would
have been.

More important, as Ned points out, this really has nothing to do
with the present document -- there are all sorts of obvious
things it could say that it doesn't.  Statements like
"registration data are public except maybe in very unusual cases
that the registry-creating spec must explicitly enable and this
media type registry specification doesn't do that" and "the IANA
doesn't get to decide on the validity of an IESG determination
of consensus for for a IETF-based standards track registration"
are certainly on that list of obvious things that shouldn't need
debate or writing down, but so is "no registrations will be
updated on the 29th of February in odd-numbered years".

While the material has been restructured and reorganized several
times to meet changing needs, there are many basic principles
that are unchanged since the registration provisions of RFC
1590.  Might it be reasonable to suggest that, if no real and
substantive problems have turned up in those basic principles in
the last 18 years, an "ain't broke, doesn't need fixing"
guideline might apply?

   john

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 May 2012 10:08:22 +1000

>>  visible provisional registration list.

For the record, it doesn't work for me. Having a separate list forces people to check two separate lists, causing confusion and reducing the overall value of the registry (we already have a problem with people using Wikipedia instead of IANA).

Regards,

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 May 2012 18:23:59 -0600

On 5/24/12 6:08 PM, Mark Nottingham wrote:
>>> Upon receipt of a provisional registration, IANA will check the
>>> name and contact information, then publish the registration in a 
>>> separate publicly visible provisional registration list. ... Does
>>> this work for you?
>> 
>> FWIW, it works for me.
> 
> For the record, it doesn't work for me. Having a separate list forces
> people to check two separate lists, causing confusion and reducing
> the overall value of the registry (we already have a problem with
> people using Wikipedia instead of IANA).

+1

---

From: Ned Freed <[email-masked]>
Date: Thu, 24 May 2012 18:17:12 -0700 (PDT)

The point of the provisional registry is to reserve the name so standards
can be written and trial implementations developed without having to go
through a subsequent name change.

It is *not* there so that random people can look up and start using the type.
Which is very likely to happen if there isn't a clean separation.

If the IESG feels differently, we'll see. But I am absolutely and totally
opposed to these not being separate, and at least one of my coauthors (John)
has indicated that if anything, he's even more opposed to it than I am.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 May 2012 11:23:30 +1000

> has indicated that if anything, he's even more opposed to it than I am.

I think the underlying problem is that "provisional" is used in a different sense in RFC3864. I'm not saying it's the *right* sense, but having two different meanings for the same term in somewhat related registries isn't optimal.

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 May 2012 21:51:56 -0400

--On Friday, May 25, 2012 11:23 +1000 Mark Nottingham
<[email-masked]> wrote:

>>>>>> Upon receipt of a provisional registration, IANA will
>>>>>> check the name and contact information, then publish the
>>>>>> registration in a separate publicly visible provisional
>>>>>> registration list. ... Does this work for you?
>>>>> 
>>>>> FWIW, it works for me.
>>>> 
>>>> For the record, it doesn't work for me. Having a separate
>>>> list forces people to check two separate lists, causing
>>>> confusion and reducing the overall value of the registry
>>>> (we already have a problem with people using Wikipedia
>>>> instead of IANA).
>> 
>>> +1
>> 
>> The point of the provisional registry is to reserve the name
>> so standards can be written and trial implementations
>> developed without having to go through a subsequent name
>> change.
>> 
>> It is *not* there so that random people can look up and start
>> using the type. Which is very likely to happen if there isn't
>> a clean separation.
>> 
>> If the IESG feels differently, we'll see. But I am absolutely
>> and totally opposed to these not being separate, and at least
>> one of my coauthors (John) has indicated that if anything,
>> he's even more opposed to it than I am.
> 
> 
> I think the underlying problem is that "provisional" is used
> in a different sense in RFC3864. I'm not saying it's the
> *right* sense, but having two different meanings for the same
> term in somewhat related registries isn't optimal.

Yes.  The 3864 definition, as I understand it, is closer to
"trial use, incomplete information, might change" while this is,
as Ned points out, is closer to "reserve name during
standardization".  If you think that is excessively confusing,
I'd be open to calling this one something more like "temporarily
reserved" or, to borrow a note from a couple of ISO Maintenance
Agencies "exceptionally reserved", rather than "provisional".
My objection, as Ned suggested, is any hint of "this will be
standardized so start using it based on what you think the
standard will be.    Those who want the standards track
registrations need to accept that they are tied to a consensus
process and that those not only take time but can result in
changes.   Those who need "fast" and/or "open to implementation
even the definitions are woefully incomplete" should use the
vendor or personal trees.

   john

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 May 2012 12:43:18 +1000

> vendor or personal trees.

Works for me.

---

From: Ned Freed <[email-masked]>
Date: Thu, 24 May 2012 18:30:51 -0700 (PDT)

> I think the underlying problem is that "provisional" is used in a different
> sense in RFC3864. I'm not saying it's the *right* sense, but having two
> different meanings for the same term in somewhat related registries isn't
> optimal.

dictionary.com defines provisional as:

1. providing  or serving for the time being only; existing only until
   permanently or properly replaced; temporary: a provisional government.

2. accepted or adopted tentatively; conditional; probationary.

Seems to me these definitions both fit the provisional media type registry
quite well, especially the first one.

As for RFC 3864, the provisional registory is pretty clearly intended to be
used not just for entries where the intent is to move them to the permanent
registory eventually, but also for entries that are, well, permanently
provisional, which per the above definition is close to, if not actually, an
oxymoron. Maybe my reading is wrong and such registrations weren't the intent,
but since the registry has been used that way (RFC 6109 is a good example of
this), that seems to be a moot point.

So the terminology misuse seems to be on the part of RFC 3864. Per an earlier
message from Graham Klyne on this general topic, I would suggest that in the
future these not-really-provisional provisional registries be called
"informational" registries instead, since that term seems to fit their purpose
far better than the term "provisional" does.

Of course it is too late to change either RFC 3864 (or RFC 4395, which is very
similar), but redefining the word "provisional" is also a bit beyond our
purview. So we really have no choice but to live with the discrepancy.

Getting back to the provisional media types registry, if we really wanted an
alternative "pro tem" is also a good fit, but  changing the terminology to what
pretty much has to be a synonym for provisional doesn't really solve the
problem.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2012 11:50:05 +1000

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.

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? 

I suppose they could carefully construct a "use this part but not this bit," but that doesn't seem like a good use for anyone's time. And, it results in a lot of ambiguous specs from organisations that aren't as rigorous as the IETF (and perhaps a few from within).

Anyway, fodder for 2045bis, if it happens one day. 

Regards,