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

["t.petch" <[e-mail]>]

----- Original Message -----
From: "Larry Masinter" <[e-mail]>
To: "Ben Niven-Jenkins" <[e-mail]>; "Mykyta Yevstifeyev"
<[e-mail]>
Cc: <[e-mail]>
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
>