doc: Add RFC documents

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]
+