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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 09 February 2011 09:02 UTC

Return-Path: <alexey.melnikov@isode.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 06FE03A6958; Wed, 9 Feb 2011 01:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 JNYq2xL3JEmM; Wed, 9 Feb 2011 01:02:17 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0AA653A6957; Wed, 9 Feb 2011 01:02:17 -0800 (PST)
Received: from [92.40.158.95] (92.40.158.95.sub.mbb.three.co.uk [92.40.158.95]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TVJYHgADL7-k@rufus.isode.com>; Wed, 9 Feb 2011 09:02:24 +0000
Message-ID: <4D525803.6070701@isode.com>
Date: Wed, 09 Feb 2011 09:01:55 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Tony Hansen <tony@att.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> <4D51B5BB.8070204@att.com>
In-Reply-To: <4D51B5BB.8070204@att.com>
MIME-Version: 1.0
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: Wed, 09 Feb 2011 09:02:19 -0000

Tony Hansen wrote:

> 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.)

While I personally like to be done with this topic, I don't think just 
declaring "afs"/"tn3270" permanent is Ok without having proper syntax 
specificications.