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

From: Ned Freed <[email-masked]>
Date: Sat, 04 Feb 2012 16:42:07 -0800 (PST)

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 05 Feb 2012 15:28:37 -0500

--On Saturday, February 04, 2012 16:42 -0800 Ned Freed
<[email-masked]> wrote:

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

It mentions ASCII and, IIR, NVT ASCII.  As far as charsets are
concerned, the latter, along with RFC 20 ASCII, are a 7bit code
embedded in an 8bit field.  But they are mentioned largely in
the context of moving beyond them.   (Abbreviated version of a
long tirade: there is no such thing as "US-ASCII" and the term/
attempted distinction doesn't even have informal value unless
you think there are, e.g., Canadian-ASCII, Mexican-ASCII,
Brazilian-ASCII, etc.).

Anyone who is inclined to split hairs along the above lines
should note that, in the early days of the ARPANET, we had
machines floating around that embedded the 7bit ASCII code in
7bits, 9bits, and at least two different flavors of 8bits.

    john

---

From: Ned Freed <[email-masked]>
Date: Sun, 05 Feb 2012 12:52:26 -0800 (PST)

> you think there are, e.g., Canadian-ASCII, Mexican-ASCII,

But not US-ASCII, and as you say, it discusses ASCII in any form only in
passing. If we really need a reference for that we can copy the one that's in
MIME that actually points to a defining document. But seriously, does anyone
really think we need such a reference? We're concerned with encodings, not
charsets, here, and US-ASCII is simply being mentioned in some text providing
context as to why encodings are even part of a registration.

				Ned