rfc2483.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2483                URI Resolution Services             January 1999


           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

   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 one organization wishes to name
   'foo'; another organization, in agreement with the first, wants to
   call the resource 'bar'. Both organizations can agree that both names
   'name' the same resource and that the URNs 'foo' and 'bar' are
   equivalent.

   The result is a URN, known to the server, that identifies the same
   resource as the input URN.

   Extreme care should be taken with this service as it toys with the
   idea of equality with respect to URNs. As mentioned in several URN
   documents, the idea of equality is very domain specific. For example,
   a URN pointing to a weather map for a particular day and a URN
   pointing to the map as it changes from day to day would NOT be
   returned in this example because they point to do different
   resources. Some other concept of temporary equivalence is at work.
   This service instead deals with resources that have two different
   names where there is a binding between the names that is agreed by
   both name assigners. I.e., both namespaces MUST have agreed that the
   each name can be used in place of the other and the meaning does not
   change.

4.8 I2Ns (URI to URNs)

      * Name: URI to URNs
      * Mnemonic: I2NS
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URI.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: A list of URNs
      * Errors:
           o Malformed URI
           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)



Mealling & Daniel             Experimental                      [Page 9]

RFC 2483                URI Resolution Services             January 1999


           o Denial of Service (see I2L)

   This operation simply returns zero or more URNs following the same
   criteria and cautions as the I2N operation.

4.9 I=I (Is URI equal to URI):

      * Name: URI = URI
      * Mnemonic: I=I
      * Number of Operands: 2
      * Type of Each Operand: Both operands are URIs.
      * Format of Each Operand: Both operands are encoded as a URIs.
      * Algorithm: Opaque
      * Output: TRUE or FALSE
      * Errors:
           o Malformed URIs
           o URIs are syntactically valid but do not exist in any form.
           o URIs exist but there is no available output from this
             operation.
           o URIs existed in the past but nothing is currently known
             about them.
           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

   This operation is used to determine whether two given URIs are
   considered to be equal by the server being asked the question. The
   algorithm used to determine equality is opaque. No assertions are
   made about whether or not the URIs exhibits characteristics of URNs
   or URLs.




















Mealling & Daniel             Experimental                     [Page 10]

RFC 2483                URI Resolution Services             January 1999


5. The text/uri-list Internet Media Type

   Several of the resolution service requests, such as I2Ls, I2Ns,
   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.

   This is a copy of the IANA registration of the text/uri-list Media
   Type.

    Date: Fri, 18 Apr 97 08:36:07 PDT
    From: Ron Daniel Jr. <[e-mail]>
    To: [e-mail], [e-mail]
    Subject: Request for MIME media type Text/IETF Tree - uri-list

    Name : Ron Daniel Jr.

    E-mail : [e-mail]

    MIME media type name : Text

    MIME subtype name : IETF Tree -uri-list

    Required parameters : none

    Optional parameters : charset

    Currently, URIs can be represented using US-ASCII. However, there
    are many non-standard URIs which use special character sets.
    Discussion of how to best achieve internationalization of URIs is
    underway. This registration will be updated with a discussion of the
    URI charsets once that discussion has concluded.

    Encoding considerations : Some transfer protocols, such as SMTP,
    place limits on the length of lines. Very long URIs might exceed
    those limits. Systems must therefore be prepared to use a suitable
    content transfer encoding. This is anticipated to be a rare
    occurance.

    Security considerations : Client software should be aware of the
    security considerations of URIs.  For example, accessing some URIs
    can result in sending a death threat to a head of state, frequently
    prompting a visit from the relevant protective service.  Accessing
    other URIs may result in financial obligations, or access to
    resources considered inappropriate by one's employer.






Mealling & Daniel             Experimental                     [Page 11]

RFC 2483                URI Resolution Services             January 1999


    While the legitimate provider of a uri-list could exploit these
    properties for good or ill, it is more likely that uri-lists will be
    falsified in order to exploit such characteristics of URIs.

    Additionally, the lookup and reverse lookup potential of the uri-
    list may be attractive to traffic analysts. URI lists may also
    reveal confidential information, such as the location of sensitive
    information.

    Because of these considerations, external confidentiality measures
    should be available to protect uri-list responses when appropriate.

    Interoperability considerations : none known

    Published specification : Uniform Resource Locators (URLs) and
    Uniform Resource Names (URNs) are two instances of the more general
    class of identifiers known as Uniform Resource Identifiers (URIs).
    URN resolution methods frequently wish to return lists of URLs for a
    resource so that fault-tolerance and load balancing can be achieved.
    The text/uri-list format is intended to be a very simple format for
    communicating such lists of URLs (and URNs) in a form suitable for
    automatic processing.

    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 URIs may contain
        the '#' character, so it is only a comment character when it is
        the first character on a line.)

    2) The remaining non-comment lines shall be URIs (URNs or URLs),
        encoded according to the URL or URN specifications (RFC2141,
        RFC1738 and RFC2396). Each URI shall appear on one and only one
        line. Very long URIs are not broken in the text/uri-list format.
        Content-transfer-encodings may be used to enforce line length
        limitations.

    3) As for all text/* formats, lines are terminated with a CRLF pair.

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









Mealling & Daniel             Experimental                     [Page 12]

RFC 2483                URI Resolution Services             January 1999


    An example of the format is given below:

      # urn:isbn:0-201-08372-8
      http://www.huh.org/books/foo.html
      http://www.huh.org/books/foo.pdf
      ftp://ftp.foo.org/books/foo.txt

    Applications which use this media : URN resolvers are the initial
    applications. Web clients and proxies are applications that are
    likely to support this format in the future.

    Additional information :

    1. Magic number(s) : none at this time
    2. File extension(s) : .uris or .uri recommended
    3. Macintosh file type code : URIs recommended

    This media type is the product of the URN working group of the IETF.

    Person to contact for further information :

    1. Name : Ron Daniel Jr.
    2. E-mail : [e-mail]

    Intended usage : Limited Use
    The text/uri-list media type is intended for use in applications
    which utilize URIs for replicated resources.

    Author/Change controller : Ron Daniel Jr.
    Los Alamos National Laboratory
    [e-mail]




















Mealling & Daniel             Experimental                     [Page 13]

RFC 2483                URI Resolution Services             January 1999


   In applications where one URI has been mapped to a list of URIs, such
   as in response to the I2Ls 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 I2L request is shown below in Figure 1.

6. Security Considerations

   Communications with a server may be of a sensitive nature. Some
   servers will hold information that should only be released to
   authorized users. The results from servers 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 that pay royalties to rights-
   holders. Server requests may be of interest to traffic analysts. The
   requests may also be subject to spoofing.

   The "Access denied" error message assumes a system within which the
   operation is being performed that can convey an authenticated concept
   of access control. Thus, the "Access denied" message should only be
   returned by systems that have an appropriate method of determining
   access control.

7. References

   [1] Berners-Lee, T., "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", RFC 1630,
       June 1994.

   [2] Daniel, R., and Mealling, M., "Resolution of Uniform Resource
       Identifiers using the Domain Name System", RFC 2168, February
       1997.

   [3] Moats, R., "URN Syntax", RFC 2141, January 1997.

   [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part One: Format of Internet Message Bodies",
       RFC 2045, November 1996.

   [5] Sollins, K., "Architectural Principles of Uniform Resource Name
       Resolution", RFC 2276, January 1998.

   [6] Kunze, J., "Functional Recommendations for Internet Resource
       Locators", RFC 1736, February 1995.

   [7] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
       Locators (URL)", RFC 1738, December 1994.




Mealling & Daniel             Experimental                     [Page 14]

RFC 2483                URI Resolution Services             January 1999


8. Authors' Addresses

   Michael Mealling
   Network Solutions
   505 Huntmar Park Drive
   Herndon, VA 22070

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Ron Daniel
   Advanced Computing Lab, MS B287
   Los Alamos National Laboratory
   Los Alamos, NM, USA, 87545

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]































Mealling & Daniel             Experimental                     [Page 15]

RFC 2483                URI Resolution Services             January 1999


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Mealling & Daniel             Experimental                     [Page 16]