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

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 24 May 2012 14:10 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785A621F8577; Thu, 24 May 2012 07:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.369
X-Spam-Level:
X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF0f1Bu+Aktz; Thu, 24 May 2012 07:10:38 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 75B1921F856F; Thu, 24 May 2012 07:10:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337868637; d=isode.com; s=selector; i=@isode.com; bh=iCdQf+Jr1htxpSJ04UXdhUZjXVp26g7rYH/LqjFr8mE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ooHDC8/E4Tbf1DzcdbR/eMnnYbvur/5eZFgj5/z18tpFYcJIyJjABqq8Gm7yU6eLRODWy3 N3kJdqv6xDrHn08fUnv42pRfpoRzD1MYy61pZBPXl2TTRETdC4hV2liN6H6gi2e7ATHraU 1GXJ68AfhFRmOx0dQB8DNbpzKUpYhtY=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <T75BXAAE4029@rufus.isode.com>; Thu, 24 May 2012 15:10:37 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4FBE4172.5020509@isode.com>
Date: Thu, 24 May 2012 15:10:58 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Ned Freed <ned.freed@mrochek.com>
References: <39405CB0-D62D-419F-83C6-DB3CFA7CD9B7@mnot.net> <01OFJW6FHKJ60006TF@mauve.mrochek.com> <004C9D74-9447-43F5-8C29-32E26716FB99@isode.com> <01OFJY4T4E9K0006TF@mauve.mrochek.com> <0B11FB37-5971-4191-9298-85A357794C8F@isode.com> <01OFK4MBYUPG0006TF@mauve.mrochek.com>
In-Reply-To: <01OFK4MBYUPG0006TF@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham <mnot@mnot.net>, IESG IESG <iesg@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>, "draft-ietf-appsawg-media-type-regs.all@tools.ietf.org" <draft-ietf-appsawg-media-type-regs.all@tools.ietf.org>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appsawg-media-type-regs-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2012 14:10:39 -0000

Hi Ned,

On 17/05/2012 01:21, Ned Freed wrote:
>> Hi Ned,
>>
>> On 16 May 2012, at 22:26, Ned Freed<ned.freed@mrochek.com>  wrote:
>>
>>>> Hi Ned,
>>>> Commenting on one specific point:
>>>> On 16 May 2012, at 17:24, Ned Freed<ned.freed@mrochek.com>  wrote:
>>>>>
>>>>>> * Section 5.2.1 "Provisional registrations MAY be updated or abandoned at any
>>>>>> time." How does this happen? How is it reflected in the registry? "OBSOLETE"?
>>>>> Provisional registrations are not in the registry. It's up to IANA as to
>>>>> how to implement the details.
>>>>>
>>>>>
>>>> I didn't get the "not in the registry" part. I suspect this is not entirely clear in the document.
>>>  From the section on provisional registries:
>>>
>>>   Upon receipt of a provisional registration, IANA will check the name and
>>>   contact information, then publish the registration in a separate provisional
>>>   registration list.
>>>
>>> Note the use of the term "separate".
>> I read "separate list" as still being a part of the registry.
> Well, in a key sense it is: The namespace is shared. There's no point to
> provisional registrations if it isn't. Whether you want to call it one single
> registry containing two separate lists or two registries sharing a namespace is
> syntactic detail I just can't get excited about. And none of this is relevant
> to the original point anyway.
Actually it is relevant in my mind. IMHO, if provisional registrations 
are listed on the same page as permanent registrations, then abandoning 
a registration shouldn't cause the entry to just disappear.
>
>> Question: did you envision that IANA might decide not to make this separate
>> list public (as one of the options)?
> This is now getting silly. Of course the list is public.
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.

But anyway, I do think that Section 5.2.1 is underspecified, in 
particular handling of abandoned registrations. But to settle this 
discussion I think we should ask Michelle from IANA about whether she 
understands what is required from IANA in case of provisional 
registrations.
> And no, there is no
> need to state that explicitly. Have you ever seen a statement in an IANA
> considerations section saying "this information needs to be made public"? I
> seriously doubt you can point to even a single example.
>