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