[apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-04

[SM <[e-mail]>]

I'll defer to the authors for the following nits on 
draft-ietf-appsawg-media-type-regs-04.

In Section 3.1:

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

Suggested text:

    The first procedure is used for registering registrations from IETF
    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 proposed change aligns the text with the "MUST" in the first 
paragraph of Section 3.1.

   "In the case of registration for the IETF itself, the registration
    proposal MUST be published as an IETF Consensus RFC, which can be on
    the Standards Track, a BCP, Informational, or Experimental."

The text is redundant (see first paragraph of that 
section).  Depending on what the objective is, the above text could 
be modified to refer to "Standards Action" or "IETF Review".

In Section 3.2:

  "The vendor tree is used for media types associated with publicly
   available products."

Peter raised a question about whether Mozilla is a vendor.  It 
qualifies as a vendor.

In Section 3.4:

   'Subtype names with "x." as the first facet may be used for types
    intended exclusively for use in private, local environments.

As I-D.ietf-appsawg-xdash is a work product of this working group, it 
does not make sense to register "x." for use in private, local environment.

In Section 4.2.8:

   "The primary guideline for whether a structured type name suffix
    should be registerable is that it be described by a readily-available
    description, preferably within a document published by an established
    standards organization, and for which there's a reference that can be
    used in a References section of an RFC."

I suggest prefacing "References" with "normative".

In Section 4.2.9:

   "In some cases a single media type may have been widely deployed prior
    to registrion under multiple names."

Typo: registration.

   "However, a list of deprecated aliases the type is known by MAY
    be supplied as additional information in order to assist
    application in processing the media type properly."

Suggested text:

   to assist the software

In Section 4.4:

   "A precise and openly available specification of the format of each
    media type MUST exist for all types registered in the standards tree
    and MUST at a minimum be referenced by, if it is not actually
    included in, the media type registration proposal itself."


RFC 5226 has the following description for "Specification Required":

   "documented in a permanent and readily available public
    specification, in sufficient detail so that interoperability
    between independent implementations is possible"

It's less hassle to align the terms instead of trying to figure out 
what "precise" or "openly available" means.

Suggested text:

    A permanent and readily available publicly available specification, in
    sufficient detail so that interoperability between independent
    implementations is possible, of the format of each media type MUST
    exist for all types registered in the standards tree  and MUST at a
    minimum be referenced by, if it is not actually included in, the
    media type registration proposal itself.

   "As such, teferences to or inclusion of format specifications in"

Typo: references.

In Section 4.6:

   'The security considerations section of all registrations is subject
    to continuing evaluation and modification, and in particular MAY be
    extended by use of the "comments on media types" mechanism described
    in Section 5.4 below.'

Is the intent to have ongoing evaluation with any updated information 
added as comments?

BTW, "and modification" does not seem correct in the above.  Does it 
mean that a registration made through a specification would require 
an update of the specification?

In Section 4.10:

   "RFC publication of vendor and personal media type registrations
    is allowed but not required."

I suggest "encouraged" instead of "allowed".

   "Additionally, any copyright on the registration template MUST allow
    the IANA to copy it into the IANA registry."

There was a question some time back about copyright and IANA 
registries.  I suggest going with the lesser restrictive copyright as 
inbound rights.  That would allow derivative work as long as you 
don't claim that it is what's in the IANA registry.  An alternative 
argument would be to require inbound rights to the IETF and leave 
IETF/IANA interaction as an internal issue.

   "To become Internet Standards, a protocol or data object must go
    through the IETF standards process."

Suggested text: "To become an Internet Standard".

   "As discussed above, registration of a top-level type requires
    standards-track processing in the IETF and, hence, RFC publication."

Suggested text:

   As discussed above, registration of a top-level type requires
   Standards Action in the IETF and, hence, the publication of a RFC on
   the Standards Track.

In Section 5.2:

  "A web form for registration requests is also available:"

This is an opportunity to fix the URL if someone thinks that it is 
worth the bother.

Regards,
-sm