Re: OCLC's URN Services Proposal

Paul Hoffman (ietf-lists@proper.com)
Wed, 14 Jun 1995 20:35:40 -0700


Message-Id: <v02120c1fac054d7a64d7@[165.227.40.35]>
Date: Wed, 14 Jun 1995 20:35:40 -0700
To: uri@bunyip.com
From: ietf-lists@proper.com (Paul Hoffman)
Subject: Re: OCLC's URN Services Proposal
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