To: uri@bunyip.com
Subject: Re: Current URN syntax is unacceptable
In-Reply-To: Your message of "Tue, 25 Oct 1994 09:38:14 CDT."
<9410251438.AA06067@void.ncsa.uiuc.edu>
Date: Tue, 25 Oct 1994 23:58:01 -0700
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Message-Id: <9410252358.aa20034@paris.ics.uci.edu>
[I wrote:]
>>The following syntax (as seen in <URL:http://www.path.net/mitra/urn.html>)
>>is unacceptable for use as a URN standard.
>>
>> URN:dns:path.net:mitra1234
>>>
>>should be
>>
>> dns:/path.net/mitra1234
>>or
>> urn:/dns/path.net/mitra1234
>>
>>so as to preserve a common URI syntax, as previously agreed
>>on this forum.
And Dan LaLiberte replied:
> This would be acceptable to me as long as we can have knowledge of
> where a public, hierarchical namimg scheme is used. I.e., immediately
> after "dns" is a domain name. The use of colons as separators suggests
> that everything before the last colon is public, as intended.
That is not what ":" suggests to me. "name:" suggests "what follows is
a name". "urn:" makes sense (though I think it is redundant, just as
URL: was redundant for URLs). "dns:" makes sense, providing that everything
following it remains in the DNS naming scheme. "path.net:" makes no
sense. And what happens when the opaque name contains a ":"?
The fact is that all this colon-business is just a misguided attempt
to use ":" instead of "/" as a hierarchical component separator. 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 has the advantages of
1) being easily parsable
2) does not place arbitrary constraints on scalability
3) does not prevent other URN schemes from coexisting (i.e. Message-IDs)
>[...]
>
> There is a good reason for constraints. To be scalable (i.e. to get
> locality of reference), there must be a public, hierarchical naming
> system. 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). This is the only reasonable way of handling
this situation -- the URI group is simply not capable of selecting a fixed
set of names that will be acceptable and sufficient for all time.
Similarly, any given entity is likely to have multiple URN names.
>[...]
>
> Slight diversion: I actually would prefer a more uniform scheme that
> is thoroughly hierarchical all the way down, even throughout the
> "opaque" string (or for grandfathered schemes, as far as they have
> gone). This lets a naming authority either handle its hierarchical
> name space all by itself or delegate parts of it to subauthorities as
> required by the load, and clients can then cache the locations of
> subauthorities. ...
Yep, definitely for any URN where hierarchy is present.
> 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. Any entity worthy of a URN is likely to have
a request rate equal to the rate of growth/decline of its audience.
Except for explicit obsolescence, the audience for such entities rarely
declines -- certainly not in this era of Internet growth.
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.
However, given that the URN functional requirements are about
as likely to be achievable as a quest for the Holy Grail, I would be
satisfied just to have the implementors' group design a truly hierarchical
URL scheme. The degree to which they stick with the URI syntax will
determine the usefulness of that scheme.
......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>