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

Mykyta Yevstifeyev <> Wed, 09 February 2011 10:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68A173A697A; Wed, 9 Feb 2011 02:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.549
X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6+5+e0csII2H; Wed, 9 Feb 2011 02:03:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D47AE3A683B; Wed, 9 Feb 2011 02:03:18 -0800 (PST)
Received: by gyd12 with SMTP id 12so3047966gyd.31 for <multiple recipients>; Wed, 09 Feb 2011 02:03:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nqb05aX1kH6voehcxXem/49oFcBSndqG57v/inNVKeE=; b=QEfCtXr6BTp3r3CblkVM7Dvhm44cOqWvu4fj8APOx6+ZO9lSWwvW69SNH7VkKKCFnS PJyhmWBJQIMp+6qDBnVFggB8QbZMwyvwXnYN9YWn90pC81IJGxtbwLpl6VuQ8/ehuPJC FCqX7Lu1Xqn27GzkBXnIhGVsjp3fn5CVfxpmg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=F6rCTq9ybuHt+42Q5JTnmlKorI5mXTqi7bbVVR/VEspa5JAi4w7VZoATQPfdSgpXhE XZ5gSYrZHfxv0SxKSyO/R5bmI1ke4P/Y4w0xIinpxdJu6Qt3pyKHKrzLaXnu44WXfSe8 y7U681bdsEnmMMxcOQCfszKbtoBd5ywQqp7PY=
MIME-Version: 1.0
Received: by with SMTP id u18mr1401256ybj.269.1297245807519; Wed, 09 Feb 2011 02:03:27 -0800 (PST)
Received: by with HTTP; Wed, 9 Feb 2011 02:03:27 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <026901cbc781$a2724ee0$> <> <> <>
Date: Wed, 9 Feb 2011 12:03:27 +0200
Message-ID: <>
From: Mykyta Yevstifeyev <>
To: Alexey Melnikov <>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, URI <>,
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: Wed, 09 Feb 2011 10:03:20 -0000

Hello all,

Let me cite the URI schmes regsitry from 28 November 2005

--- Citations starts----

Uniform Resource Identifier (URI) SCHEMES

(last updated 28 November 2005)

This is the Official IANA Registry of URI Schemes

In the Uniform Resource Identifier (URI) definition [RFC3986,RFC1738]
there is a field, called "scheme", to identify the type of resource
and access method.


Reserved URI Scheme Names:

   afs              Andrew File System global file names
   tn3270           Interactive 3270 emulation sessions
   mailserver       Access to data available from mail servers

---Citations ends---

And then from February 2007, provisional category:

---Ctation starts---

Index of /assignments/uri-schemes/prov
 Name                    Last modified       Size  Description
 Parent Directory        23-Feb-2007 11:55      -
 iax2                    23-Feb-2007 11:54     3k


Apache/1.3.27 Server at Port 80

---Citation ends----

The same is for Sepember 2007 and the latest archival entry from 23
October 2007 here:*/

The question is - who added the sheme to the regsitry?

Mykyta Yevstifeyev

2011/2/9, Alexey Melnikov <>om>:
> 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.