rfc2276.txt

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

                                 |
                                 |
              (return rule or URN resolver service reference)
                                 |
                                 +----------------------------------+
                                 |                                  |
                       +->(apply rule to determine RDS server)      |
                       |         |                                  |
                       |         |                                  |
                       |         |                                  |
                       |    +----------+                            |
                       |    |RDS server|          +-----------------+
                       |    +----------+          |
                       |      |   |               v
                       |      |   |   (set of choices)
                       |      |   +----+----------(...)--------+
                       |   (rule)      |                       |
                       |      |        |                       |
                       |      |        |                       |
                       +------+        |                       |
                                       v                       v
                                  +----------+            +----------+
                                  |URN       |            |URN       |
                                  |resolver  |            |resolver  |
                                  |service   |            |service   |
                                  +----------+            +----------+

                       Figure 1: An RDS framework

   The NID defines a top level syntax.  This syntax will determine
   whether the NID alone or in conjunction with some extraction from the
   NSS (for the top level naming authority name) is to be used to
   identify the first level server to be contacted.  At each stage of
   the lookup either a new rule for generating the strings used in yet
   another lookup (the strings being the identity of another RDS server
   and possibly a string to be resolved if it is different than the
   original URN) or a reference outside the RDS to a URN resolver
   service, sidestepping any further use of the RDS scheme.  Figure 1



Sollins                      Informational                     [Page 20]

RFC 2276            Uniform Resource Name Resolution        January 1998


   depicts this process.

   There are several points worth noting about the RDS framework.
   First, it leaves open the determination of the protocols, data
   organization, distribution and replication needed to support a
   particular RDS scheme.  Second, it leaves open the location of the
   computations engendered by the rules.  Third, it leaves open the
   possibility that partitioning (distribution) of the RDS database need
   not be on the same boundaries as the name delegation.  This may seem
   radical to some, but if the information is stored in balanced B-trees
   for example, the partitioning may not be along those naming authority
   delegation boundaries (see [7]).  Lastly, it leaves open access to
   the Global NID Registry.  Is this distributed to every client, or
   managed in widely distributed servers?  It is important to note that
   it is the intention here that a single RDS scheme is likely to
   support names from many or all naming schemes, as embodied in their
   NIDs.

   One concept that has not been addressed in Figure 1 is that there may
   be more than one RDS available at any given time, in order to allow
   for evolution to new schemes.  Thus, the picture should probably look
   more like Figure 2.





























Sollins                      Informational                     [Page 21]

RFC 2276            Uniform Resource Name Resolution        January 1998


                         URN:<NID>:<NSS>
                               |
                               |
                   +-----------+-------(...)-------+
                   |                               |
                   |                               |
                   |                               |
                   v                               v
         +---------------------+        +---------------------+
         |Global NID registry 1|        |Global NID registry N|
         +---------------------+        +---------------------+
                   .                               .
                   .                               .
                   .                               .


             Figure 2: More than one co-existing RDS scheme

   If we are to support more than one co-existing RDS scheme, there will
   need to be coordination among them with respect to storage and
   propagation of information and modifications.  The issue is that
   generally it should be assumed that all information should be
   available through any operational RDS scheme.  One cannot expect
   potential publishers to submit updates to more than one RDS scheme.
   Hence there will need to be a straightforward mapping of information
   from one to the other of these schemes.  It is possible that that
   transformation will only go in one direction, because a newer RDS
   service is replacing an older one, which is not kept up to date, in
   order to encourage transfer to the newer one.  Thus, at some point,
   updates may be made only to the newer one and not be made available
   to the older one, as is often done with library catalogs.

   This framework is presented in order to suggest to RDS scheme
   designers a direction in which to start designing.  It should be
   obvious to the reader that adherence to this framework will in no way
   guarantee compliance with the guidelines or even the assumptions
   described in Sections 2 and 3.  These must be reviewed independently
   as part of the design process.  There is no single correct design
   that will conform to these guidelines.  Furthermore, it is assumed
   that preliminary proposals may not meet all the guidelines, but
   should be expected to itemized and justify any lack of compliance.










Sollins                      Informational                     [Page 22]

RFC 2276            Uniform Resource Name Resolution        January 1998


5. Acknowledgments

   Foremost acknowledgment for this document goes to Lewis Girod, as my
   co-author on a preliminary URN requirements document and for his
   insightful comments on this version of the document.  Thanks also go
   to Ron Daniel especially for his many comments on my writing.  In
   addition, I recognize the contributors to a previous URN framework
   document, the "Knoxville" group.  There are too many of you to
   acknowledge here individually, but thank you.  Finally, I must thank
   the contributors to the URN working group and mailing list (urn-
   [e-mail]), for your animated discussions on these and related
   topics.

6. References

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

   [2] Sollins, K., and L. Masinter, "Functional Requirements for
   Uniform Resource Names", RFC 1738, December 1994.

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

   [4] URN Working Group, "Namespace Identifier Requirements for URN
   Services," Work in Progress.

   [5] Voydock, V. L., and Kent, S. T., "Security Mechanisms in High-
   Level Protocols", ACM Computing Surveys, v. 15, No. 2, June, 1983,
   pp. 135-171.

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

   [7] Slottow, E.G., "Engineering a Global Resolution Service," MIT-
   LCS-TR712, June, 1997.  Currently available as
   <http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps> or
   <http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>.

7. Author's Address

   Karen Sollins
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA 02139

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




Sollins                      Informational                     [Page 23]

RFC 2276            Uniform Resource Name Resolution        January 1998


8.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Sollins                      Informational                     [Page 24]