Registration process for new URL schemes

I'd like to pick up again the discussion on "scheme registration process" that
we started in Memphis.

Here is my recap of the issues raised in Memphis:  If you left Memphis with a
different understanding of our meeting and/or you have additional issues, please
post your comments to the list.

1) There needs to be some registry (IANA or the like) that keeps the master list
of URL scheme names (public and private alike).  This is needed to ensure that
scheme names are unique.

2) There is the issue of "rights" to a scheme name:  Is it a trademark?  Can
CompuServe register AOL:? Can someone other than SUN register java:?  Etc.
Also, what are the rules for declaring a scheme name abandoned?

3) There needs to be some documentation component to the registration of new
schemes so that folks parsing URLs know how to handle (or ignore) each scheme.
It has been suggested that a standards track RFC should be used for schemes
intended to be public and an informational RFC should be used for private
schemes.  This allows the process to be fast for private schemes yet still
ensures that sufficient review is applied to public schemes.

4) The time sequence of (1) and (3) is in question.  Does one register the
scheme first then publish an informational or standards track RFC or the other
way around?  If registration is first, do we have a time limit on how long it
can take for a documentation RFC (of either type) to appear?

There was general agreement in Memphis that private URL schemes should share a
common name space with public schemes and that "x-" naming is not a good idea.
One of the supporting arguments is that public schemes may start out as private
schemes.  If you do not have a common name space to start with, moving a private
scheme to public may not be possible due to name conflicts.  In the case of
"x-", how do you know when to remove the "x-" and what issues arise out of
renaming a scheme?

I have a proposal in mind for the registration process but I'd like to get some
feedback from the list on the issues mentioned above before I post my proposal.
I don't want to prematurely restrict people to commenting on (defending, etc.) a
proposal.

Rich Petke ([email protected])