# Re: OCLC's URN Services Proposal

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

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: owner-uri@bunyip.com: "Re: OCLC's URN Services Proposal"
- Previous message: Paul Hoffman: "Re: OCLC's URN Services Proposal"
- In reply to: Paul Hoffman: "Re: OCLC's URN Services Proposal"
- Next in thread: owner-uri@bunyip.com: "Re: OCLC's URN Services Proposal"

    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)

    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

- Next message: owner-uri@bunyip.com: "Re: OCLC's URN Services Proposal"
- Previous message: Paul Hoffman: "Re: OCLC's URN Services Proposal"
- In reply to: Paul Hoffman: "Re: OCLC's URN Services Proposal"
- Next in thread: owner-uri@bunyip.com: "Re: OCLC's URN Services Proposal"