Re: UR* schemes

At 11:48 AM 11/22/99 -0500, Daniel LaLiberte wrote:
> > 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
>altogether.
>
> > 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
>liberte@w3.org
> 

Let's face it.  The set of resources which are infinitely stable is
uninterestingly small.  The practical requirement is to be able to share
assertions characterizing the stability of a resource.  Any assertion of
stability extending into the future is an estimate, subject to change at a
later date.  This in itself means that scheme syntax is an unfortunate way
to discover the stability of a resource.  One doesn't want to have to
migrate a resource between schemes just because of an erratum.  There are a
variety of ways to associate such assertions with a resource.  Catalog
services are one way, embedded references to a configuration management
(effectivity) database is another.  Yet another is "expires" information
distributed as attached metadata (Headers) with the recovered instance of
the resource.  It makes more sense to encode this as instance particulars
than by some structural distinction in the URI scheme. 

Stability is of interest in creating replication policies and operating
cache/replica services.  It is also of interest in terms of the internals
of a resource such as "for how long is this price quote good?" which is
unlikely to be reflected in the URI of the quote page.

The gross features of the scheme should be reserved for information that is
more frequently of immediate concern to the end-user of the URI.  The
performance characteristics of URI schemes do not line up well will with
the performance requirements that go with stability or effectivity
information.

"How long is this information good?" is a question which is more often
going to be asked after reading the information itself, as opposed to
before reading.

Al

Received on Monday, 22 November 1999 12:46:26 UTC