[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [133.2.253.33]) 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 ([133.2.253.231]) 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 [133.2.206.133]) 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] ([133.2.210.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: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) 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 
http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-00.

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