- From: Paul Hoffman <ietf-lists@proper.com>
- Date: Thu, 8 Jun 1995 10:03:16 -0700
- To: weibel@oclc.org
- 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
Received on Thursday, 8 June 1995 13:06:28 UTC