rfc2169.txt

RFC 的详细文档！

   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.








Daniel                        Experimental                      [Page 5]

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.






































Daniel                        Experimental                      [Page 6]

RFC 2169                 HTTP in URN Resolution                June 1997


Appendix A: The text/uri-list Internet Media Type
=================================================
[This appendix will be augmented or replaced by the registration of the
text/uri-list IMT once that registration has been performed].

   Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns,
   L2Ls, result in a list of URIs being returned to the client. The
   text/uri-list Internet Media Type is defined to provide a simple
   format for the automatic processing of such lists of URIs.

   The format of text/uri-list resources is:

   1) Any lines beginning with the '#' character are comment lines
      and are ignored during processing. (Note that '#' is a character
      that may appear in URIs, so it only denotes a comment when it is the
      first character on a line).
   2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded
      according to the URI specification RFC[6]. Each URI shall appear on
      one and only one line.
   3) As for all text/* formats, lines are terminated with a CR LF pair,
      although clients should be liberal in accepting lines with only
      one of those characters.

   In applications where one URI has been mapped to a list of URIs, such
   as in response to the N2Ls request, the first line of the text/uri-
   list response SHOULD be a comment giving the original URI.

   An example of such a result for the N2L request is shown below in
   figure 1.

        # urn:cid:[e-mail]
        http://www.huh.org/cid/foo.html
        http://www.huh.org/cid/foo.pdf
        ftp://ftp.foo.org/cid/foo.txt

               Figure 1: Example of the text/uri-list format

Appendix B:  n2l.pl script
==========================

   This is a simple CGI script for the N2L resolution service. It
   assumes the presence of a DBM database to store the URN to URL
   mappings. This script does not specify standard behavior, it is
   provided merely as a courtesy for implementors. In fact, this script
   does not process incoming Accept: headers, nor does it generate
   status codes. Such behavior should be part of a real script for any
   of the resolution services.




Daniel                        Experimental                      [Page 7]

RFC 2169                 HTTP in URN Resolution                June 1997


    #!/bin/perl
    # N2L  - performs urn to url  resolution

    $n2l_File = "...filename for DBM database...";


    $urn = $ENV{'QUERY_STRING'} ;

    # Sanity check on the URN. Minimum length of a valid URN is
    # 7 characters - "urn:", a 1-character Namespace ID, ":", and
    # a 1-character namespace-specific string. More elaborate
    # sanity checks should be part of a real resolver script.
    if(length($urn)<7)
    {
        $error=1;
    }

    if(!$error)
    {
        # Convert lexically equivalent versions of a URI into
        # a canonical version for DB lookups.
        $urn =~ s/^urn:([^:]*):(.*)$/sprintf("urn:%s:%s", lc $1, $2)/ie;

        dbmopen(%lu,$n2l_File,0444);
        if($lu{$urn})
        {
            $url=$lu{$urn};
            print STDOUT "Location: $url\n\n";
        }else{
            $error=2;
        }
        dbmclose(%lu);
    }

    if($error)
    {
        print "Content-Type: text/html \n\n";
        print "<html>\n";
        print "<head><title>URN Resolution: N2L</title></head>\n";
        print "<BODY>\n";
        print "<h1>URN to URL resolution failed for the URN:</h1>\n";
        print "<hr><h3>$urn</h3>\n";
        print "</body>\n";
        print "</html>\n";
    }

    exit;




Daniel                        Experimental                      [Page 8]

RFC 2169                 HTTP in URN Resolution                June 1997


References:
===========

   [1] Daniel, Ron and Michael Mealling, RFC 2168, "Resolution of Uniform
       Resource Identifiers using the Domain Name System", June 1997.

   [2] Berners-Lee, T, R. Fielding, H. Frystyk, RFC 1945, "Hypertext
       Transfer Protocol -- HTTP/1.0", T. Berners-Lee, May 1996.

   [3] Fielding, R., J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee,
       RFC 2068, "Hypertext Transfer Protocol -- HTTP/1.1", Jan. 1997.

   [4] Moats, R., RFC 2141, "URN Syntax", May 1997.

   [5] URN-WG. "URN Resolution Services". Work In Progress.

   [6] Berners-Lee, T., RFC 1630, "Universal Resource Identifiers in WWW:
       A Unifying Syntax for the Expression of Names and Addresses of
       Objects on the Network as used in the World-Wide Web", June 1994.

Security Considerations
=======================

   Communications with a resolver may be of a sensitive nature. Some
   resolvers will hold information that should only be released to
   authorized users. The results from resolvers may be the target of
   spoofing, especially once electronic commerce transactions are common
   and there is money to be made by directing users to pirate
   repositories rather than repositories which pay royalties to
   rightsholders. Resolution requests may be of interest to traffic
   analysts. The requests may also be subject to spoofing.

   The requests and responses in this draft are amenable to encoding,
   signing, and authentication in the manner of any other HTTP traffic.

Author Contact Information:
===========================

   Advanced Computing Lab, MS B287
   Los Alamos National Laboratory
   Los Alamos, NM, USA, 87545
   voice:  [phone]
   fax:    [phone]
   email:  [e-mail]







Daniel                        Experimental                      [Page 9]