W3C home > Mailing lists > Public > uri@w3.org > November 1999

Re: UR* schemes

From: Daniel LaLiberte <liberte@w3.org>
Date: Mon, 22 Nov 1999 11:48:42 -0500 (EST)
Message-ID: <14393.29674.459424.319657@alceste.w3.org>
To: Keith Moore <moore@cs.utk.edu>
Cc: uri@w3.org
 > Daniel LaLiberte wrote:
 > > I believe Tim's argument against more central registries is that it
 > > would be even better to have no central registries.  We have one central
 > > registry, DNS, and that should be enough.  We have problems enough with
 > > that one registry.

Keith Moore writes:
 > No, I don't think so.
 > The reason DNS has been a problem is arguably that it there is too
 > much control in one place - so one particular enterprise (NSI) has
 > been able to unfairly restrict access to the registry and to demand
 > tribute from those using it.  

I think we all agree that we are having problems with the one central
DNS registry.  But it is not so clear whether we should try to make one
central registry work better, or go to a few more registries (dozens) or
many more registries (100s to 1000s).  Or should we go in the opposite
direction of avoiding central registries.  Ironically, an indefinitely
large number of "central" registries is like having no central
registries at all since both directions lead to anarchy.

 > Furthermore, it's a feature of many registries that they use compact
 > encodings (e.g. to minimize payload impact) and/or human-meaningful 
 > strings.  

I definitely see the value of these, despite the disadvantages.

 > I see absolutely no value and much harm in trying to use
 > DNS names for port numbers, autonomous system numbers, DNS query types, etc.

I wasn't arguing (in this exchange, so far) for using DNS names directly
for all these things.  Rather DNS could be used as it already has been,
to register hosts that are then used via http URIs to reference
resources served by those hosts.  Each host can "register" more URIs
simply by creating and using them, so all of URI-space becomes an
indefinitely large registry, all built on the one DNS registry.  There's
a bit more to it than that, of course, but that's the basic argument.

 > And to encode header field names, URI prefixes, etc. as DNS names
 > strikes me as a very dubious compromise - it's essentially saying
 > that it's more important to keep the protocol registries absolutely
 > open (or more accurately, to put all of the control in one place) and
 > to encourage vendor-specific protocol extensions, than it is to make
 > the prefixes terse, meaningful to humans, or transcribable, or to try
 > to encourage review or standardization of extensions.

That's an interesting set of issues, but I don't think the answers are
easy.  I would tend to say that while it is important to make
identifiers terse, meaningful, and to encourage standardization, we can
achieve that in different ways.  We can attempt to control the process,
or we can let free-market forces control it more "naturally".  The
trouble with free-market forces is that they are often not so free after
all.  Control of namespaces seems to get political one way or another.

But note that DNS (used either directly or indirectly via URIs) is a
single mechanism, but not a single point of control, once you get past
the top couple levels of DNS.  The single hierarchy of DNS is used to
delegate authority rather than control it.

 > IETF working groups have a lot of latitude when choosing extension
 > mechanisms for new protocols - see RFC 2434.  Different groups choose
 > different mechanisms for different protocols after weighing the
 > advantages and disadvantages of each.  This seems entirely
 > appropriate.

This freedom of choice is good as a goal, but the fact that different
mechanisms are chosen means that different namespaces can't interoperate
very easily.  A single interoperable namespace (such as all DNS, or all
URIs) does not necessarily imply that all control of authority is lost.

 > > Sure, but do URNs really offer anything new, or is it only an illusion
 > > of something new?
 > This has been discussed many times.   

Yes, and my question was somewhat rhetorical.  I didn't necessarily want
to get into the same arguments all over again.  But I wouldn't be at all
surprised (though I would be delighted) if new arguments come up.

 > URNs are a notational convention.

as are all URIs, and any URI scheme in particular.

 > They were deliberately made to look different than other kinds of URIs
 > in the hope that users would associate somewhat different semantics 
 > with URNs than with other URIs.  This is purely a human-interface issue.

I like to see that argument, partly because not all people who like the
idea of URNs see it the same way you do.  Many people believe there is
something fundamentally different about URNs compared to URLs.  I've
spent most of my time arguing how URNs and URLs are fundamentally the
same kind of thing, indistinguishable except by human perception.  So
you and I seem to agree.

 > We agree that it is possible to build protocol engines that allow 
 > URLs to be stable over a long time, but the point of URNs is to make
 > that stability (or at least, the intent of stability) a visible part
 > of the identifier.  

I don't know that everyone had (or has) the same idea about the
visibility of a persistence indicator.  Some people (including myself)
have been more concerned with establishing and deploying protocols that
support long-term persistence.  

Other ways of visibly indicating persistence in the identifier are being
tried, such as http://www.purl.org, and including dates in URIs.  As
mere identifiers, none of these variations have any more or less
guarantee of persistence, since persistence is a social contract.  But I
believe there is still a need for better protocol support for
persistence to allow the social contract to be implemented.

One alternative to including indicators of persistence in URIs is
indicating persistence in separate metadata where it can give much more
detail about the nature of the persistence, or the lack thereof.

 > This could have been done in many ways, but after
 > much deliberation the URN working group chose a particular syntax 
 > for URNs and particular rules for assigning them to ensure (if those
 > rules are followed) uniqueness and stability.  The work is done,
 > the decisions have been made, it's now up for users and implementors 
 > to decide whether they are sufficiently valuable to use.

The deployment hurdle for a new URI scheme is very high.  Combined with
the general lack of interest in persistence, URNs have gotten no where.
Either we need to make the value of deployment sufficiently high, or
make deployment considerably easier, or avoid the deployment problem

 > I will however note that in relation to the first topic, the URN group
 > worked very hard to avoid having a central point of control over URN
 > space - especially over URN resolution - while still preventing
 > conflicts in URN assignment, realizing that such control would be
 > an impediment both to deployment of URNs and to their long-term stability.
 > You might or might not believe that they were successful - but this 
 > was one of the tough problems that they tried to tackle.

I believe this effort to avoid a central point of control was motivated
more by the need to support multiple name spaces (past and future) than
a political control issue.  But regardless, I think most people are
happy with this as a goal.  Even the CNRI handle system eventually
delegated all control to subnamespaces (I believe).

 > > In a sense, every "directory" at every web site is a registry controlled
 > > by the owner of that directory.  But anyone can now publish documents
 > > merely by putting up their own web site, at very low cost, so we have
 > > less need to get someone else's permission.  Curiously, we continue to
 > > think in centralized ways.
 > It would be even more curious if we arbitrarily decided that all
 > centralized solutions were inherently evil, without bothering to
 > consider the pros and cons of each.  Internet protocols have
 > generally avoided centralization unless there was a good reason for
 > it; I expect this trend will continue.
 > Keith

Daniel LaLiberte
Received on Monday, 22 November 1999 11:48:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:01 UTC