Re: [apps-discuss] [happiana] comments on draft-freed-media-type-regs

[Ned Freed <[e-mail]>]

I've been reviewing past comments on the draft and realized I had missed
this one that was originally posted to the HAPPIANA list.

> <hat type='individual'/>

> Overall this looks quite good and is an improvement over RFC 4288.
> Thanks to the authors for working on this.

> I have a few small comments.

> 1. Non-Commercial Producers

> Section 3.2 says:

>    "Vendor" or "producer" are construed as
>    equivalent and very broadly in this context.

> Section 3.3 says:

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

> What about products that are distributed non-commercially, such as
> open-source software. Should the registrant use "vnd." or "prs."?

vnd. definitely. We already added text about industry consortia using
the vnd. tree but it is worth adding non-commercial to that. It will be
in the next revision.

> IMHO it would be better to define vendor/producer broadly enough to
> include non-commercial organizations.

Agreed.

> 2. Owners

> Sections 3.1 and 3.3 define the "owner" for a registration:

>    The "owner" of a media type registration in the standards tree is
>    assumed to be the standards body itself.

>    The owner of "personal" registrations and associated specifications
>    is the person or entity making the registration, or one to whom
>    responsibility has been transferred as described below.

> As far as I can see, such a definition is not provided for the vendor
> tree (despite the claim in Section 5.8). Thus arises the question: are
> third-party registrations allowed? I think they should be.

This is currently on the open issues list.

> 3. The "x." Tree

> Section 3.4 is somewhat at odds with draft-ietf-appsawg-xdash, which
> deprecates use of "x-" and similar constructions in application
> protocols. I doubt that we still need a special tree here. See also the
> naming restrictions in Section 4.2. I would be happy to discuss this
> further or propose text if desired.

Per my previous response, I'm taking a wait-and-see position on this one
for now. My preference would be to leave x. alone (it's never seen
any real use AFAIK) but remove the special status for x- entirely. But
let's see how the consensus develops.

> 4. "charset"

> Section 4.1 mentions things that are not media formats but charsets.
> Just to be sure, do we actually mean charset instead of one of the other
> terms (e.g., "character encoding") from BCP 166?

Absolutely not. Charset is the correct term to use here. For one thing, neither
character encoding nor coded character by themselves suffice to define a
complete way to encode characters as text - you have to combine them. And even
if you do, there are charsets that are defined in other ways. Charset really is
the most general term as it is defined as a mapping of octets to characters.

> 5. Encodings

> When mentioning "7bit US-ASCII text", perhaps reference RFC 5198.

Er, no. RFC 5198 doesn't even mention US-ASCII. And the Unicode format it
defines is 8bit, not 7bit!

> 6. Submission to the IESG

> One topic we've discussed on and off is removing the IESG bottleneck for
> standards-tree registrations, enabling other SDOs to directly submit
> their registration requests to the IANA for review by the IESG (rather
> than having the SDO's initial contact be to the IESG). I don't think
> we've quite reached consensus on that approach, but I think we should do
> so before draft-freed-media-type-regs is approved.

Of course this is the entire focus of the most recent revision; any feedback
on how it has been implemented would be appreciated.

				Ned