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

08.02.2011 13:16, t.petch пишет:
> ----- 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!
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
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

Received on Tuesday, 8 February 2011 15:46:35 UTC