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

Folks,

In order to avoid the confusions that occur with the 'afs' URI scheme
in future, I'd like to propose to make the *full* regsitration
template required for registration of URI schemes in all categories,
except Historical - ie Permanent and Provisional.  This will provide
at last formal specification of scheme's syntax and semantics and then
allow to decide on the category of particular scheme later.

Next, in order to avoid some other misunderstanding with Historical
category, I'd like to propose to give more distinctive definition on
this category rathetr tan mentioning it as 'this exists'.
Particulary, add some decription of procedures used for moving the
schemes' regsitrations to it.  What is more, allow not to provide the
registration template for such regsitrations.

Or any other thoughts?

Mykyta Yevstifeyev

2011/2/9, t.petch <ietfc@btconnect.com>:
>
> ----- 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 Thursday, 10 February 2011 07:41:39 UTC