Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs

[Ned Freed <[e-mail]>]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> On 4/12/12 12:09 PM, Murray S. Kucherawy wrote:
> > Just a reminder that this WGLC ends today.  If anyone has any
> > reviews to report or comments to provide, please do so.  I’d like
> > to hand it over to Barry this weekend if possible.

> Overall this looks very good. I have a few comments.

> 1. I wonder about this:

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

> Given the descriptions of Informational and Experimental documents in
> RFC 2026, I don't think we can say that they reflect IETF consensus.

You're reading it backwards. Nowhere does it say that all informational
specifications reflect IETF consensus, but rather than some IETF Consensus RFCs
can be published as informational. This is an incontrovertible fact, as is the
fact that standards tree media types have been defined in informational
specifications, and I suspect this will be done in the future as well.

For better or worse, the fact that everything has to go in one of a small set
of categories sometimes necessitates that awkward choices be made. But in the
case of a standards tree registration in an RFC, the IESG has final say on
that, including but not limited to assessing whether or not it makes sense for
the type to be in the standards tree at all, irrespective of the document
status. And I think this is already very clear.

> See in particular:

>    An "Informational" specification is published for the general
>    information of the Internet community, and does not represent an
>    Internet community consensus or recommendation.

Except that sometimes it does, and this has been true for a long time, RFC 2026
assertions notwithstanding. And in the case of it registering a media type in
the standards tree, it has to.

> 2. It's not clear to me where open-source projects fit into the
> taxonomy. One might think that an organization like Mozilla is a
> "vendor" or "producer", according to Section 3.2:

According to their web site, the Mozilla Foundation qualifies as a
non-commercial  entity.

>    The vendor tree is used for media types associated with publicly
>    available products.  "Vendor" and "producer" are construed very
>    broadly in this context and are considered equivalent.  Note that
>    industry consortia as well as non-commercial entities that do not
>    qualify as recognized standards bodies can quite appropriately
>    register media types in the vendor tree.

> However, Section 3.3 seems to add a further proviso regarding the
> commercial nature of a vendor or producer:

>    Registrations for media types created experimentally or as part of
>    products that are not distributed commercially may be registered in
>    the personal or vanity tree.

> So, is commercial distribution a necessary feature of a vendor or
> producer?

Once again you're reading things backwards. This is a restriction on who may
register a personal or vanity type, nothing more. We really don't want types
associated commercial entities showing up in the prs. tree.

And I really don't see how you can read it any other way. The term "vendor
tree" appears nowhere in this paragraph and the paragraph itself appears in a
section talking about the prs. tree, so how can it possibly apply any sort of
restriction on a different tree?

> 3. I don't know if the unregistered "x." tree is truly consistent with
> draft-ietf-appsawg-xdash. I'm not saying it needs to be, but that
> would IMHO be desirable. Note that the xdash document, despite the
> name, is not limited to the literal string "x-" but applies more
> generally to similar constructs, such as "x.". Given that we are
> significantly easing the registration process in
> draft-ietf-appsawg-media-type-regs, do we still feel a need to even
> mention the "x." tree?

If there's a clear preference and consensus to drop it that's fine, but absent
that I'm uncomfortable with removing it.

				Ned