Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31

> I don't know how I can make this any clearer:
> 
> 1. I (and others who were at Knoxville) have said, repeatedly, that
> the client chooses how to resolve a URN.  (One of our oft-stated
> design principles was "a client can and will do whatever it wants to".)

The client can only do this if it has some way to differentiate between
URN schemes.  You are assuming that there will be only one URN scheme.
That is ridiculous, has been discussed many times before, does not correspond
to any notion of networked resources that the IETF has ever dealt with
in the past, and any system designed with that assumption is already
broken by design.  Worse, you gain no advantage by designing a prototype
system based on that assumption.

Any resource may be identified by multiple names and/or locations.
Any resource which is "the current version of X" is also "that specific
version of X" -- both of these concepts can and should be assigned names
if it is determined (by anyone) that such a name is useful.  Thus, any
system that purports to define URNs must also allow multiple names per
resource.

Requiring that all URNs have the same properties (i.e., case insensitive,
references an entity fixed-for-all-time, etc.) would make it impossible
to represent resource names as URNs.  Requiring that all URNs within a
given URN scheme have certain minimum properties is useful, but not
sufficient to contain all of the semantics any particular user would
assign to any particular resource.  Allowing a resource to be identified
by multiple URN schemes, with each such URN scheme defining its own set
of relevant semantics, is the only way to sufficiently *identify resources*
using a simple identity string.

> 2. I have also said, repeatedly, that the URN syntax that we defined
> is NOT tied to DNS, that other registries besides the DNS registry
> are expected.  It is essential that the syntax does not imply DNS -- 
> if for no other reason than to allow transitions to other registries 
> in the long term.

If the only way a client can determine the type and semantics of an
identifier is to perform a DNS query on some part of that identifier,
then the identifier is tied to DNS.

> 3. URN: in the Knoxville proposal is NOT a "scheme".  URN: is a prefix 
> that allows clients to identify URNs in text and to distinguish URNs 
> from other kinds of URIs.  The Knoxville proposal doesn't have "schemes",
> because -- to the extent a "scheme" dictates a resolution protocol --
> the inclusion of a "scheme" impairs the longevity of the URN.

Then you don't understand what a scheme is.  A scheme defines the syntax and
semantics associated with the remainder of the identifier.  It does not
define the resolution protocol; some identifiers have a scheme name which
matches a protocol name because that is the most meaningful name to
associate with a locator for which the ultimate resolution process defaults
to using that protocol.  In other words, the Knoxville proposal is using
the scheme "URN".

World-Wide Web user agents use the identifier scheme to determine the
resolution mechanism (NOT protocol -- mechanism is that *thing* which is
responsible, within or outside the client, for resolving identifiers of
that particular identifier type -- it may use any protocol defined by
the user or vendor for resolving that scheme, including a protocol defined
on-the-fly through retrieval of a script).  This allows any identifier
to be independent of a resolution mechanism.  Advanced clients will be
capable of associating any URI prefix with any resolution mechanism,
including multiple resolution mechanisms if the first one fails,
but the most important, distinguishing part of an identifier prefix is
the identifier scheme.

Uniform Resource Names is a category of identifiers, referring to those
that identify a resource independent of its network location.  It is wrong
to use "URN" as a scheme name for the same reason it is wrong to use
"URL" as a scheme name.

   I CANNOT USE ANY IDENTIFIER THAT BEGINS WITH "URN:"

Which means, obviously, that I will forbid the use of such an identifier
in any system which I design or am responsible for standardization.
That is what I've said consistently for over 1.5 years now, that is what
I will recommend to the W3 Consortium members, and that is the objection
I will continue to raise every time this is discussed within the IETF.

Is that clear?

>> All you have done is define a single scheme-uber-alles called "URN".
>> That is not desirable, reduces flexibility and robustness, and standardizes
>> mechanisms that have no implementation experience on a global scale.
> 
> URN: is not a scheme.  And you have failed to justify your other attacks.
> In particular, you have not explained why any of the following is 
> undesirable, inflexible, or non-robust:
> 
>   + a common prefix and NA space for all URNs

See above.  And this is at least the fourth time I have provided sufficient
reason and argument for why a common prefix and NA space for all URNs
is both unnecessary and undesirable [see the mailing list archive]. 
Not once has ANYONE come up with any proof that a single URN scheme is
necessary and sufficient to encompass all resource names.  As far as I'm
concerned, this discussion is closed until such time as that proof is given.

>   + using domain names for that NA space (as long as it's possible
>     to define new domain names that have better longevity properties 
>     than existing domain names)

I have no problems with that, providing the identifier is distinguishable
as such.  In fact, I encourage it.

>   + resolution services for URNs are advertised in one or more
>     global registries. clients need not be configured to resolve
>     URNs on a per-scheme basis; they can simply consult one or more
>     of the registries to see which services/protocols are available. 
>     (clients can special-case lookups for part of the name space
>     if they want to; but the ability to resolve a URN doesn't depend
>     on them doing so.)  

And how does the client get "configured to consult one of the registries"?
The WWW mechanism for doing this depends on the existence of scheme names.
Relative URL parsing depends on the existence of scheme names.  Hell, ALL
EXISTING IMPLEMENTATIONS OF URIs DEPEND ON THE EXISTENCE OF SCHEME NAMES.

>   + building one of those registries using DNS, so we can get quick
>     deployment, and so that anyone on the Internet can use it.

Fine by me.

> Nothing about our proposal requires the client to use the URN registries.
> But if we were to design a scheme such that a client NEEDS "to define, 
> without reference to any network, how identifiers are to be resolved", 
> THAT would be undesirable.
> 
> As for being able to "resolve" a URN without being connected to the network...
> I don't know what this means.  Either the client has access to the external 
> services it needs to make use of a URN, or it doesn't.  If the client doesn't
> have access to those services, the URN isn't very useful to the client
> except for comparison with other URNs.

You obviously haven't read the references I posted earlier.
Here they are again:

  http://www.acl.lanl.gov/URI/archive/uri-94q4.messages/0093.html
  http://www.acl.lanl.gov/URI/archive/uri-94q4.messages/0101.html
and
  http://www.ics.uci.edu/pub/ietf/uri/draft-ietf-uri-roy-urn-urc-00.txt

Note that the last one is an Internet-Draft posted to the URI WG shortly
before the Stockholm meeting.

If you don't support the identification of resources that may already
be on your local disk, identified within a personal database of resources
located in a real-world bookshelf, or located within the user's local
University library, then you have failed to solve the URN problem.
You don't have to define these resolution mechanisms -- you just have
to make them possible with minimum difficulty.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 29 November 1995 04:32:25 UTC