Re: [apps-discuss] The state of 'afs' URi scheme

Tony Hansen <tony@att.com> Tue, 08 February 2011 21:29 UTC

Return-Path: <tony@att.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208403A6890; Tue, 8 Feb 2011 13:29:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.555
X-Spam-Level:
X-Spam-Status: No, score=-105.555 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_05=-1.11, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNyoWHupN-fL; Tue, 8 Feb 2011 13:29:35 -0800 (PST)
Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 56C343A6835; Tue, 8 Feb 2011 13:29:35 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-12.tower-121.messagelabs.com!1297200581!45039720!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 7705 invoked from network); 8 Feb 2011 21:29:42 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Feb 2011 21:29:42 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p18LU3UH008666; Tue, 8 Feb 2011 16:30:03 -0500
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p18LTxS6008638; Tue, 8 Feb 2011 16:30:00 -0500
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p18LTa3i020922; Tue, 8 Feb 2011 16:29:36 -0500
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p18LTWnw020784; Tue, 8 Feb 2011 16:29:32 -0500
Received: from [135.91.118.213] (dn135-91-118-213.dhcpn.ugn.att.com[135.91.118.213]) by maillennium.att.com (mailgw1) with ESMTP id <20110208212931gw100e4ljfe> (Authid: tony); Tue, 8 Feb 2011 21:29:32 +0000
X-Originating-IP: [135.91.118.213]
Message-ID: <4D51B5BB.8070204@att.com>
Date: Tue, 08 Feb 2011 16:29:31 -0500
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com><81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com><4D455380.6040103@gmail.com> <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com><4D464EA4.7090303@gmail.com> <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com><4D46CE52.6030503@vpnc.org> <4D47DD4A.7040503@gmail.com><06BA884E-D1C7-4783-BBE6-A6B21DE013B7@niven-jenkins.co.uk><4D482071.8050202@gmail.com><CDAB7832-EBF9-4ECE-B8D1-09BA39BDF4B8@niven-jenkins.co.uk><4D48267A.1030800@gmail.com><96CC61EE-81BD-43CB-A83F-78E67B2DA7A5@niven-jenkins.co.uk> <C68CB012D9182D408CED7B884F441D4D058EEE61B9@nambxv01a.corp.adobe.com> <026901cbc781$a2724ee0$4001a8c0@gateway.2wire.net> <4D516551.1060108@gmail.com>
In-Reply-To: <4D516551.1060108@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: "uri-review@ietf.org" <uri-review@ietf.org>, URI <uri@w3.org>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] The state of 'afs' URi scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 08 Feb 2011 21:29:38 -0000

On 2/8/2011 10:46 AM, Mykyta Yevstifeyev wrote:
> 08.02.2011 13:16, t.petch пишет:
>> The problem, at least for URI, is RFC4395, which gives the procedures 
>> for new
>> schemes
>> and failed to consider old schemes.  RFC1738 did not make afs: 
>> provisional or
>> historic,
>> it merely asked that the name be reserved.  IANA, arguably 
>> incorrectly, places
>> afs: under
>> Provisional citing RFC1738 as its source.  But RFC1738 does not tell 
>> them to do
>> that!
> Maybe IANA was guided by the following fact. While RFC 4395 mentions 
> the Provisional category, it does not give full definition of its 
> purpose. This might cause misunderstanding of community and other 
> interesting parties. IANA, due to lack of precise definition decided 
> that RFC 1738 reserves these names via their provisional registration. 
> Therefore they put it into corresponding category.
>
> But we should note that RFC 4395 says:
>
>>   To transition to the new registry, all URL name schemes in the
>>     existing table should be entered as URI schemes, with 'permanent'
>>     status.
> and says nothing about filling the Provisional registry. This should 
> have caused this problem.
>> So, arguably, we could tell IANA to create a provisional registry as 
>> RFC1738
>> told them to
>> and make it light weight, no need for IETF/IESG involvement unless 
>> and until a
>> move
>> to Provisional or Permanent is envisaged, using Expert Review in 
>> other cases of
>> change.
>> (I know of no other way of changing things in the IETF, which is what 
>> I see as a
>> constraint
>> we have to accept).
> Such proposal is not very clear. What do you mean while saying 
> 'registry per RFC1738'. Such registry is now replaced by what created 
> by RFC4395. Moreover, since you propose to make it almost not 
> controlled, possibly with the 'First Come First Served' policies will 
> create great confusion. I do not think such idea is good.
>> Or we could write a just-once catch-all RFC that picks up all these 
>> old ones,
>> and defines
>> a procedure for them (ie not a registration, but a procedure for 
>> registration,
>> such as
>> reinforcing the need for a Reserved category and placing those in it 
>> that should
>> always have
>> been in it).
> During the discussion of this topic in December there was such a 
> proposal - to create the special Reserved category, but this did not 
> gain the support. Such category's scope is very contiguous with that 
> for Provisional one.

I'm wondering if the authors of RFC 4395 (of which I'm one) should send 
a note to IANA saying that "afs" and "tn3270" should have been entered 
into the "Permanent" portion of the URI registry instead of the 
"Provisional" portion. (And then be done with the topic.)

     Tony Hansen
     tony@att.com