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

John C Klensin <> Fri, 25 May 2012 01:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC29821F84D8; Thu, 24 May 2012 18:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.498
X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gPkId4jFy603; Thu, 24 May 2012 18:52:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6103C21F84D6; Thu, 24 May 2012 18:52:08 -0700 (PDT)
Received: from [] (helo=PST.JCK.COM) by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1SXjbX-0002zu-Gm; Thu, 24 May 2012 21:46:11 -0400
Date: Thu, 24 May 2012 21:51:56 -0400
From: John C Klensin <>
To: Mark Nottingham <>, Ned Freed <>
Message-ID: <AC3555A97C0D08BEB5E653B5@PST.JCK.COM>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <711532BB4A183EA21FAF4413@PST.JCK.COM> <> <> <> <>
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: IETF Apps Discuss <>, IESG IESG <>,
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: Fri, 25 May 2012 01:52:10 -0000

--On Friday, May 25, 2012 11:23 +1000 Mark Nottingham
<> wrote:

> On 25/05/2012, at 11:17 AM, Ned Freed wrote:
>>> On 5/24/12 6:08 PM, Mark Nottingham wrote:
>>>> On 25/05/2012, at 3:47 AM, John C Klensin wrote:
>>>>>> 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.
>>>> For the record, it doesn't work for me. Having a separate
>>>> list forces people to check two separate lists, causing
>>>> confusion and reducing the overall value of the registry
>>>> (we already have a problem with people using Wikipedia
>>>> instead of IANA).
>>> +1
>> The point of the provisional registry is to reserve the name
>> so standards can be written and trial implementations
>> developed without having to go through a subsequent name
>> change.
>> It is *not* there so that random people can look up and start
>> using the type. Which is very likely to happen if there isn't
>> a clean separation.
>> If the IESG feels differently, we'll see. But I am absolutely
>> and totally opposed to these not being separate, and at least
>> one of my coauthors (John) has indicated that if anything,
>> he's even more opposed to it than I am.
> I think the underlying problem is that "provisional" is used
> in a different sense in RFC3864. I'm not saying it's the
> *right* sense, but having two different meanings for the same
> term in somewhat related registries isn't optimal.

Yes.  The 3864 definition, as I understand it, is closer to
"trial use, incomplete information, might change" while this is,
as Ned points out, is closer to "reserve name during
standardization".  If you think that is excessively confusing,
I'd be open to calling this one something more like "temporarily
reserved" or, to borrow a note from a couple of ISO Maintenance
Agencies "exceptionally reserved", rather than "provisional".
My objection, as Ned suggested, is any hint of "this will be
standardized so start using it based on what you think the
standard will be.    Those who want the standards track
registrations need to accept that they are tied to a consensus
process and that those not only take time but can result in
changes.   Those who need "fast" and/or "open to implementation
even the definitions are woefully incomplete" should use the
vendor or personal trees.