draft-ietf-urn-ddds-toc-03.txt   rfc3401.txt 
URN M. Mealling Network Working Group M. Mealling
Internet-Draft VeriSign Request for Comments: 3401 VeriSign
Expires: November 5, 2002 May 7, 2002 Updates: 2276 October 2002
Obsoletes: 2915, 2168
Category: Informational
Dynamic Delegation Discovery System (DDDS) Part One: The Dynamic Delegation Discovery System (DDDS)
Comprehensive DDDS Standard Part One: The Comprehensive DDDS
draft-ietf-urn-ddds-toc-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 5, 2002.
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
Dynamic Delegation Discovery System (DDDS) standard. The DDDS is an Dynamic Delegation Discovery System (DDDS). DDDS is an abstract
abstract algorithm for applying dynamically retrieved string algorithm for applying dynamically retrieved string transformation
transformation rules to an application-unique string. rules to an application-unique string.
This document along with RFC XXXX, RFC YYYY and RFC ZZZZ obsolete RFC This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC
2168 [8] and RFC 2915 [6] as well as update RFC 2276 [5]. 2168 and RFC 2915, as well as updates RFC 2276.
1. Intended Audience 1. Intended Audience
This document and the documents that it references are intended for This document and the documents that it references are intended for
anyone attempting to implement or understand the generic DDDS anyone attempting to implement or understand the generic DDDS
algorithm, URI Resolution, ENUM telephone number to URI resolution, algorithm, URI Resolution, ENUM telephone number to URI resolution,
and the NAPTR DNS resource record. The reader is warned that reading and the NAPTR DNS resource record. The reader is warned that reading
one of the documents in this series without reading the others will one of the documents in this series without reading the others will
probably lead to misunderstandings and interoperability problems. probably lead to misunderstandings and interoperability problems.
2. Introduction 2. Introduction
The Dynamic Delegation Discovery System is used to implement lazy The Dynamic Delegation Discovery System is used to implement lazy
binding of strings to data, in order to support dynamically binding of strings to data, in order to support dynamically
configured delegation systems. The DDDS functions by mapping some configured delegation systems. The DDDS functions by mapping some
unique string to data stored within a DDDS Database by iteratively unique string to data stored within a DDDS Database by iteratively
applying string transformation rules until a terminal condition is applying string transformation rules until a terminal condition is
reached. This document defines the entire DDDS standard by listing reached. This document defines the entire DDDS by listing the
the 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 XXXX, RFC YYYY and RFC ZZZZ obsolete RFC This document along with RFC 3402, RFC 3403 and RFC 3404 obsoletes
2168 [8] and RFC 2915 [6] as well as update RFC 2276 [5]. This 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 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
check the IETF RFC repository for any documents that obsolete or check the IETF RFC repository for any documents that obsoletes or
update this one. updates this one.
3. The Algorithm 3. The Algorithm
The DDDS algorithm is defined by RFC XXXX [1]. That document defines The DDDS algorithm is defined by RFC 3402 [1]. That document defines
the following DDDS concepts: the following DDDS concepts:
o The basic DDDS vocabulary o The basic DDDS vocabulary.
o The algorithm o The algorithm.
o The requirements on applications using the algorithm o The requirements on applications using the algorithm.
o The requirements on databases that store DDDS rules o The requirements on databases that store DDDS rules.
RFC XXXX is the actual DDDS algorithm Specification. But the 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
called Applications and do not actually make up part of the DDDS core called Applications and do not actually make up part of the DDDS core
specification. Applications require databases in which to store specification. Applications require databases in which to store
their Rules. These databases are called DDDS Databases and are their Rules. These databases are called DDDS Databases and are
usually specified in separate documents. But again, these Database usually specified in separate documents. But again, these Database
specifications are not included in the DDDS core specification specifications are not included in the DDDS core specification
itself. itself.
4. DDDS Applications 4. DDDS Applications
No implementation can begin without an Application specification, as No implementation can begin without an Application specification, as
this is what provides the concrete instantiation details for the DDDS this is what provides the concrete instantiation details for the DDDS
Algorithm. Without them the DDDS is nothing more than a general Algorithm. Without them the DDDS is nothing more than a general
algorithm. Application documents define the following: algorithm. Application documents define the following:
o the Application Unique String (the thing the delegation rules act o the Application Unique String (the thing the delegation rules act
on) on).
o the First Well Known Rule (the Rule that says where the process o the First Well Known Rule (the Rule that says where the process
starts) starts).
o the list of valid Databases (you can't just use any Database) o the list of valid Databases (you can't just use any Database).
o the final expected output o the final expected output.
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" (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 URI o "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
Resolution Application" (RFC YYYY) [3]. This Application uses the Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].
DDDS to resolve any URI to a set of endpoints or 'resolvers' that This Application uses the DDDS to resolve any URI to a set of
can give additional information about the URI independent of its endpoints or 'resolvers' that can give additional information
particular URI scheme. about the URI independent of its particular URI scheme.
5. Currently Standardized Databases 5. Currently Standardized Databases
Any DDDS Application must use some type of DDDS Database. Database Any DDDS Application must use some type of DDDS Database. Database
documents define the following: documents define the following:
o the general spec for how the Database works o the general spec for how the Database works.
o formats for Keys o formats for Keys.
o formats for Rules o formats for Rules.
o Key lookup process o Key lookup process.
o rule insertion procedures o rule insertion procedures.
o collision avoidance measures o collision avoidance measures.
A Database cannot be used on its own; there must be at least one A Database cannot be used on its own; there must be at least one
Application that uses it. Multiple Databases and Applications are Application that uses it. Multiple Databases and Applications are
defined, and some Databases will support multiple Applications. defined, and some Databases will support multiple Applications.
However, not every Application uses each Database, and vice versa. However, not every Application uses each Database, and vice versa.
Thus, compliance is defined by the combination of a Database and Thus, compliance is defined by the combination of a Database and
Application specification. Application specification.
One sample Database specification is documented in: One sample Database specification is documented in:
o "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS o "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain
Database" (RFC XXXX) [1] (This document is the official Name System (DNS) Database" (RFC 3402) [1]. (This document is the
specification for the NAPTR DNS Resource Record) official specification for the NAPTR DNS Resource Record.)
6. Security Considerations 6. Security Considerations
Any known security issues that arise from the use of algorithms and Any known security issues that arise from the use of algorithms and
databases must be specified in the respective specifications. They databases must be specified in the respective specifications. They
must be completely and fully described. It is not required that the 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 database and algorithms be secure or that it be free from risks, but
that the known risks be identified. Publication of a new database that the known risks be identified. Publication of a new database
type or algorithm does require a security review, and the security type or algorithm does require a security review, and the security
considerations section should be subject to continuing evaluation. considerations section should be subject to continuing evaluation.
skipping to change at page 9, line 8 skipping to change at page 4, line 23
the IANA, the documents in this series create many varied the IANA, the documents in this series create many varied
requirements. The IANA Considerations sections in those documents requirements. The IANA Considerations sections in those documents
should be reviewed by the IANA to determine the complete set of new should be reviewed by the IANA to determine the complete set of new
registries and requirements. Any new algorithms, databases or registries and requirements. Any new algorithms, databases or
applications should take great care in what they require the IANA to applications should take great care in what they require the IANA to
do in the future. do in the future.
References References
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-07.txt (work Two: The Algorithm", RFC 3402, October 2002.
in progress), May 2002.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- Three: The Doman Name System (DNS) Database", RFC 3403, October
database-09.txt (work in progress), May 2002. 2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The URI Resolution Application", RFC YYYY, draft-ietf-urn- Four: The Uniform Resource Identifiers (URI) Resolution
uri-res-ddds-06.txt (work in progress), February 2002. Application", 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 VVVV, draft-ietf-urn- Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
net-procedures-10.txt (work in progress), February 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", RFC 2276, January 1998.
[6] Mealling, M. and R. Daniel, "The Naming Authority Pointer [6] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR)
(NAPTR) DNS Resource Record", RFC 2915, August 2000. DNS Resource Record", RFC 2915, August 2000.
[7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. [7] Faltstrom, P., "E.164 number and DNS", 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", RFC 2168, June 1997.
Author's Address Author's Address
Michael Mealling Michael Mealling
VeriSign VeriSign
 End of changes. 31 change blocks. 
71 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/