Media Type Specifications and Registration Procedures
RFC 6838

Note: This ballot was opened for revision 13 and is now closed.

(Barry Leiba) Yes

(Pete Resnick) Yes

Comment (2012-06-19 for -13)
No email
send info
A fresh look is always nice. This looks pretty darn reasonable. A few questions:


   Standards-tree registrations from recognized standards bodies may be
   submitted directly to the IANA, where they will undergo Expert Review
   [RFC5226] prior to approval.
Why is it "may be" in the above? Ought it be "should be" or "are"?

5.1 and 6: I know there was some discussion about having IANA take care of posting to ietf-types, in particular for standards-tree non-IETF registrations. Was it decided that this was *not* going to be done? Or was it simply idle chatting about a potential change but nothing ever came of it? Just curious.

5.2.1 The mechanism for abandoning provisional registrations was not clear to me. Do you mean they are considered abandoned after some period of time, or an applicant can explicitly abandon them, or something else? It's not spelled out.

(Robert Sparks) (was Discuss) Yes

Comment (2012-06-20 for -13)
No email
send info
(Updating to reflect email discussion, clearing the discuss point. The list discussion already describes resolution for the remaining comments below)

In paragraph 5 of section 4.2.1  where it says "all text/* registrations", should it say "all new text/* registrations"? (Similar to how mime-default-charset allowed for existing registrations that didn't follow these instructions.)

Very minor nits:

There are a few uses of RFC2119 keywords carried forward from RFC4288 that you might consider removing.
The SHOULDs in the first paragraphs of section 4.5 are what motivated this comment. I understand if you
don't want to make such a low-yield change at this point in the process though.

The historical note (section 1.1) was copied forward from the introduction to rfc4288 without modification.
It says things like "has now been moved" and "this revision" where "now" and "this" were written with 4288 
in mind. 

Please grammar check the last sentence of 4.2.7

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-06-15 for -13)
No email
send info
Thank you for Appendix B which made reviewing a lot easier.

(Stephen Farrell) No Objection

Comment (2012-06-18 for -13)
No email
send info
- "faceted name" could be defined more clearly, I didn't get the
"tree.subtree...subtype" notation in section 3. The draft is readable
even so, but that was a bit confusing.

- Just wondering, if another SDO or a vendor registers a media-type and
then updates their specification for that, is there an expectation of
backwards compatibility? Is that something the designated expert ought
take into account?

- 3.4, typo s/considered to members/considered to be members/

- 4.1, "better thought of as..." is a bit vague, but I guess this was
thrashed by the appsawg. If not, (and only if not), would this be
better with a more objective definition of what's not allowed, and with
some 2119 language for the designated expert to follow?

- 4.2 says that different names for the same thing "is discouraged."
Why isn't that a SHOULD NOT with the exception being legacy stuff and
things that escape into the wild and get too big to ignore?

- 4.6 says "MUST NOT be confused with" which isn't really meaningful
2119 language - if you want to outlaw saying there are "no security
issues" then just saying that might be a good, if odd, MUST NOT. I'd
say you could strike the 2119 lanaguage here though.

- 4.12 refers to MacOSFileTypes, when you go there it says Apple no
longer update that page, so a) is that the best reference? b) should
this draft say that those file type codes are legacy stuff (if that's
the case, I'm not a Mac user:-).

- 5.3 doesn't actually say how the media types reviewer makes the
decision public which I think it ought (presumably via a mail to IANA
and some mailing list?). It also doesn't specify any time limits or
goals for responsiveness, which would be nice.

- 5.6 could usefully reference a "good" example registration (maybe as
a pointer to somewhere or a new appendix). I think that'd help people
who read this later. (Same for section 6, if one exists.)

- section 6 assumes (I think), but doesn't say that the same expert
does this, is appointed by apps ADs etc. Worth adding?

- section 7 might usefully provide a reference to some known
vulnerabilities that have been seen in complex media types. For
example, saying something like: "As noted earlier, complex media types
can and have caused real security problems, for an example see
[CVE-2010-3116]." That [1] was just the first related CVE I saw in a
search, anything similar would do fine. The idea is just to emphasise
that these are real problems in real systems.


(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-06-18 for -13)
No email
send info
  Section 6 says:
  > 2.  If there is no entry for their suffix scheme, fill out the
  > template (specified in Section 6.2) and include that with the
  > media type registration.  The template may be contained in an
  > Internet Draft, alone or as part of some other protocol
  > specification.  The template may also be submitted in some other
  > form (as part of another document or as a stand-alone document),
  > but the contents will be treated as an "IETF Contribution" under
  > the guidelines of BCP 78 [RFC5378].
  If a document other than an Internet-Draft is used, how do the
  authors acknowledge that an IETF contribution is being made?

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection