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

----- Original Message -----
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
To: "t.petch" <ietfc@btconnect.com>
Cc: "Larry Masinter" <masinter@adobe.com>; "Ben Niven-Jenkins"
<ben@niven-jenkins.co.uk>; <apps-discuss@ietf.org>; <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>; "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

Received on Wednesday, 9 February 2011 21:38:51 UTC