Re: OCLC's URN Services Proposal

Paul Hoffman (ietf-lists@proper.com)
Thu, 8 Jun 1995 10:03:16 -0700


Message-Id: <v02120c0babfcd7e5a9d3@[165.227.40.38]>
Date: Thu, 8 Jun 1995 10:03:16 -0700
To: weibel@oclc.org
From: ietf-lists@proper.com (Paul Hoffman)
Subject: Re: OCLC's URN Services Proposal
Cc: uri@bunyip.com

>The great majority of the time, the client software will specify the
>resolution service(s) to be applied to the URN (see section X).  One
>can also imagine situations where it would be useful to let an author
>embed a service request in the URN...  to highlight a particular
>projection of the metadata for the object, for example.  Do we really
>want to make this impossible?

No, not impossible. However, you may want to emphasize in your I-D that
specifying the service is the rare case, and most URNs would just look like
NA/OS.

>Our notion was that any but the simplest of clients will in fact
>implement a resolution strategy based on a series of attempted service
>resolutions.  ...
>Some syntax that would let you actually get multiple service requests
>fulfilled simultaneously does make sense.  This requires further
>thought.  Independence of services is still the safest starting place.
>Imagine a service, for example, that resolves to terms and conditions.
>Such a service might well be fulfilled by a different resolution server
>than the one that resolves location.

Sending multiple requests to a single server works, but it also wastes
Internet bandwidth (and the user's time) because of the multiple retries
needed in the case of a server that only emits lowest-level (N2L)
responses. A much better way would be for the client to tell each server
tested the user's entire preferred list of response types, using a single
message.

When you add the specification for the transport protocol you intend to
use, please consider this seriously. Again, this is one reason why Ron and
I chose HTTP, although there are other protocols such as whois++ that also
support this.

--Paul Hoffman
--Proper Publishing