The state of 'afs' URi scheme

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

The state of 'afs' URi scheme

Mykyta Yevstifeyev
Dear all,

I have posted the following message on 7 January:

Dear all,

Let me briefly summarize all the comments on 'afs' URI scheme. Firstly, 
those referring to OpenAFS, forget that AFS is not only network service, 
but just file system. If we move this scheme to historic, there will be 
no harm to those who use it. Moreover, I should repeat here that moving 
the scheme to Historic does not mean restricting them to be used. If 
smbd still uses it, they will continue to do this. But it's impossible, 
as there is no clients for AFS as *network service*.

I personally think we should move it to Historic to indicate it is not 
used among the Internet and is outdated. So what we decide on 'afs' URI 
scheme?

All the best,
Mykyta Yevstifeyev
and have not received any responses yet. Should I consider that as the 'silent agreement'?

Mykyta
Reply | Threaded
Open this post in threaded view
|

Re: The state of 'afs' URi scheme

Mykyta Yevstifeyev
11.01.2011 18:11, Alastair Angwin1 wrote:

> Mykyta
> I have watched this thread and alerted some folks who would be closer to it
> than I am
> As someone who has been involved in standards and had to deal with legacy
> may I point out that the classification of "historic" is emotive,
> Regardless of whether or not it affects any current implementations or
> users it sends a less than desirable message. I cannot think of many of us
> other than a palaeontologist who would like ourselves or our work to be
> referred to as dinosaurs or ancient.
> May I suggest as a way forward that the team wanting to address these
> legacy, a much more preferred term, schemes actually contacts the OpenAFS
> folks or IBM who still support customers using AFS to get their input
> I don't think silence should always be taken as agreement ... perhaps those
> who would have an opinion are simply not sufficiently aware of current
> discussions
Alastair,

During the discussion that occurred here, it was mentioned that there is
no any appropriate implementation that use the 'afs' URI scheme to
access the AFS resources.  Maybe there are some server implementations,
but having no interest to this scheme as a tool to access the resources
provided by these servers makes the scheme just useless.  If there is no
benefit from such a scheme.  Those who use AFS may use it, we don't
restrict them.  We just want to indicate that the 'afs' scheme is out of
use, deprecated.  And in this case, do you know any implementations to
support this scheme?

Mykyta Yevstifeyev

> Regards
>
> Alastair Angwin
>
>
>
>
>
> From:       Mykyta Yevstifeyev<[hidden email]>
> To:         [hidden email]
> Date:       11/01/2011 15:31
> Subject:    The state of 'afs' URi scheme
> Sent by:    [hidden email]
>
>
>
> Dear all,
>
> I have posted the following message on 7 January:
>        Dear all,
>
>        Let me briefly summarize all the comments on 'afs' URI scheme.
>        Firstly,
>        those referring to OpenAFS, forget that AFS is not only network
>        service,
>        but just file system. If we move this scheme to historic, there will
>        be
>        no harm to those who use it. Moreover, I should repeat here that
>        moving
>        the scheme to Historic does not mean restricting them to be used. If
>        smbd still uses it, they will continue to do this. But it's
>        impossible,
>        as there is no clients for AFS as *network service*.
>
>        I personally think we should move it to Historic to indicate it is
>        not
>        used among the Internet and is outdated. So what we decide on 'afs'
>        URI
>        scheme?
>
>        All the best,
>        Mykyta Yevstifeyev
>
> and have not received any responses yet. Should I consider that as the
> 'silent agreement'?
>
> Mykyta
>
>


Reply | Threaded
Open this post in threaded view
|

Re: The state of 'afs' URi scheme

Mykyta Yevstifeyev
In reply to this post by Mykyta Yevstifeyev
Hello all,

I'd like to resume the discussion on 'afs' URI scheme by citing RFC 4395:
 
In some circumstances, it is appropriate to note a URI scheme that
   was once in use or registered but for whatever reason is no longer in
   common use
or the use is not recommended.  In this case, it is
   possible for an individual to request that the URI scheme be
   registered (newly, or as an update to an existing registration) as
   'historical'.  Any scheme that is no longer in common use MAY be
   designated as historical; the registration should contain some
   indication to where the scheme was previously defined or documented.

So there is a sense in moving this scheme to Historical category since it fully matches to these guidelines.  Therefore I do not consider such action as inappropriate for the 'afs' URI scheme.

Any other thoughts as for this?

All the best,
Mykyta Yevstifeyev



Reply | Threaded
Open this post in threaded view
|

Re: The state of 'afs' URi scheme

Roy T. Fielding
On Jan 30, 2011, at 4:03 AM, Mykyta Yevstifeyev wrote:

> Hello all,
>
> I'd like to resume the discussion on 'afs' URI scheme by citing RFC 4395:
>  
>> In some circumstances, it is appropriate to note a URI scheme that
>>    was once in use or registered but for whatever reason is no longer in
>>    common use or the use is not recommended.  In this case, it is
>>    possible for an individual to request that the URI scheme be
>>    registered (newly, or as an update to an existing registration) as
>>    'historical'.  Any scheme that is no longer in common use MAY be
>>    designated as historical; the registration should contain some
>>    indication to where the scheme was previously defined or documented.
>
> So there is a sense in moving this scheme to Historical category since it fully matches to these guidelines.  Therefore I do not consider such action as inappropriate for the 'afs' URI scheme.

No, there is no reason to publish a new document about a
scheme that was never used.  It is obsolete.

....Roy


Reply | Threaded
Open this post in threaded view
|

Re: The state of 'afs' URi scheme

Mykyta Yevstifeyev
30.01.2011 20:20, Roy T. Fielding wrote:

> On Jan 30, 2011, at 4:03 AM, Mykyta Yevstifeyev wrote:
>
>> Hello all,
>>
>> I'd like to resume the discussion on 'afs' URI scheme by citing RFC 4395:
>>
>>> In some circumstances, it is appropriate to note a URI scheme that
>>>     was once in use or registered but for whatever reason is no longer in
>>>     common use or the use is not recommended.  In this case, it is
>>>     possible for an individual to request that the URI scheme be
>>>     registered (newly, or as an update to an existing registration) as
>>>     'historical'.  Any scheme that is no longer in common use MAY be
>>>     designated as historical; the registration should contain some
>>>     indication to where the scheme was previously defined or documented.
>> So there is a sense in moving this scheme to Historical category since it fully matches to these guidelines.  Therefore I do not consider such action as inappropriate for the 'afs' URI scheme.
> No, there is no reason to publish a new document about a
> scheme that was never used.  It is obsolete.
Roy,

I think that the document like that may be found here:
https://datatracker.ietf.org/doc/draft-melnikov-mailserver-uri-to-historic/ 
is suitable for 'afs' URI scheme.  This is the same situation as with
the 'mailserver' URI scheme.

Mykyta
> ....Roy
>
>


Reply | Threaded
Open this post in threaded view
|

Re: The state of 'afs' URi scheme

Roy T. Fielding
On Jan 30, 2011, at 9:54 PM, Mykyta Yevstifeyev wrote:

> 30.01.2011 20:20, Roy T. Fielding wrote:
>> On Jan 30, 2011, at 4:03 AM, Mykyta Yevstifeyev wrote:
>>
>>> Hello all,
>>>
>>> I'd like to resume the discussion on 'afs' URI scheme by citing RFC 4395:
>>>
>>>> In some circumstances, it is appropriate to note a URI scheme that
>>>>    was once in use or registered but for whatever reason is no longer in
>>>>    common use or the use is not recommended.  In this case, it is
>>>>    possible for an individual to request that the URI scheme be
>>>>    registered (newly, or as an update to an existing registration) as
>>>>    'historical'.  Any scheme that is no longer in common use MAY be
>>>>    designated as historical; the registration should contain some
>>>>    indication to where the scheme was previously defined or documented.
>>> So there is a sense in moving this scheme to Historical category since it fully matches to these guidelines.  Therefore I do not consider such action as inappropriate for the 'afs' URI scheme.
>> No, there is no reason to publish a new document about a
>> scheme that was never used.  It is obsolete.
> Roy,
>
> I think that the document like that may be found here: https://datatracker.ietf.org/doc/draft-melnikov-mailserver-uri-to-historic/ is suitable for 'afs' URI scheme.  This is the same situation as with the 'mailserver' URI scheme.

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.

....Roy
Reply | Threaded
Open this post in threaded view
|

Re: The state of 'afs' URi scheme

Mykyta Yevstifeyev
31.01.2011 10:28, Roy T. Fielding wrote:

> On Jan 30, 2011, at 9:54 PM, Mykyta Yevstifeyev wrote:
>> 30.01.2011 20:20, Roy T. Fielding wrote:
>>> On Jan 30, 2011, at 4:03 AM, Mykyta Yevstifeyev wrote:
>>>
>>>> Hello all,
>>>>
>>>> I'd like to resume the discussion on 'afs' URI scheme by citing RFC 4395:
>>>>
>>>>> In some circumstances, it is appropriate to note a URI scheme that
>>>>>     was once in use or registered but for whatever reason is no longer in
>>>>>     common use or the use is not recommended.  In this case, it is
>>>>>     possible for an individual to request that the URI scheme be
>>>>>     registered (newly, or as an update to an existing registration) as
>>>>>     'historical'.  Any scheme that is no longer in common use MAY be
>>>>>     designated as historical; the registration should contain some
>>>>>     indication to where the scheme was previously defined or documented.
>>>> So there is a sense in moving this scheme to Historical category since it fully matches to these guidelines.  Therefore I do not consider such action as inappropriate for the 'afs' URI scheme.
>>> No, there is no reason to publish a new document about a
>>> scheme that was never used.  It is obsolete.
>> Roy,
>>
>> I think that the document like that may be found here: https://datatracker.ietf.org/doc/draft-melnikov-mailserver-uri-to-historic/ is suitable for 'afs' URI scheme.  This is the same situation as with the 'mailserver' URI scheme.
> 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.
Roy,

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.

Mykyta
> ....Roy


Reply | Threaded
Open this post in threaded view
|

Re: The state of 'afs' URi scheme

Roy T. Fielding
On Jan 31, 2011, at 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.

No, they should be removed from the registry and allowed to be
defined by some other spec in the future.  There is no need to
reserve the schemes of unimplemented identifier mechanisms.

....Roy


Reply | Threaded
Open this post in threaded view
|

Re: The state of 'afs' URi scheme

Mykyta Yevstifeyev
31.01.2011 21:32, Roy T. Fielding wrote:
> On Jan 31, 2011, at 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.
> No, they should be removed from the registry and allowed to be
> defined by some other spec in the future.  There is no need to
> reserve the schemes of unimplemented identifier mechanisms.
Roy,

Firstly, are there any procedures for de-assignment of URI schemes
registration, as you propose.  Moreover, Provisional category provides
the state 'waiting for proper specification'.  Finally, re-read the
definition of Historical category and the definition of Provisional
category.  And then make the conclusions.

Mykyta
> ....Roy
>
>


Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
In reply to this post by Roy T. Fielding
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.
Ben,

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


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


Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
01.02.2011 17:23, Ben Niven-Jenkins wrote:

> Mykyta,
>
> On 1 Feb 2011, at 15:02, Mykyta Yevstifeyev wrote:
>> Ben,
>>
>> 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
>>    registration.
>>
>>
>> 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.
> So you've saved an I-D being written but still used IESG time which could be much better spent on other things that actually provide value to the community.
I really do not consider the action I propose as that 'requires great
amount of time'.  Moreover, there is a strong consensus it is not used
and will not be used so no problems will appear, IMO.
> Also, you failed to answer the question I asked though, namely:
>>> 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.
> Unless there is a good answer to that question to justify changing their classification, I don't see any point in spending time discussing how one might go about reclassifying them.
You should better ask the authors of RFC 4395 this, but not me.  If this
wasn't needed, it wouldn't appear here.

Mykyta Yevstifeyev
> Ben
>
>


Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
In reply to this post by Mykyta Yevstifeyev
01.02.2011 17:53, John Levine wrote:
>> This is like that.  Let's not waste everyone's time.
>> In fact, let's not waste any more time discussing it.
> I certainly see rough consensus (everyone except one) that there is
> nothing to do here.  So I encourage people to resist the urge to
> debate it further.
Dear all,

If there is a rough consensus to remain this scheme Provisional, this
means that there should be proper specification.  Even RFC 1738 is not
appropriate here, as it is obsoleted.  Does anyone one want to specify
this?  The answer is obviously 'no'.  The same answer is to the question
'Move to Historic?'.  And for 'Do anything else?'

This seems to be a deadlock.  Therefore for I'll contact apps Area
directors for their final decision.

Mykyta Yevstifeyev

> R's,
> John
> _______________________________________________
> apps-discuss mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
In reply to this post by Mykyta Yevstifeyev
08.02.2011 13:16, t.petch пишет:

> ----- Original Message -----
> From: "Larry Masinter"<[hidden email]>
> To: "Ben Niven-Jenkins"<[hidden email]>; "Mykyta Yevstifeyev"
> <[hidden email]>
> Cc:<[hidden email]>
> 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!
Maybe IANA was guided by the following fact. While RFC 4395 mentions the
Provisional category, it does not give full definition of its purpose.
This might cause misunderstanding of community and other interesting
parties. IANA, due to lack of precise definition decided that RFC 1738
reserves these names via their provisional registration. Therefore they
put it into corresponding category.

But we should note that RFC 4395 says:

>   To transition to the new registry, all URL name schemes in the
>     existing table should be entered as URI schemes, with 'permanent'
>     status.
and says nothing about filling the Provisional registry. This should
have caused this problem.
> 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).
Such proposal is not very clear. What do you mean while saying 'registry
per RFC1738'. Such registry is now replaced by what created by RFC4395.
Moreover, since you propose to make it almost not controlled, possibly
with the 'First Come First Served' policies will create great confusion.
I do not think such idea is good.
> 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).
During the discussion of this topic in December there was such a
proposal - to create the special Reserved category, but this did not
gain the support. Such category's scope is very contiguous with that for
Provisional one.

Mykyta Yevstifeyev
> Tom Petch
>
>> Larry
>>
> _______________________________________________
> apps-discuss mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


Reply | Threaded
Open this post in threaded view
|

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

Tony Hansen
On 2/8/2011 10:46 AM, Mykyta Yevstifeyev wrote:

> 08.02.2011 13:16, t.petch пишет:
>> 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!
> Maybe IANA was guided by the following fact. While RFC 4395 mentions
> the Provisional category, it does not give full definition of its
> purpose. This might cause misunderstanding of community and other
> interesting parties. IANA, due to lack of precise definition decided
> that RFC 1738 reserves these names via their provisional registration.
> Therefore they put it into corresponding category.
>
> But we should note that RFC 4395 says:
>
>>   To transition to the new registry, all URL name schemes in the
>>     existing table should be entered as URI schemes, with 'permanent'
>>     status.
> and says nothing about filling the Provisional registry. This should
> have caused this problem.
>> 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).
> Such proposal is not very clear. What do you mean while saying
> 'registry per RFC1738'. Such registry is now replaced by what created
> by RFC4395. Moreover, since you propose to make it almost not
> controlled, possibly with the 'First Come First Served' policies will
> create great confusion. I do not think such idea is good.
>> 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).
> During the discussion of this topic in December there was such a
> proposal - to create the special Reserved category, but this did not
> gain the support. Such category's scope is very contiguous with that
> for Provisional one.

I'm wondering if the authors of RFC 4395 (of which I'm one) should send
a note to IANA saying that "afs" and "tn3270" should have been entered
into the "Permanent" portion of the URI registry instead of the
"Provisional" portion. (And then be done with the topic.)

     Tony Hansen
     [hidden email]


Reply | Threaded
Open this post in threaded view
|

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

Alexey Melnikov
Tony Hansen wrote:

> On 2/8/2011 10:46 AM, Mykyta Yevstifeyev wrote:
>
>> 08.02.2011 13:16, t.petch пишет:
>>
>>> 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!
>>
>> Maybe IANA was guided by the following fact. While RFC 4395 mentions
>> the Provisional category, it does not give full definition of its
>> purpose. This might cause misunderstanding of community and other
>> interesting parties. IANA, due to lack of precise definition decided
>> that RFC 1738 reserves these names via their provisional
>> registration. Therefore they put it into corresponding category.
>>
>> But we should note that RFC 4395 says:
>>
>>>   To transition to the new registry, all URL name schemes in the
>>>     existing table should be entered as URI schemes, with 'permanent'
>>>     status.
>>
>> and says nothing about filling the Provisional registry. This should
>> have caused this problem.
>>
>>> 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).
>>
>> Such proposal is not very clear. What do you mean while saying
>> 'registry per RFC1738'. Such registry is now replaced by what created
>> by RFC4395. Moreover, since you propose to make it almost not
>> controlled, possibly with the 'First Come First Served' policies will
>> create great confusion. I do not think such idea is good.
>>
>>> 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).
>>
>> During the discussion of this topic in December there was such a
>> proposal - to create the special Reserved category, but this did not
>> gain the support. Such category's scope is very contiguous with that
>> for Provisional one.
>
> I'm wondering if the authors of RFC 4395 (of which I'm one) should
> send a note to IANA saying that "afs" and "tn3270" should have been
> entered into the "Permanent" portion of the URI registry instead of
> the "Provisional" portion. (And then be done with the topic.)

While I personally like to be done with this topic, I don't think just
declaring "afs"/"tn3270" permanent is Ok without having proper syntax
specificications.


Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
Hello all,

Let me cite the URI schmes regsitry from 28 November 2005

--- Citations starts----

Uniform Resource Identifier (URI) SCHEMES

(last updated 28 November 2005)

This is the Official IANA Registry of URI Schemes

In the Uniform Resource Identifier (URI) definition [RFC3986,RFC1738]
there is a field, called "scheme", to identify the type of resource
and access method.

[....]

Reserved URI Scheme Names:

   afs              Andrew File System global file names
   tn3270           Interactive 3270 emulation sessions
   mailserver       Access to data available from mail servers

---Citations ends---

And then from February 2007, provisional category:

---Ctation starts---

Index of /assignments/uri-schemes/prov
 Name                    Last modified       Size  Description
--------------------------------------------------------------------------------
 Parent Directory        23-Feb-2007 11:55      -
 iax2                    23-Feb-2007 11:54     3k


--------------------------------------------------------------------------------

Apache/1.3.27 Server at www.iana.org Port 80

---Citation ends----

The same is for Sepember 2007 and the latest archival entry from 23
October 2007 here:
http://web.archive.org/web/*/http://iana.org/assignments/uri-schemes

The question is - who added the sheme to the regsitry?

Mykyta Yevstifeyev

2011/2/9, Alexey Melnikov <[hidden email]>:

> Tony Hansen wrote:
>
>> On 2/8/2011 10:46 AM, Mykyta Yevstifeyev wrote:
>>
>>> 08.02.2011 13:16, t.petch пишет:
>>>
>>>> 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!
>>>
>>> Maybe IANA was guided by the following fact. While RFC 4395 mentions
>>> the Provisional category, it does not give full definition of its
>>> purpose. This might cause misunderstanding of community and other
>>> interesting parties. IANA, due to lack of precise definition decided
>>> that RFC 1738 reserves these names via their provisional
>>> registration. Therefore they put it into corresponding category.
>>>
>>> But we should note that RFC 4395 says:
>>>
>>>>   To transition to the new registry, all URL name schemes in the
>>>>     existing table should be entered as URI schemes, with 'permanent'
>>>>     status.
>>>
>>> and says nothing about filling the Provisional registry. This should
>>> have caused this problem.
>>>
>>>> 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).
>>>
>>> Such proposal is not very clear. What do you mean while saying
>>> 'registry per RFC1738'. Such registry is now replaced by what created
>>> by RFC4395. Moreover, since you propose to make it almost not
>>> controlled, possibly with the 'First Come First Served' policies will
>>> create great confusion. I do not think such idea is good.
>>>
>>>> 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).
>>>
>>> During the discussion of this topic in December there was such a
>>> proposal - to create the special Reserved category, but this did not
>>> gain the support. Such category's scope is very contiguous with that
>>> for Provisional one.
>>
>> I'm wondering if the authors of RFC 4395 (of which I'm one) should
>> send a note to IANA saying that "afs" and "tn3270" should have been
>> entered into the "Permanent" portion of the URI registry instead of
>> the "Provisional" portion. (And then be done with the topic.)
>
> While I personally like to be done with this topic, I don't think just
> declaring "afs"/"tn3270" permanent is Ok without having proper syntax
> specificications.
>
>