Date: Wed, 26 Oct 94 12:00:46 CDT
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Message-Id: <9410261700.AA07853@void.ncsa.uiuc.edu>
To: fielding@avron.ICS.UCI.EDU, uri@bunyip.com
Subject: Re: Current URN syntax is unacceptable
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
The fact is that all this colon-business is just a misguided
attempt to use ":" instead of "/" as a hierarchical component
separator.
The proposal was not to use ":" within the hierarchical component but
between components of the name. But I don't think most people care
either way. I'm happy with "/" instead.
I see no reason for making such a change, and thus
propose that if a hierarchical name is to be used, the
separator should be "/". For instance:
urn:/dns/net/path/mitra/1234
(which establishes one URN uber alles -- a bad idea), or
dns:/net/path/mitra/1234
dns:/edu/uci/ics/urn/People/Fielding/Roy/public/vitae
which allows the actual hierarchy to be determined downstream
(where the "answer" is known) rather than in the client.
This thoroughly hierarchical scheme is closer to what I would like
anyway. The way it would have to work (to be scalable) is that the
client (or proxy) would first try to figure out as much of the prefix
as it can by asking its local DNS resolver to look up successively
shorter strings. e.g. 1234.mitra.path.net, mitra.path.net, path.net,
net. Once it gets an IP address back, the client passes the rest of
the string on to be resolved. I don't know if DNS can be made to work
this way though.
This has the advantages of
1) being easily parsable
Certainly.
2) does not place arbitrary constraints on scalability
Not sure what you are getting at here. Do you mean that it is up
to the name resolver side to decide whether to delegate subtrees
to subresolveres?
3) does not prevent other URN schemes from coexisting
(i.e. Message-IDs)
Any flat name scheme could fit in with a hierarchical scheme at the
top level, provided that there is no conflict with the existing top
level names and with the syntax of the hierarchical naming scheme.
E.g. dns:isbn/1234 fits right in, although it looks a bit silly. But
perhaps those provisos are too restrictive.
> If more naming systems are allowed, there must be only a
> small fixed number of them (presumably the ones grandfathered in)
> because these must be known by clients or their proxy servers.
I disagree here -- there is no need to restrict the schemes to
a fixed number. Schemes can be bound to "handlers" at
run-time, providing that the method for identifying the scheme
remains constant (another reason for discarding the URN:
prefix).
Hmm, for scalability, handling of services must be pushed down to
clients as much as possible (and then the remainder to be handled by
remote servers must be managable). The more different kinds of
schemes that clients are required to know about, the larger their
code grows. I suppose market pressures will tend to keep this within
reasonable bounds though.
Actually, the paragraph I wrote after the one you quoted above agrees
with you. We are OK if there is a fixed number of *types* of schemes
that clients must know about. All schemes that are handled by some
external handler look like the same type of scheme to clients.
... Similarly, any given entity is likely to have
multiple URN names.
This seems like a completely different subject and a big can o' worms.
I'll agree that any particular entity might be *referenced* indirectly
via the URCs of multiple URNs. For example, a URN for the collection
of all versions of a document might intersect with a URN for the
collection of all representations of the current version of a
document. But every URN is still unique and corresponds to a unique
entity. I like to think of the URC as the object identified by a URN.
> But the current proposal is probably
> sufficient because the number of requests for any particular
> document generally declines over time, so the name resolver
> associated with that document can safely assume it will not
> have to handle more requests in the future.
Say what? That is simply untrue, as evidenced by the number
of requests on the Mosaic "What's New" document or (over a
longer term) the number of requests for RFC 822.
You aren't thinking long term enough then. I was thinking on the 500
year time frame. The "What's New" page won't survive that long. Not
much will. Still, I should have qualified my statement above by
saying that requests may rise temporarily over a day, week, month,
year, or decade. So publishers have to guess how popular they think a
document will become at its peak to decide whether to create a
subpublisher to handle it. In the worst case, each document would be
served (or servable) by a single machine.
BTW, caching enters in here too. Popular documents will usually be
fetched from caches rather than on the original document servers. The
problem documents will be the ones that are not popular enough to stay
in caches but still get accessed fairly often.
Finally, there is the question (yet again) of why this particular
"dns:" scheme is being called a URN instead of a URL? It looks like
a URL, it acts like a URL, it's being used like a URL, and there is
no guarantee (other than some "social agreement") that it is any less
transient than a URL.
Yes, URLs could be made location independent (thus making URL a
misnomer) by requiring servers of documents to live forever
(impossible) and forward any references to them, or by requiring the
parent of a server that moves to forward all references to the server
to its current address. The second thing is essentially what we are
requiring of the "dns:" scheme, and to facilitate this, a separate
branch off the root of the DNS tree may be used to separate publishers
from the current organizational structure. (Mitra, please post your
rational for this.)
URNs are essentially URLs for URCs. The fact that URCs are returned
does make the use of URNs different from that of URLs, unless we unify
URCs with documents and identify a URC with a document type. e.g. the
first line before a URC might be "Content-type: urc/asn.1". Maybe
that is not a bad idea.
Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications