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

From: SM <[email-masked]>
Date: Fri, 13 Apr 2012 01:26:14 -0700

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

---

From: Ned Freed <[email-masked]>
Date: Sun, 15 Apr 2012 14:12:59 -0700 (PDT)

> paragraph of Section 3.1.

Actually, it does no such thing. A document that has to be approved by the IESG
is more or less by definition going to be a consensus document, since a key
aspect of the IESG's job is to assess consensus. Your proposed change actually
makes things less aligned.

> be modified to refer to "Standards Action" or "IETF Review".

Wrong again, I'm afraid. A document can be approved but not published. That's
the key point beind made here. Well, that and that the fact that the document
doesn't have to be on the standards track.

> does not make sense to register "x." for use in private, local environment.

This document isn't registering it. The tree already exists; this document
simply isn't removing it. I'm not inclined to remove it because we have no idea
if it's in use or not (I suspect it's not, but my suspicions are not evidence),
and also aside from this whole "align with xdash even though it doesn't apply
to existing mechanisms" argument, nobody has expressed any preference for
removing it, let alone explaining how to actually accomplish this removal.

This is different from the change to allow registration of x-. x- wasn't a
tree, x. is. So simply removing it would change any x. type usage from that of
an unregistered type to that of using an invalid tree.

> I suggest prefacing "References" with "normative".

It's probably a bit too strict, but I'll go ahead and do this. I can always
back it out if there are objections.

> Typo: registration.

This must already be fixed because I cannot find it.

>    to assist the software

I prefer application. But it does need to be plural.

>     media type registration proposal itself.

I'm not wild about the RFC 5226 text and actually preferred what we had, but in
the interests of alignment I've changed things to use a variant of it.

> Typo: references.

Can't find this one either.

> I suggest "encouraged" instead of "allowed".

That was intentionally changed in the other direction. We don't really want to
encourage a flood of RFCs containing the vendor format du jour.

> IETF/IANA interaction as an internal issue.

You're proposing a specific mechanism, one of many possible mechanisms. It is
completely inappropriate to restrict this to one mechanism or even suggest a
mechanism - the key point is that IANA has the right to copy, not how it is
done.

> Suggested text: "To become an Internet Standard".

Changed.

>    Standards Action in the IETF and, hence, the publication of a RFC on

That's better. Changed.

> This is an opportunity to fix the URL if someone thinks that it is

No, actually, it's not. We'll be consulting with IANA before final publication
on what changes need to be made to the web form. That will be the time to
change the URL, assuming such a change is needed.

Thanks for the review; sorry I didn't get to it before posting -05.

				Ned

---

From: SM <[email-masked]>
Date: Sun, 15 Apr 2012 15:59:48 -0700

Hi Ned,

Thanks for the explanation you provided.

>makes things less aligned.

Ok.

>Wrong again, I'm afraid. A document can be approved but not published. That's

Ok. :-)

>if it's in use or not (I suspect it's not, but my suspicions are not 

Please leave it.

>back it out if there are objections.

I'll leave it to others to provide input on this (Section 4.2.8).

>This must already be fixed because I cannot find it.

 From the diff of -05, I see that it has been fixed.

>I prefer application. But it does need to be plural.

Ok.

>Can't find this one either.

It's fixed in -05.

>encourage a flood of RFCs containing the vendor format du jour.

I misinterpreted that text.

>mechanism - the key point is that IANA has the right to copy, not how it is

Ok.

>change the URL, assuming such a change is needed.

Ok.

>Thanks for the review; sorry I didn't get to it before posting -05.

It's alright.  BTW, there isn't a sentence in the Abstract or 
Introduction in -05 about this document obsoleting RFC 4288.  That 
may have to be added.

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Sun, 15 Apr 2012 19:05:13 -0700 (PDT)

> BTW, there isn't a sentence in the Abstract or

Another sort point with both John Klensin and myself. This "requirement" (it is
actually nothing of the sort) is not just pointless, it's outright
inappropriate. We managed to publish the EAI specifications without such
language and we're going to push hard to do that here as well.

				Ned