W3C home > Mailing lists > Public > uri@w3.org > June 1995

Re: OCLC's URN Services Proposal

From: Paul Hoffman <ietf-lists@proper.com>
Date: Wed, 14 Jun 1995 20:35:40 -0700
Message-Id: <v02120c1fac054d7a64d7@[165.227.40.35]>
To: uri@bunyip.com
Cc: weibel@oclc.org
About a week ago, in my response to the OCLC proposal, I said:

>RPs
>I like this idea very much. Assuming that the RPs are generated
>by the client software resolving a registered NA and seeing
>which of the hosts it prefers, this has many big advantages over
>our DNS-only scheme. More kudos for this.

On further thought, I'd like to retract my "I like this idea very much". I
believe that RPs (resolution paths) that are specified as part of an
electronic or printed URN string are a Bad Idea. Basically, including RPs
in electronic or printed URN strings can lead to incorrect resolution of
the URNs.

Consider the short example of a URN with an RP from the original text:
N2L:/ncsa.uiuc.edu:120/RFC/paper1.1995

Now consider the situation five years from now. What if the owner of the
name "RFC" no longer wants ncsa.uiuc.edu to keep resolving its names, but
the people at ncsa.uiuc.edu choose to do so against the wishes of the owner
of RFC? People resolving the URN would be getting the resolution from a
source now known to be bad, possibly even malicious (apologies to anyone at
UIUC!).

If ncsa.uiuc.edu stops resolving URNs for RFC, the resolution will continue
correctly. However, even in this case, every access to that URN will cause
wasted bandwidth and wasted user time because they will contact
ncsa.uiuc.edu and get a negative response or, worse, a timeout. Make the RP
list three or four out-of-date hosts and resolving a URN will become a
tedious process.

I believe that we should avoid putting any such list in URN representations.

--Paul Hoffman
--Proper Publishing
Received on Wednesday, 14 June 1995 23:47:23 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:30 UTC