Re: [apps-discuss] APPSDIR review of draft-ietf-appsawg-media-type-regs-07

John C Klensin <> Thu, 24 May 2012 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD32821F8606; Thu, 24 May 2012 10:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.476
X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l5zkhNxrDfzD; Thu, 24 May 2012 10:48:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ECC4821F85EA; Thu, 24 May 2012 10:48:05 -0700 (PDT)
Received: from [] (helo=PST.JCK.COM) by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1SXc36-0002MQ-Jt; Thu, 24 May 2012 13:42:08 -0400
Date: Thu, 24 May 2012 13:47:53 -0400
From: John C Klensin <>
To: Ned Freed <>, Alexey Melnikov <>
Message-ID: <711532BB4A183EA21FAF4413@PST.JCK.COM>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Mark Nottingham <>, IESG IESG <>, IETF Apps Discuss <>,
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appsawg-media-type-regs-07
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 May 2012 17:48:07 -0000

--On Thursday, May 24, 2012 09:49 -0700 Ned Freed
<> wrote:

>> Ok, maybe it is silly. But I've heard IANA people talking
>> about private registrations of things like port numbers,
>> which are hidden from the world until the product associated
>> with such private registration is released.
> I ask again: How many registration setup specifications have
> you seen that make
> a point of stating that the information they cantain is
> supposed to be public?
> You have yet to provide a single example. And a particularly
> relevant
> counterexample is RFC 3864, which set up the provisional
> header field registry.
> Nowhere did the IANA directions in that document say that the
> registry needed
> to be public, yet it ended up that way. So the default is
> clearly public and an
> explicit statement is required for a registry to be private.
> But that said, this nonsense needs to stop, and if changing
> the wording is the
> only way to accomplish that, so be it. How about:
>   Upon receipt of a provisional registration, IANA will check
> the name and
>   contact information, then publish the registration in a
> separate publicly
>   visible provisional registration list.
> Does this work for you?

FWIW, it works for me.

Also FWIW, IANA used to accept "hidden" or private entries in
some registries.  For them, either only the identifier was
visible to the public or nothing at all was visible but the name
or number would not be available for reuse or use by others.  In
those cases, IANA required documentation supporting the
registration and descriptions of what it was for, but was
willing to keep those confidential (under NDA) for some
negotiated period of time.

As far as I know, that practice ended with the transfer of IANA
responsibility from USC-ISI to ICANN.  Answers to questions in
the first half of the last decade indicated that it was no
longer being done; if that has changed more recently to
reinstate the older practice, I don't believe the community (or
even the IAB) has been told about it and believe that both would
have been.

More important, as Ned points out, this really has nothing to do
with the present document -- there are all sorts of obvious
things it could say that it doesn't.  Statements like
"registration data are public except maybe in very unusual cases
that the registry-creating spec must explicitly enable and this
media type registry specification doesn't do that" and "the IANA
doesn't get to decide on the validity of an IESG determination
of consensus for for a IETF-based standards track registration"
are certainly on that list of obvious things that shouldn't need
debate or writing down, but so is "no registrations will be
updated on the 29th of February in odd-numbered years".

While the material has been restructured and reorganized several
times to meet changing needs, there are many basic principles
that are unchanged since the registration provisions of RFC
1590.  Might it be reasonable to suggest that, if no real and
substantive problems have turned up in those basic principles in
the last 18 years, an "ain't broke, doesn't need fixing"
guideline might apply?