Movatterモバイル変換

Network Working Group                                        M. MeallingRequest for Comments: 3401                                      VeriSignUpdates:2276                                               October 2002Obsoletes:2915,2168Category: InformationalDynamic Delegation Discovery System (DDDS)Part One: The Comprehensive DDDSStatus of this Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2002).  All Rights Reserved.Abstract   This document specifies the exact documents that make up the complete   Dynamic Delegation Discovery System (DDDS).  DDDS is an abstract   algorithm for applying dynamically retrieved string transformation   rules to an application-unique string.   This document along withRFC 3402,RFC 3403 andRFC 3404 obsoleteRFC2168 andRFC 2915, as well as updatesRFC 2276.1. Intended Audience   This document and the documents that it references are intended for   anyone attempting to implement or understand the generic DDDS   algorithm, URI Resolution, ENUM telephone number to URI resolution,   and the NAPTR DNS resource record.  The reader is warned that reading   one of the documents in this series without reading the others will   probably lead to misunderstandings and interoperability problems.2. Introduction   The Dynamic Delegation Discovery System is used to implement lazy   binding of strings to data, in order to support dynamically   configured delegation systems.  The DDDS functions by mapping some   unique string to data stored within a DDDS Database by iteratively   applying string transformation rules until a terminal condition is   reached.  This document defines the entire DDDS by listing the   documents that make up the complete specification at this time.Mealling                     Informational                      [Page 1]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002   This document along withRFC 3402,RFC 3403 andRFC 3404 obsoletesRFC 2168 [8] andRFC 2915 [6], as well as updatesRFC 2276 [5].  This   document will be updated and or obsoleted when changes are made to   the DDDS specifications.  Thus the reader is strongly encouraged to   check the IETF RFC repository for any documents that obsoletes or   updates this one.3. The Algorithm   The DDDS algorithm is defined byRFC 3402 [1].  That document defines   the following DDDS concepts:   o  The basic DDDS vocabulary.   o  The algorithm.   o  The requirements on applications using the algorithm.   o  The requirements on databases that store DDDS rules.RFC 3402 is the actual DDDS Algorithm specification.  But the   specification by itself is useless without some additional document   that defines how and why the algorithm is used.  These documents are   called Applications and do not actually make up part of the DDDS core   specification.  Applications require databases in which to store   their Rules.  These databases are called DDDS Databases and are   usually specified in separate documents.  But again, these Database   specifications are not included in the DDDS core specification   itself.4. DDDS Applications   No implementation can begin without an Application specification, as   this is what provides the concrete instantiation details for the DDDS   Algorithm.  Without them the DDDS is nothing more than a general   algorithm.  Application documents define the following:   o  the Application Unique String (the thing the delegation rules act      on).   o  the First Well Known Rule (the Rule that says where the process      starts).   o  the list of valid Databases (you can't just use any Database).   o  the final expected output.Mealling                     Informational                      [Page 2]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002   Some sample Applications are documented in:   o  "E.164 number and DNS" (RFC 2916) [7].  This Application uses the      DDDS to map a telephone number to service endpoints such as SIP or      email.   o  "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform      Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].      This Application uses the DDDS to resolve any URI to a set of      endpoints or 'resolvers' that can give additional information      about the URI independent of its particular URI scheme.5. Currently Standardized Databases   Any DDDS Application must use some type of DDDS Database.  Database   documents define the following:   o  the general spec for how the Database works.   o  formats for Keys.   o  formats for Rules.   o  Key lookup process.   o  rule insertion procedures.   o  collision avoidance measures.   A Database cannot be used on its own; there must be at least one   Application that uses it.  Multiple Databases and Applications are   defined, and some Databases will support multiple Applications.   However, not every Application uses each Database, and vice versa.   Thus, compliance is defined by the combination of a Database and   Application specification.   One sample Database specification is documented in:   o  "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain      Name System (DNS) Database" (RFC 3402) [1].  (This document is the      official specification for the NAPTR DNS Resource Record.)6. Security Considerations   Any known security issues that arise from the use of algorithms and   databases must be specified in the respective specifications.  They   must be completely and fully described.  It is not required that the   database and algorithms be secure or that it be free from risks, butMealling                     Informational                      [Page 3]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002   that the known risks be identified.  Publication of a new database   type or algorithm does require a security review, and the security   considerations section should be subject to continuing evaluation.   Additional security considerations should be addressed by publishing   revised versions of the database and algorithm specifications.7. IANA Considerations   While this document itself does not create any new requirements for   the IANA, the documents in this series create many varied   requirements.  The IANA Considerations sections in those documents   should be reviewed by the IANA to determine the complete set of new   registries and requirements.  Any new algorithms, databases or   applications should take great care in what they require the IANA to   do in the future.References   [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part       Two: The Algorithm",RFC 3402, October 2002.   [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part       Three: The Doman Name System (DNS) Database",RFC 3403, October       2002.   [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part       Four: The Uniform Resource Identifiers (URI) Resolution       Application",RFC 3404, October 2002.   [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part       Five: URI.ARPA Assignment Procedures",RFC 3405, October 2002.   [5] Sollins, K., "Architectural Principles of Uniform Resource Name       Resolution",RFC 2276, January 1998.   [6] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR)       DNS Resource Record",RFC 2915, August 2000.   [7] Faltstrom, P., "E.164 number and DNS",RFC 2916, September 2000.   [8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource       Identifiers using the Domain Name System",RFC 2168, June 1997.Mealling                     Informational                      [Page 4]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002Author's Address   Michael Mealling   VeriSign   21345 Ridgetop Circle   Sterling, VA  20166   US   EMail: michael@neonym.net   URI:http://www.verisignlabs.comMealling                     Informational                      [Page 5]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002Full Copyright Statement   Copyright (C) The Internet Society (2002).  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.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Mealling                     Informational                      [Page 6]