Difference between revisions of "RFC3401"

From RFC-Wiki
 
Line 8: Line 8:
 
                 Part One: The Comprehensive DDDS
 
                 Part One: The Comprehensive DDDS
  
Status of this Memo
+
'''Status of this Memo'''
  
 
This memo provides information for the Internet community.  It does
 
This memo provides information for the Internet community.  It does
Line 14: Line 14:
 
memo is unlimited.
 
memo is unlimited.
  
Copyright Notice
+
'''Copyright Notice'''
  
 
Copyright (C) The Internet Society (2002).  All Rights Reserved.
 
Copyright (C) The Internet Society (2002).  All Rights Reserved.
  
Abstract
+
'''Abstract'''
  
 
This document specifies the exact documents that make up the complete
 
This document specifies the exact documents that make up the complete
Line 25: Line 25:
 
rules to an application-unique string.
 
rules to an application-unique string.
  
This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC
+
This document along with [[RFC3402|RFC 3402]], [[RFC3403|RFC 3403]] and [[RFC3404|RFC 3404]] obsolete RFC
2168 and RFC 2915, as well as updates RFC 2276.
+
2168 and [[RFC2915|RFC 2915]], as well as updates [[RFC2276|RFC 2276]].
  
 
== Intended Audience ==
 
== Intended Audience ==
Line 47: Line 47:
 
documents that make up the complete specification at this time.
 
documents that make up the complete specification at this time.
  
This document along with RFC 3402, RFC 3403 and RFC 3404 obsoletes
+
This document along with [[RFC3402|RFC 3402]], [[RFC3403|RFC 3403]] and [[RFC3404|RFC 3404]] obsoletes
RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 2276 [5].  This
+
[[RFC2168|RFC 2168]] [8] and [[RFC2915|RFC 2915]] [6], as well as updates [[RFC2276|RFC 2276]] [5].  This
 
document will be updated and or obsoleted when changes are made to
 
document will be updated and or obsoleted when changes are made to
 
the DDDS specifications.  Thus the reader is strongly encouraged to
 
the DDDS specifications.  Thus the reader is strongly encouraged to
Line 56: Line 56:
 
== The Algorithm ==
 
== The Algorithm ==
  
The DDDS algorithm is defined by RFC 3402 [1].  That document defines
+
The DDDS algorithm is defined by [[RFC3402|RFC 3402]] [1].  That document defines
 
the following DDDS concepts:
 
the following DDDS concepts:
  
Line 67: Line 67:
 
o  The requirements on databases that store DDDS rules.
 
o  The requirements on databases that store DDDS rules.
  
RFC 3402 is the actual DDDS Algorithm specification.  But the
+
[[RFC3402|RFC 3402]] is the actual DDDS Algorithm specification.  But the
 
specification by itself is useless without some additional document
 
specification by itself is useless without some additional document
 
that defines how and why the algorithm is used.  These documents are
 
that defines how and why the algorithm is used.  These documents are
Line 96: Line 96:
 
Some sample Applications are documented in:
 
Some sample Applications are documented in:
  
o  "E.164 number and DNS" (RFC 2916) [7].  This Application uses the
+
o  "E.164 number and DNS" ([[RFC2916|RFC 2916]]) [7].  This Application uses the
 
   DDDS to map a telephone number to service endpoints such as SIP or
 
   DDDS to map a telephone number to service endpoints such as SIP or
 
   email.
 
   email.
  
 
o  "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
 
o  "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
   Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].
+
   Resource Identifiers (URI) Resolution Application" ([[RFC3404|RFC 3404]]) [3].
 
   This Application uses the DDDS to resolve any URI to a set of
 
   This Application uses the DDDS to resolve any URI to a set of
 
   endpoints or 'resolvers' that can give additional information
 
   endpoints or 'resolvers' that can give additional information
Line 133: Line 133:
  
 
o  "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain
 
o  "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain
   Name System (DNS) Database" (RFC 3402) [1].  (This document is the
+
   Name System (DNS) Database" ([[RFC3402|RFC 3402]]) [1].  (This document is the
 
   official specification for the NAPTR DNS Resource Record.)
 
   official specification for the NAPTR DNS Resource Record.)
  
Line 162: Line 162:
  
 
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
 
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
     Two: The Algorithm", RFC 3402, October 2002.
+
     Two: The Algorithm", [[RFC3402|RFC 3402]], October 2002.
  
 
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
 
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
     Three: The Doman Name System (DNS) Database", RFC 3403, October
+
     Three: The Doman Name System (DNS) Database", [[RFC3403|RFC 3403]], October
 
     2002.
 
     2002.
  
 
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
 
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
 
     Four: The Uniform Resource Identifiers (URI) Resolution
 
     Four: The Uniform Resource Identifiers (URI) Resolution
     Application", RFC 3404, October 2002.
+
     Application", [[RFC3404|RFC 3404]], October 2002.
  
 
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
 
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
     Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
+
     Five: URI.ARPA Assignment Procedures", [[RFC3405|RFC 3405]], October 2002.
  
 
[5] Sollins, K., "Architectural Principles of Uniform Resource Name
 
[5] Sollins, K., "Architectural Principles of Uniform Resource Name
     Resolution", RFC 2276, January 1998.
+
     Resolution", [[RFC2276|RFC 2276]], January 1998.
  
 
[6] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR)
 
[6] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR)
     DNS Resource Record", RFC 2915, August 2000.
+
     DNS Resource Record", [[RFC2915|RFC 2915]], August 2000.
  
[7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
+
[7] Faltstrom, P., "E.164 number and DNS", [[RFC2916|RFC 2916]], September 2000.
  
 
[8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
 
[8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
     Identifiers using the Domain Name System", RFC 2168, June 1997.
+
     Identifiers using the Domain Name System", [[RFC2168|RFC 2168]], June 1997.
  
 
Author's Address
 
Author's Address
Line 229: Line 229:
 
Funding for the RFC Editor function is currently provided by the
 
Funding for the RFC Editor function is currently provided by the
 
Internet Society.
 
Internet Society.
 +
 +
[[Category:Informational]]

Latest revision as of 01:25, 4 October 2020

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.

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.

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.

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.

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.

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.

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.

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.)

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

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.

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.

Author's Address

Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US

EMail: [email protected] URI: http://www.verisignlabs.com

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.