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

"t.petch" <ietfc@btconnect.com> Wed, 09 February 2011 15:45 UTC

Return-Path: <ietfc@btconnect.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 481123A67A2 for <apps-discuss@core3.amsl.com>; Wed, 9 Feb 2011 07:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.456
X-Spam-Level: *
X-Spam-Status: No, score=1.456 tagged_above=-999 required=5 tests=[AWL=-2.314, BAYES_40=-0.185, FRT_ADOBE2=2.455, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3]
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 2nxay+y+QaLG for <apps-discuss@core3.amsl.com>; Wed, 9 Feb 2011 07:45:47 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id A0F0E3A6767 for <apps-discuss@ietf.org>; Wed, 9 Feb 2011 07:45:46 -0800 (PST)
Received: from host86-156-136-65.range86-156.btcentralplus.com (HELO pc6) ([86.156.136.65]) by c2bthomr14.btconnect.com with SMTP id BQD54175; Wed, 09 Feb 2011 15:45:46 +0000 (GMT)
Message-ID: <000901cbc867$7a9d31a0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "=?iso-8859-1?Q?Martin_J._D=FCrst?=" <duerst@it.aoyama.ac.jp>
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> <4D520AE6.8070502@it.aoyama.ac.jp>
Date: Wed, 9 Feb 2011 15:41:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D52B6A9.000B, actions=tag
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4D52B6AC.003E, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: public-iri@w3.org, apps-discuss@ietf.org
Subject: Re: [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 15:45:48 -0000

----- Original Message -----
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
To: "t.petch" <ietfc@btconnect.com>
Cc: "Larry Masinter" <masinter@adobe.com>om>; "Ben Niven-Jenkins"
<ben@niven-jenkins.co.uk>uk>; <apps-discuss@ietf.org>rg>; <public-iri@w3.org>
Sent: Wednesday, February 09, 2011 4:32 AM

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

Martin

Well, the IRI charter says produce a new version of RFC4395, but looking
at the details in the charter, I see no reference to RFC4395.

Looking at rfc4395bis, the changes I see are 'URI includes IRI'
which is good to have, but not really on the same scale as "let's
change the IANA categories".  I would expect the WG chairs
and AD to declare such activity ultra vires (but I might get
a pleasant surprise:-).

Tom Petch

> 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