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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Wed, 09 February 2011 03:32 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id D4C0E3A6848 for <apps-discuss@core3.amsl.com>; Tue, 8 Feb 2011 19:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.78
X-Spam-Status: No, score=-96.78 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, FRT_ADOBE2=2.455, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id i31FCD7Fa-XG for <apps-discuss@core3.amsl.com>; Tue, 8 Feb 2011 19:32:57 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp []) by core3.amsl.com (Postfix) with ESMTP id D82E53A6841 for <apps-discuss@ietf.org>; Tue, 8 Feb 2011 19:32:56 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p193Wupa030978 for <apps-discuss@ietf.org>; Wed, 9 Feb 2011 12:32:56 +0900
Received: from (unknown []) by scmse02.scbb.aoyama.ac.jp with smtp id 69d6_72d5_4901d68a_33fd_11e0_96fd_001d096c5782; Wed, 09 Feb 2011 12:32:56 +0900
Received: from [IPv6:::1] ([]:51698) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S14CB293> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Wed, 9 Feb 2011 12:32:54 +0900
Message-ID: <4D520AE6.8070502@it.aoyama.ac.jp>
Date: Wed, 09 Feb 2011 12:32:54 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.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>
In-Reply-To: <026901cbc781$a2724ee0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "public-iri@w3.org" <public-iri@w3.org>, apps-discuss@ietf.org
Subject: [apps-discuss] URI registrywas: Re: 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 03:32:59 -0000

I'm cc'ing the IRI WG list. One of the deliverables of the IRI WG is an 
update of RFC 4395. You can see the current version at 

Given that there is a WG chartered to work on these issues, I suggest to 
move the discussion there.

Regards,   Martin.

On 2011/02/08 20:16, t.petch wrote:
> ----- Original Message -----
> From: "Larry Masinter"<masinter@adobe.com>
> To: "Ben Niven-Jenkins"<ben@niven-jenkins.co.uk>; "Mykyta Yevstifeyev"
> <evnikita2@gmail.com>
> Cc:<apps-discuss@ietf.org>
> Sent: Tuesday, February 08, 2011 5:46 AM
>> I think in general the overhead in maintaining current information about old
> registered values is too high, and that it *is* worth time thinking about how we
> could lower the overhead for registry maintenance.
>> There are a number of related issues raised about various registered values,
> including MIME type, charset, and URI schemes.
>> Ideally a registry is a place where a new implementor can go to discover both
> the theory and current practice for use of registered values on the internet. I
> think the current processes cope OK with theory (although the overhead of
> updating the registry when there is a new spec is high, it might be acceptable)
> but not with practice (where implementation and deployment sometimes is in
> advance of, or divergent from, the formal specs).
>> The situation is more acute in areas where protocols and formats are
> undergoing rapid development.
>> So I agree that writing a document marking 'afs' as 'obsolete' is make-work
> and not-worth anyone's time, but how could we make it easier (light-weight
> annotation) without subjecting ourselves to DOS of unreliable annotation?
> 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!
> 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).
> 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).
> Tom Petch
>> Larry
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp