list.

3.3  N2R (URN to Resource):
---------------------------

   The request is encoded as above. The resource is returned using
   standard HTTP mechanisms. The request may be modified using the
   Accept: header as in normal HTTP to specify that the result be given
   in a preferred Internet Media Type.

3.4  N2Rs (URN to Resources):
-----------------------------

   This resolution service returns multiple instances of a resource, for
   example, GIF and JPEG versions of an image. The judgment about the
   resources being "the same" resides with the naming authority that
   issued the URN.

   The request is encoded as above. The result shall be a MIME
   multipart/alternative message with the alternative versions of the
   resource in seperate body parts. If there is only one version of the
   resource identified by the URN, it MAY be returned without the




 
RFC 2169                 HTTP in URN Resolution                June 1997


   multipart/alternative wrapper. Resolver software SHOULD look at the
   Accept: header, if any, and only return versions of the resource that
   are acceptable according to that header.

3.5  N2C (URN to URC):
----------------------

   URCs (Uniform Resource Characteristics) are descriptions of other
   resources. This request allows us to obtain a description of the
   resource identified by a URN, as opposed to the resource itself.  The
   description might be a bibliographic citation, a digital signature, a
   revision history, etc. This document does not specify the content of
   any response to a URC request. That content is expected to vary from
   one resolver to another.

   The format of any response to a N2C request MUST be communicated
   using the ContentType header, as is standard HTTP practice. The
   Accept: header SHOULD be honored.

3.6  N2Ns (URN to URNs):
------------------------

   While URNs are supposed to identify one and only one resource, that
   does not mean that a resource may have one and only one URN. For
   example, consider a resource that has something like "current-
   weather-map" for one URN and "weather-map-for-datetime-x" for another
   URN. The N2Ns service request lets us obtain lists of URNs that are
   believed equivalent at the time of the request. As the weathermap
   example shows, some of the equivalances will be transitory, so the
   standard HTTP mechanisms for communicating cachability MUST be
   honored.

   The request is encoded as above. The result is a list of all the
   URNs, known to the resolver, which identify the same resource as the
   input URN. The result shall be encoded as for the N2Ls request above
   (text/uri-list unless specified otherwise by an Accept: header).

3.7  L2Ns (URL to URNs):
----------------------

   The request is encoded as above. The response is a list of any URNs
   known to be assigned to the resource at the given URL. The result
   shall be encoded as for the N2Ls and N2Ns requests.









 
RFC 2169                 HTTP in URN Resolution                June 1997


3.8  L2Ls (URL to URLs):
------------------------

   The request is encoded as described above. The result is a list of
   all the URLs that the resolver knows are associated with the resource
   located by the given URL. This is encoded as for the N2Ls, N2Ns, and
   L2Ns requests.

3.9  L2C (URL to URC):
----------------------

   The request is encoded as above, the response is the same as for the
   N2C request.