W3C home > Mailing lists > Public > uri@w3.org > February 2011

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

From: Mykyta Yevstifeyev <evnikita2@gmail.com>
Date: Tue, 01 Feb 2011 17:02:09 +0200
Message-ID: <4D482071.8050202@gmail.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
CC: Paul Hoffman <paul.hoffman@vpnc.org>, apps-discuss@ietf.org, "uri-review@ietf.org" <uri-review@ietf.org>, URI <uri@w3.org>
01.02.2011 13:23, Ben Niven-Jenkins wrote:
> Mykyta,
> On 1 Feb 2011, at 10:15, Mykyta Yevstifeyev wrote:
>> 31.01.2011 16:59, Paul Hoffman wrote:
>>> On 1/31/11 12:28 AM, Roy T. Fielding wrote:
>>>> No, there is no reason to have that document either.  We don't need
>>>> these useless exercises in bit pushing -- there are plenty of other
>>>> drafts that need writing about actual protocols that were (and are)
>>>> used on the Web as identifiers.  afs, nfs, tn3270, and mailserver are
>>>> all examples of schemes that someone once thought might be a good idea,
>>>> but were in fact never used on the Internet.  They are obsolete.
>>> +1
>>> On 1/31/11 3:20 AM, Mykyta Yevstifeyev wrote:
>>>> Since these schemes are in Provisional category, it means that they are
>>>> 'waiting for specification'. If no-one specifies them, they should be
>>>> moved to Historical. That's clear, IMO.
>>> -1
>>> Mykyta, you are approximately the only person who seems to have a problem understanding that standards organizations like the IETF sometimes don't follow through on what they thought were good ideas and sometimes don't document that. Your response is to generate many useless efforts to clean up the IETF specs instead of just doing what everyone else does, which is to ask a question, find the answer, and move on. It feels like you are wasting lots of people's time for the benefit of no one other than maybe yourself. (If there are others who feel that Mykyta's efforts are worth our time, by all means speak up and I'm happy to back down here.)
>> Paul, Roy, and all,
>> What RFC 4395 says is that all URI schemes ever registered fall into three categories: Permanent, Provisional and Historical.  There are no other cases the URI scheme may be classified as.
>> RFC 1738, in its Section 4 mentioned the 'afs' URI scheme as reserved for further specifying.  Following the creation of URI schemes registry the scheme was added to Provisional category, since it does not appear to appropriate for registration as Permanent or Historical.
>> RFC 4395 sets clear criteria for all the categories.  The 'afs' URI scheme may not be classified as Permanent, because of the lack of what mentioned in Section 2.1, 2.3, 2.4, 2.6 and 2.7 of RFC 4395.  This scheme is not appropriate for Provisional because of the points described in Section 3 of this document, especially the cited below:
> I think the exact category these schemes are recorded under is not the key issue here.
> These schemes were registered because it was believed they would be used but no-one has actually used them.
> What is the real value and benefit in doing all the work to move them to historic? No one uses them so no one benefits from tweaking the category they are placed in IMO.
> One could argue that it is good housekeeping etc. but given the effort to write a draft, have it reviewed and taken through the IESG to become an RFC that no-one will read (because no-one uses the scheme in the first place) just doesn't seem a good use of the community's time and resources IMO.

Such action might be performed by simple request of IESG.  RFC 4395 says:

Transition from 'provisional' to 'historical' may be
    requested by anyone authorized to update the provisional

Since that is not clear who is authorized to change it, IESG should be 
considered for such action (there is not this in the document, this is 
my opinion).  So IMO IESG should issue the community call on 
reclassification and then request this action from IANA.

And in this way there won't be what you say - unnecessary docs.

All the best,
Mykyta Yevstifeyev
> Ben
Received on Tuesday, 1 February 2011 15:02:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC