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

Larry Masinter <masinter@adobe.com> Tue, 08 February 2011 04:46 UTC

Return-Path: <masinter@adobe.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 13F183A6C9B for <apps-discuss@core3.amsl.com>; Mon, 7 Feb 2011 20:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 j4UbKWJhhSL4 for <apps-discuss@core3.amsl.com>; Mon, 7 Feb 2011 20:46:08 -0800 (PST)
Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by core3.amsl.com (Postfix) with ESMTP id 5D8573A6C99 for <apps-discuss@ietf.org>; Mon, 7 Feb 2011 20:46:05 -0800 (PST)
Received: from source ([192.150.8.22]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKTVDKkIVGn3dWPzf9EiSMSSqlrQka/Lh1@postini.com; Mon, 07 Feb 2011 20:46:14 PST
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p184k6s4005207; Mon, 7 Feb 2011 20:46:07 -0800 (PST)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p184k5HB028858; Mon, 7 Feb 2011 20:46:05 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 7 Feb 2011 20:46:05 -0800
From: Larry Masinter <masinter@adobe.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, Mykyta Yevstifeyev <evnikita2@gmail.com>
Date: Mon, 7 Feb 2011 20:46:10 -0800
Thread-Topic: [apps-discuss] The state of 'afs' URi scheme
Thread-Index: AcvCJ8yUSrPhj0XSQJCMpMIInTg8NQFIjuWg
Message-ID: <C68CB012D9182D408CED7B884F441D4D058EEE61B9@nambxv01a.corp.adobe.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>
In-Reply-To: <96CC61EE-81BD-43CB-A83F-78E67B2DA7A5@niven-jenkins.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.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: Tue, 08 Feb 2011 04:46:09 -0000

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?

Larry