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

Mykyta Yevstifeyev <> Tue, 01 February 2011 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 616EB3A6D4D; Tue, 1 Feb 2011 06:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.214
X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sRwLp7IJAb3C; Tue, 1 Feb 2011 06:58:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D331C3A6D41; Tue, 1 Feb 2011 06:58:31 -0800 (PST)
Received: by fxm9 with SMTP id 9so7530258fxm.31 for <multiple recipients>; Tue, 01 Feb 2011 07:01:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MoMJH70NgATLtCfY1B/FG2GUh4BK7q+Ro2H0iVi+8Ig=; b=sOousM1zGV5KnBXylEtFyIEBZQt4PVBQycasa2zHzX3drIJuJdRmXk2xe6Gmroe0F+ Y6tdAytkMkAtE8mjh6ugDLvF1bJEUeCiwjPnSoXKQ2NIsaZlM1wPh4Y5gn/MftcnrlCV V7zVmj/2XvDNaXD9R/uXfWh0lzEY65PSNTPr0=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Urv2EyUzBFAQt/xdC6KaoTO/NLC9IHBQom5nUubhj62yunoVdApmlIh1BTdMMjdSPK mDtL9GmXaJuELy7OdE0HyQiDlifI+EXiJL2xIDy3l0khogbm+teHZw610KeJqQn7NxWK /riqKSRKaSOevpLtSx2OpGPLj+ugwIO1ZIt8I=
Received: by with SMTP id v16mr7549848fal.128.1296572508421; Tue, 01 Feb 2011 07:01:48 -0800 (PST)
Received: from [] ([]) by with ESMTPS id n26sm7891935fam.13.2011. (version=SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 07:01:47 -0800 (PST)
Message-ID: <>
Date: Tue, 01 Feb 2011 17:02:09 +0200
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Ben Niven-Jenkins <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>, URI <>, Paul Hoffman <>,
Subject: Re: [apps-discuss] The state of 'afs' URi scheme
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Feb 2011 14:58:33 -0000

01.02.2011 13:23, Ben Niven-Jenkins wrote:
> Mykyta,
> On 1 Feb 2011, at 10:15, Mykyta Yevstifeyev wrote:
>> 31.01.2011 16:59, Paul Hoffman wrote:
>>> On 1/31/11 12:28 AM, Roy T. Fielding wrote:
>>>> No, there is no reason to have that document either.  We don't need
>>>> these useless exercises in bit pushing -- there are plenty of other
>>>> drafts that need writing about actual protocols that were (and are)
>>>> used on the Web as identifiers.  afs, nfs, tn3270, and mailserver are
>>>> all examples of schemes that someone once thought might be a good idea,
>>>> but were in fact never used on the Internet.  They are obsolete.
>>> +1
>>> On 1/31/11 3:20 AM, Mykyta Yevstifeyev wrote:
>>>> Since these schemes are in Provisional category, it means that they are
>>>> 'waiting for specification'. If no-one specifies them, they should be
>>>> moved to Historical. That's clear, IMO.
>>> -1
>>> Mykyta, you are approximately the only person who seems to have a problem understanding that standards organizations like the IETF sometimes don't follow through on what they thought were good ideas and sometimes don't document that. Your response is to generate many useless efforts to clean up the IETF specs instead of just doing what everyone else does, which is to ask a question, find the answer, and move on. It feels like you are wasting lots of people's time for the benefit of no one other than maybe yourself. (If there are others who feel that Mykyta's efforts are worth our time, by all means speak up and I'm happy to back down here.)
>> Paul, Roy, and all,
>> What RFC 4395 says is that all URI schemes ever registered fall into three categories: Permanent, Provisional and Historical.  There are no other cases the URI scheme may be classified as.
>> RFC 1738, in its Section 4 mentioned the 'afs' URI scheme as reserved for further specifying.  Following the creation of URI schemes registry the scheme was added to Provisional category, since it does not appear to appropriate for registration as Permanent or Historical.
>> RFC 4395 sets clear criteria for all the categories.  The 'afs' URI scheme may not be classified as Permanent, because of the lack of what mentioned in Section 2.1, 2.3, 2.4, 2.6 and 2.7 of RFC 4395.  This scheme is not appropriate for Provisional because of the points described in Section 3 of this document, especially the cited below:
> I think the exact category these schemes are recorded under is not the key issue here.
> These schemes were registered because it was believed they would be used but no-one has actually used them.
> What is the real value and benefit in doing all the work to move them to historic? No one uses them so no one benefits from tweaking the category they are placed in IMO.
> One could argue that it is good housekeeping etc. but given the effort to write a draft, have it reviewed and taken through the IESG to become an RFC that no-one will read (because no-one uses the scheme in the first place) just doesn't seem a good use of the community's time and resources IMO.

Such action might be performed by simple request of IESG.  RFC 4395 says:

Transition from 'provisional' to 'historical' may be
    requested by anyone authorized to update the provisional

Since that is not clear who is authorized to change it, IESG should be 
considered for such action (there is not this in the document, this is 
my opinion).  So IMO IESG should issue the community call on 
reclassification and then request this action from IANA.

And in this way there won't be what you say - unnecessary docs.

All the best,
Mykyta Yevstifeyev
> Ben