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

Re: UR* schemes [was: 3rd IETF/W3C coordination call...]

From: Keith Moore <moore@cs.utk.edu>
Date: Wed, 17 Nov 1999 17:33:59 -0500
Message-Id: <199911172233.RAA21986@astro.cs.utk.edu>
To: Daniel LaLiberte <liberte@w3.org>
cc: "Larry Masinter" <lmm@acm.org>, "Keith Moore" <moore@cs.utk.edu>, "Dan Connolly" <connolly@w3.org>, "Patrik Fältström" <paf@swip.net>, "Philipp Hoschka" <ph@w3.org>, w3t-arch@w3.org, t-and-s@w3.org, w3c-policy@apps.ietf.org
> 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.

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.  ICANN might help that situation (only time will tell) - 
but it's been incredibly difficult to get it going, largely due to opposition
from NSI and NSI-funded loonies - partially because NSI could use the 
tribute money to build its war chest.  Imagine the situation if NSI had control
over all of the ICANN registries because they were all under the DNS root.

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 see absolutely no value and much harm in trying to use
DNS names for port numbers, autonomous system numbers, DNS query types, etc.
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.

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.

IIRC we discussed this topic in a previous teleconference, so I don't 
think we should spend time on it again.

> Sure, but do URNs really offer anything new, or is it only an illusion
> of something new?

This has been discussed many times.   URNs are a notational convention.
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.
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.  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.

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.

> 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.

Received on Thursday, 18 November 1999 10:50:53 UTC

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