URI scheme registration procedures

This is a response to "Registration Procedures for URL Scheme Names",
draft-ietf-urlreg-procedures-06.txt, by Petke, King

Also "Some Alternatives to draft-ietf-urlreg-procedures-03" by Petke.
and "The VND Tree for URL Scheme Names" by King.

The remainder of this message contains some of my ideas for the general
problem of not enough URI schemes, rather than too many.

=============

The registration procedures document is OK as far as it goes, and I
don't have any strong objection.    Good thing since the deadline for
comments has passed.  Consider these comments in that light.

Three general recommendations:

  1. Change "locator" to "identifier" throughout, URL -> URI
  2. Separate identification from protocol.
  3. Impose URI based registration of each scheme name.

Section "URL Scheme Name Registration Trees", "General"
'the need is recognized for multiple registration "trees"'

It is not clear from the text whether the "trees" are arbitrarily deep
trees or are the just two levels deep, where lower level subtrees are
really just a flat list?  A two-level tree seems to be intended. 

I would favor general trees where higher levels would "own" lower levels
and could impose any restrictions desired as long as they are more
strict than the Guidelines for new schemes.  The top-most levels,
whether official IETF or alternative schemes, should be reviewed and
approved via a Standards Track document, but a lower level scheme would
follow the rules established by its ancestors.

Section "Registration Template", the "Intended usage" part confuses
identifiers with protocols to some extent.  I can go along with giving
an intended use as long as it is made clear this is not a protocol
binding and there may be new protocols implemented in the future that
impart otherwise unintended uses.


One area that should be addressed, perhaps in a separate document, is
automatically associating a URI with each scheme name, where resolving
that URI will provide at least a human-readable definition of the
scheme.  Doing this would provide documentation in a way that more
actively encourages conformance since everyone is referred to the same
document.  If machine-readable semantics could also be accessed by a
similar URI, this would provide a greatly needed extensible mechanism
for deploying new schemes. 

Since there not likely to be many IETF standardized schemes, the need
for associating a URI with each scheme is not so important.  With the
ability to add many schemes (to the alternative trees) in a less
controlled fashion, there is a far greater need to associate each scheme
with its documentation.  But allowing many more schemes to be deployed
is not the same as actually facilitating their deployment.  More on this
below.


=================


Regarding the "Some alternatives..." document, two ideas are suggested
for supporting alternative scheme trees.  The idea of composing vanity
names by reversing DNS names is preferrable to the NOREG syntax proposed
by Goland (in noreg-00.txt: 'NOREG+' domain name '+' URL-Scheme), but
it seems a bit unkempt.  More on this below.

The Numeric OIDs idea should be avoided until such time as we can
communicate telepathically to avoid seeing or entering URIs, or we have
a higher-level human-readable URI scheme that hides the numeric OID
level, but if we have that, why bother with OIDs.  

But I would like to argue against one of the supposed advantages of OIDs:
"Scheme names can stay the same even if the owning entity changes it's
name or is acquired by another entity".  This may be true, but if so, it
is only because the OID space is separate from the owning entities
ultimate control, not because the OID space uses numbers.  Numbers can
be owned just as well as readable names.


The main problem with the VND Tree suggestion is that it creates a new
top level name space that will result in disputes if there are
eventually enough parties interested in using it.  It is even more of a
problem because it is "vendor" specific and only a flat name space.

Many public organizations (government, libraries, non-profit orgs) might
have more of a reason to use their own schemes, and nothing is stopping
them from registering their own top-level alternative tree.  But it
would be odd to have different trees operating by different syntactic
rules.

===================

The remainder addresses how to satisfy two goals:

 1. Binding short schemes names to URIs, grandfathering in existing
    scheme names and allowing registration of new scheme names.

 2. A non-centralized mechanism for adding new schemes names in
    a way that avoids collisions and facilitates deployment.  

The first goal can be accomplished by mapping the abbreviated short name
of a scheme to a full URI as if it were a relative URI with a base URI
of some long-standing form such as "http://www.ietf.org/urireg/".  So
the "http" scheme would itself be identified by the full URI
"http://www.ietf.org/urireg/http", and resolving that URI would result in a
human readable document, the current HTTP spec that defines how to
process http URIs.

This registration mechanism is not intended to be flat, but to allow
structured names, we need to specify a translation from a structured
form such as left-to-right '-' separated scheme names to the corresponding
left-to-right '/' separated URIs.  So a scheme name such as
'http-secure' would map to "http://www.ietf.org/urireg/http/secure".


To accomplish the second goal of non-centralized registration, we need
to rely on DNS itself, or some other existing name system that will
deal with name space disputes.    Name space disputes are inevitable if
enough parties want to own parts of the same space.  Trademark
registration deals with name space disputes, and DNS needs to inherit
the same dispute resolution mechanisms, if not do them better.
So if we inherit from DNS, we are doing no worse.  (Several people have
made this argument.)

To allow any party to independently create their own scheme, otherwise
unregistered, I suggest we define one more top-level scheme for this
purpose, call it 'dns'.  The dns URI would look like:
'dns://<domain-name>/<scheme-specific-path>'.  This is directly
analogous to the http URI, but the difference is in the way a client
resolves it.  First it asks DNS for a particular kind of record for the
<domain-name>, call it the 'URIREG' record for now.  That record would
give another URI for the document(s) defining the scheme.  If a client
knows how to use that scheme, it proceeds with the remainder of the URI,
the <scheme-specific-path>.  If it doesn't, see below on extensible
semantics.

The 'dns' scheme would be registered as above, and resolving
"http://www.ietf.org/urireg/dns/<domain-name>" using the <domain-name>
in the URI (perhaps reversed and '/' separated) could cause the server
to fetch the URIREG record and produce a scheme definition document just
as for other schemes.

===

All this presumes that deploying new URI schemes is relatively easy.
Otherwise, why bother with all this bureaucratic overhead?  (We should
also ask In what areas do the existing schemes fall short?)  It is easy
enough to deploy clients that understand new schemes which documents
will use in very constrained ways that are either backward compatible or
there is nothing to be backward compatible with.  The 'javascript'
scheme is a case of this.  If a browser doesn't understand a javascript
link, it probably doesn't understand the javascript language at all, and
the browser-local action that the link should invoke will not occur.
Thus browsers that don't support javascript won't provide this
functionality, but it is not a loss on a global scale.

On the other hand, new schemes associated with new network protocols for
global access are very difficult to deploy.  Note that we have the same
set of global URI schemes today as we did at the beginning of the web.
This is because providers are very unlikely to use a new scheme in
documents if few clients support it, and producers of client software are
unlikely to support a new scheme unless there are providers that use
them to make the extra code worth while.  It is clearly not impossible,
but it is obviously very difficult unless there is a long term
cooperation between providers and client software producers.

One approach to the deployment problem is to use proxies associated with
each new scheme that process the identifiers for clients.  If the
registered information associated with a scheme name included how to
find a proxy that understands the scheme, this would provide at least a
foot in the door to deployment.  But it is not a terribly scalable
approach unless the proxy mechanism can be sufficiently distributed as
well.

Another partial solution to the deployment problem is to allow multiple
URIs per link.  Instead of only one URI in a single anchor, if a list of
somewhat equivalent URIs were allowed, the client could pick the first
one it understood, or pick one the user would prefer to use if there is
something to prefer.  This will at least allow new URI schemes to be
used in documents while continuing to support the old schemes, so it
makes deployment less problematic, but it doesn't otherwise address how
new scheme handlers get deployed in clients.


Another approach to work around this impass is automatically deployable,
executable semantics in the form of Java code (or something at least as
powerful) that may be downloaded into clients as needed to process
identifiers in the associated scheme.  Clients that already understand a
scheme by some other means (i.e. it's hard-coded into the client) need
not download the code, but clients that can accept this form of
extension will have access to any scheme defined in this way.

There are obviously significant security concerns here, and current Java
runtime systems don't permit unlimited access to all network services,
nor should they do so.  But there should be several possible solutions
to this set of concerns.  For example, proxies that do resolution on
behalf of other clients as described above could download the resolution
code and take on the additional burden of verifying the integrity of the
resolution code.

With an extensible scheme mechanism in place (it has to be deployed too)
we would not have to worry about deployment of any schemes that fit
within this one extensible scheme.  Indeed, there are several hard
questions that must be addressed, such as how extensible does it need to
be, and how are security problems to be avoided.  But deploying this one
extensible scheme would greatly facilitate the more rapid evolution of the
internet.  Hmm, maybe we don't really need that after all. :-)


-- 
Daniel LaLiberte
[email protected]