Media Type Specifications and Registration Procedures
draft-ietf-appsawg-media-type-regs-14

Thank you for Appendix B which made reviewing a lot easier.

  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?

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

   [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3116