# Re: OCLC's URN Services Proposal

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

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Rich Salz: "Comment on draft..."
- Previous message: Paul Hoffman: "Re: OCLC's URN Services Proposal"
- Maybe in reply to: weibel@oclc.org: "OCLC's URN Services Proposal"
- Next in thread: roxanab@attmail.com: "Re: OCLC's URN Services Proposal"

    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

>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

- Next message: Rich Salz: "Comment on draft..."
- Previous message: Paul Hoffman: "Re: OCLC's URN Services Proposal"
- Maybe in reply to: weibel@oclc.org: "OCLC's URN Services Proposal"
- Next in thread: roxanab@attmail.com: "Re: OCLC's URN Services Proposal"