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

From: Larry Masinter <[email-masked]>
Date: Sun, 15 Apr 2012 04:07:04 -0700

should there be a process for moving vendor tree formats to standards tree, when product formats become open standards (as happened with PDF) ?
Connected by DROID on Verizon Wireless

-----Original message-----
From: SM <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Fri, Apr 13, 2012 08:54:10 GMT+00:00
Subject: [apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-04

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

---

From: Ned Freed <[email-masked]>
Date: Sun, 15 Apr 2012 07:06:57 -0700 (PDT)

> should there be a process for moving vendor tree formats to standards tree,
> when product formats become open standards (as happened with PDF) ?

I think this is a sufficiently rare event that a process isn't needed. In the
specific case of PDF, the registered type is application/pdf, which means
there's no naming issue, but in general there will be, and that really needs to
be handled on a case by case basis. There's also the possibility that
standardization may actually result in an incompatible change to the format.

				Ned

---

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

> standardization may actually result in an incompatible change to the format.

... and after giving this some more thought, I wouldn't touch it with a stick.
Consider the change control issue - standards tree requires that change control
rest with a standards body. And that doesn't mean "there's a subset of this
that described in a standard", but rather "the standards actually describe
what's showing up on the wire".

				Ned