summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3401.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3401.txt')
-rw-r--r--doc/rfc/rfc3401.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc3401.txt b/doc/rfc/rfc3401.txt
new file mode 100644
index 0000000..e648fd0
--- /dev/null
+++ b/doc/rfc/rfc3401.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group M. Mealling
+Request for Comments: 3401 VeriSign
+Updates: 2276 October 2002
+Obsoletes: 2915, 2168
+Category: Informational
+
+
+ Dynamic Delegation Discovery System (DDDS)
+ Part One: The Comprehensive DDDS
+
+Status 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 with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC
+ 2168 and RFC 2915, as well as updates RFC 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 with RFC 3402, RFC 3403 and RFC 3404 obsoletes
+ RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 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 by RFC 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, but
+
+
+
+Mealling 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 2002
+
+
+Author's Address
+
+ Michael Mealling
+ VeriSign
+ 21345 Ridgetop Circle
+ Sterling, VA 20166
+ US
+
+ EMail: michael@neonym.net
+ URI: http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling Informational [Page 5]
+
+RFC 3401 DDDS - The Comprehensive DDDS October 2002
+
+
+Full 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]
+