Re: OCLC's URN Services Proposal

Michael Shapiro (mshapiro@ncsa.uiuc.edu)
Thu, 15 Jun 1995 06:00:01 -0500 (CDT)


From: mshapiro@ncsa.uiuc.edu (Michael Shapiro)
Message-Id: <9506151100.AA13626@void.ncsa.uiuc.edu>
Subject: Re: OCLC's URN Services Proposal
To: ietf-lists@proper.com (Paul Hoffman)
Date: Thu, 15 Jun 1995 06:00:01 -0500 (CDT)
Cc: uri@bunyip.com
In-Reply-To: <v02120c1fac054d7a64d7@[165.227.40.35]> from "Paul Hoffman" at Jun 14, 95 08:35:40 pm

   Paul, I think I agree with what you are saying. If  there  are
to  be  alternate  resolution  services,  then they should not be
bound in the name but discovered during the lookup. There  is  an
example  of  this idea in our path scheme. (I'm not claiming here
that the specifics of the  path  scheme  are  THE  right  way  to
provide alternates).  I think that the binding for the resolution
service should be made more  dynamic  -  that  way  it  could  be
reconfigured "behind the scenes"

   I don't like arguments like we shouldn't do something  because
of    wasted   bandwidth.   This   puts   implementation   before
functionality. (And obscures the real issues). The only  argument
you  need  to  make is the one about the RP (and/or the NA) going
away or being malicious. Also, I  think  we  will  only  get  the
functionality   we  need  with  some  level  of  indirection  and
iteration and that will always be more costly.

Paul Hoffman wrote:
|
|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
|
|
|


-- 
Michael Shapiro                   mshapiro@ncsa.uiuc.edu
NCSA                              (217) 244-6642
605 E Springfield Ave. RM 152CAB  fax: (217) 333-5973
Champaign, IL 61820