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: [email protected]
  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]


You are viewing proxied material from gopher.rbfh.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.