draft-ietf-urn-ddds-02.txt   draft-ietf-urn-ddds-03.txt 
Network Working Group M.M. Mealling Network Working Group M. Mealling
Internet-Draft Network Solutions, Inc. Internet-Draft Network Solutions, Inc.
Expires: March 22, 2001 September 21, 2000 Expires: May 2, 2001 November 1, 2000
Dynamic Delegation Discovery System (DDDS) Dynamic Delegation Discovery System (DDDS)
draft-ietf-urn-ddds-02 draft-ietf-urn-ddds-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at To view the entire list of Internet-Draft Shadow Directories, see
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. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 22, 2001. This Internet-Draft will expire on May 2, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
This document describes a the Dynamic Delegation Discovery System or This document describes the Dynamic Delegation Discovery System
DDDS which, when applied to a unique string will produce a series of (DDDS). The DDDS defines an abstract algorithm for applying
rules that describe the various delegations that may exist based on dynamically retrieved string transformation rules to an
the syntax of that string. Since the DDDS is an abstract algorithm, application-unique string. Well-formed transformation rules will
this specification does not define either an application or a rule reflect the delegation of management of information associated with
database. the string. This memo does not specify any application or database,
although it does define the requirements for doing so.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 5 3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 5
3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 5 3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 5
3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 7 3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 7
4. Specifying An Application . . . . . . . . . . . . . . . . . . 9 4. Specifying An Application . . . . . . . . . . . . . . . . . . 9
5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 11 5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 11
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 An Automobile Parts Identification System . . . . . . . . . . 12 6.1 An Automobile Parts Identification System . . . . . . . . . . 13
6.2 A Document Identification Service . . . . . . . . . . . . . . 13 6.2 A Document Identification Service . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Dynamic Delegation Discovery System is used to map some unique The Dynamic Delegation Discovery System is used to map some unique
string to data stored within the DDDS by iteratively applying string string to data stored within the DDDS by iteratively applying string
transformation rules until a terminal condition is reached. This transformation rules until a terminal condition is reached. This
document describes the general algorithm, not any particular document describes the general algorithm, not any particular
application or usage scenario. It is up to other documents to application or usage scenario. It is up to other documents to
describe how they use the DDDS algorithms. describe how they use the DDDS algorithms. Two such documents are
RFXXXX[5] which describes the URI Resolution Application and
RFC2916[7] which describes the E.164 Telephone Number to URI Mapping
Application.
The DDDS's history is an evolution from work done by the Uniform The DDDS's history is an evolution from work done by the Uniform
Resource Name Working Group. When Uniform Resource Names[1] were Resource Name Working Group. When Uniform Resource Names[1] were
originally formulated there was the desire to locate an originally formulated there was the desire to locate an
authoritative server for a URN which by design contained no authoritative server for a URN which by design contained no
information about network locations. A system was formulated that information about network locations. A system was formulated that
could use a database of rules that could be applied to a URN to find could use a database of rules that could be applied to a URN to find
out information about specific chunks of syntax. This system was out information about specific chunks of syntax. This system was
originally called the Resolver Discovery System[2] and only applied originally called the Resolver Discovery System[2] and only applied
to URNs. to URNs.
Over time other systems began to apply this same algorithm and Over time other systems began to apply this same algorithm and
infrastructure to other, non-URN related, systems. This caused some infrastructure to other, non-URN related, systems. This caused some
of the underlying assumptions to change and need clarification. This of the underlying assumptions to change and need clarification. This
document, which is one of a series, is an update of those original document, which is one of a series, is an update of those original
URN specifications in order to allow new applications and rule URN specifications in order to allow new applications and rule
databases to be developed in a standardized manner. databases to be developed in a standardized manner.
A direct result of these clarifications and generalizations is that A direct result of these clarifications and generalizations is that
this document, along with [4] and [5], obsoletes RFC 2168[6] and this document, along with RFC YYYY[4] and RFC XXXX[5], obsoletes RFC
updates RFC 2276[2]. 2168[8] and RFC 2915[6] as well as updates RFC 2276[2].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
Application Unique String Application Unique String
A string that is the target of the rewrite rules. Each possible The string that is the target of all the rewrite rules. By the
value of the string must be unique within the space for which it nature of the DDDS algorithm, each string defines a unique
is valid in order for the rewrite rules to apply. delegation path; therefore strings must be chosen to reflect the
one-to-one relationship between whatever is being delegated and
the string (uniqueness).
Rewrite Rule Rewrite Rule
An object containing several pieces of data that, when combined An object containing several pieces of data that, when combined
and applied to an Application Unique String, produces a new key and applied to an Application Unique String, produces a new key
that exists in the Rule Database. Also simply known as a Rule. that exists in the Rule Database. Also simply known as a Rule.
First Well Known Rule First Well Known Rule
This is a rewrite rule that is defined by the application and not This is a rewrite rule that is defined by the application and not
actually in the Rule Database. It is used to produce the first actually in the Rule Database. It is used to produce the first
valid key. valid key.
skipping to change at page 5, line 43 skipping to change at page 5, line 43
delegation branch. For example, two rules may equally apply to a delegation branch. For example, two rules may equally apply to a
specific delegation decision for a string. One rule can lead to a specific delegation decision for a string. One rule can lead to a
terminal rule that produces information for use in high terminal rule that produces information for use in high
availability environments while another may lead to an archival availability environments while another may lead to an archival
service that may be slower but is more stable over long periods service that may be slower but is more stable over long periods
of time. of time.
A Substitution Expression A Substitution Expression
This is the actual string modification part of the rule. It is a This is the actual string modification part of the rule. It is a
combination of a POSIX Extended Regular Expression[3] and a combination of a POSIX Extended Regular Expression[3] and a
replacement string similar to SED search-replace function. See replacement string similar to Unix sed(1) search-replace
Section 3.2. function. See Section 3.2.
3.2 Substitution Expression Syntax 3.2 Substitution Expression Syntax
The syntax of the Substitution Expression part of the rule is a The syntax of the Substitution Expression part of the rule is a
sed-style substitution expression. True sed(1) substitution sed-style substitution expression. True sed(1) substitution
expressions are not appropriate for use in this application for a expressions are not appropriate for use in this application for a
variety of reasons, therefore the contents of the regexp field MUST variety of reasons, therefore the contents of the regexp field MUST
follow this grammar: follow this grammar:
subst-expr = delim-char ere delim-char repl delim-char *flags subst-expr = delim-char ere delim-char repl delim-char *flags
skipping to change at page 6, line 44 skipping to change at page 6, line 44
has backref expressions: has backref expressions:
\1 = ABCDEFG \1 = ABCDEFG
\2 = BCDE \2 = BCDE
\3 = C \3 = C
\4 = F \4 = F
\5..\9 = error - no matching subexpression \5..\9 = error - no matching subexpression
The "i" flag indicates that the ERE matching SHALL be performed in a The "i" flag indicates that the ERE matching SHALL be performed in a
case-insensitive fashion. Furthermore, any backref replacements MAY case-insensitive fashion. Furthermore, any backref replacements MAY
be normalized to lower case when the "i" flag is given. be normalized to lower case when the "i" flag is given. This flag
only has meaning when both the Application and Database define a
character set where case insensitivity is valid.
The first character in the substitution expression shall be used as The first character in the substitution expression shall be used as
the character that delimits the components of the substitution the character that delimits the components of the substitution
expression. There must be exactly three non-escaped occurrences of expression. There must be exactly three non-escaped occurrences of
the delimiter character in a substitution expression. Since escaped the delimiter character in a substitution expression. Since escaped
occurrences of the delimiter character will be interpreted as occurrences of the delimiter character will be interpreted as
occurrences of that character, digits MUST NOT be used as occurrences of that character, digits MUST NOT be used as
delimiters. Backrefs would be confused with literal digits were this delimiters. Backrefs would be confused with literal digits were this
allowed. Similarly, if flags are specified in the substitution allowed. Similarly, if flags are specified in the substitution
expression, the delimiter character must not also be a flag expression, the delimiter character must not also be a flag
character. character.
The character set(s) that the substitution expression is in and can The character set(s) that the substitution expression is in and can
act on are dependent both on the Application and on the Database act on are dependent both on the Application and on the Database
beind used. An Application must define what the allowed character being used. An Application must define what the allowed character
sets are for the Application Unique String. A DDDS Database sets are for the Application Unique String. A DDDS Database
specification must define what character sets are required for specification must define what character sets are required for
producing its keys and for how the substitution expression itself is producing its keys and for how the substitution expression itself is
encoded. The grammar required characters from above only have encoded. The grammar required characters from above only have
meaning once a specific character set is defined for the Database or meaning once a specific character set is defined for the Database or
Application. Application.
3.3 The Complete Algorithm 3.3 The Complete Algorithm
The following is the exact DDDS algorithm: The following is the exact DDDS algorithm:
skipping to change at page 9, line 13 skipping to change at page 9, line 13
along with the output of the last Substitution Expression. along with the output of the last Substitution Expression.
4. Specifying An Application 4. Specifying An Application
In order for this algorithm to have any usefulness, a specification In order for this algorithm to have any usefulness, a specification
must be written describing an application and one or more databases. must be written describing an application and one or more databases.
In order to specify an application the following pieces of In order to specify an application the following pieces of
information are required: information are required:
Application Unique String: Application Unique String:
This is the original string that the rewrite rules will apply to. This is the only string that the rewrite rules will apply to. The
The string must have some regular structure and be unique within string must have some regular structure and be unique within the
the application such that anyone applying Rules taken from the application such that anyone applying Rules taken from the same
same Database will end up with the same Keys. For example, the Database will end up with the same Keys. For example, the URI
URI Resolution application would define the Application Unique Resolution application defines the Application Unique String to
String to be a URI. be a URI.
No application is allowed to define an Application Unique String No application is allowed to define an Application Unique String
such that the Key obtained by a rewrite rule is treated as the such that the Key obtained by a rewrite rule is treated as the
Application Unique String for input to a new rule. This leads to Application Unique String for input to a new rule. This leads to
sendmail style rewrite rules which are fragile and error prone. sendmail style rewrite rules which are fragile and error prone.
The one single exception to this is when an Application defines
some flag or state where the rules for that application are
suspended and a new DDDS Application or some other arbitrary set
of rules take over. If this is the case then, by definition, none
of these rules apply. One such case can be found in the URI
Resolution application which defines the 'p' flag which states
that the next step is 'protocol specific' and thus outside of the
scope of DDDS.
First Well Known Rule: First Well Known Rule:
This is the first rule that, when applied to the Application This is the first rule that, when applied to the Application
Unique String, produces the first valid Key. It can be expressed Unique String, produces the first valid Key. It can be expressed
in the same form as a Rule or it can be something more complex. in the same form as a Rule or it can be something more complex.
For example, the URI Resolution application might specify that For example, the URI Resolution application might specify that
the rule is that the sequence of characters in the URI up to but the rule is that the sequence of characters in the URI up to but
not including the first colon (the URI scheme) is the first Key. not including the first colon (the URI scheme) is the first Key.
Valid Databases: Valid Databases:
The application can define which Databases are valid. For each The application can define which Databases are valid. For each
Database the Application must define how the First Well Known Database the Application must define how the First Well Known
Rule's output (the first Key) is turned into something that is Rule's output (the first Key) is turned into something that is
valid for that Database. For example, the URI Resolution valid for that Database. For example, the URI Resolution
application could use the Domain Name System (DNS) as a Database. application could use the Domain Name System (DNS) as a Database.
The operation for turning this first Key into something that was The operation for turning this first Key into something that was
valid for the database would be to to turn it into some DNS-valid valid for the database would be to to turn it into some DNS-valid
domain-name. Additionally, for each Database an Application domain-name. Additionally, for each Database an Application
defines, it must also specify what the valid character sets are defines, it must also specify what the valid character sets are
that will produce the correct Keys. In the URI Resolution that will produce the correct Keys. In the URI Resolution example
example, the character set of a URI is 7 bit ASCII which matches shown here, the character set of a URI is 7 bit ASCII which
fairly well with DNS's 8 bit limitation on characters in its zone matches fairly well with DNS's 8 bit limitation on characters in
files. its zone files.
Expected Output: Expected Output:
The Application must define what the expected output of the The Application must define what the expected output of the
Terminal Rule should be. For example, the URI Resolution Terminal Rule should be. For example, the URI Resolution
application is concerned with finding servers that contain application is concerned with finding servers that contain
authoritative data about a given URI. Thus the output of the authoritative data about a given URI. Thus the output of the
terminal rule would be information (hosts, ports, protocols, etc) terminal rule would be information (hosts, ports, protocols, etc)
that would be used to contact that authoritative server. that would be used to contact that authoritative server.
5. Specifying A Database 5. Specifying A Database
Additionally, any Application must have at least one corresponding Additionally, any Application must have at least one corresponding
Database from which to retrieve the Rules. A Database specification Database from which to retrieve the Rules. It is important to note
must include the following pieces of information: that a given Database may be used by more than one Application. If
this is the case, each rule must be use some combination of its
Services and/or substitution expression to match only those
Application Unique Strings for which it is valid.
A Database specification must include the following pieces of
information:
General Specification: General Specification:
The Database must have a general specification. This can The Database must have a general specification. This can
reference other standards (SQL, DNS, etc) or it can fully specify reference other standards (SQL, DNS, etc) or it can fully specify
a novel database system. This specification must be clear as to a novel database system. This specification must be clear as to
what allowed character sets exist in order to know in which what allowed character sets exist in order to know in which
character set the Rules and subsequence substitution expression character set the Rules and subsequence substitution expression
are encoded in. are encoded.
Lookup Procedure: Lookup Procedure:
This specifies how a query is formulated and submitted to the This specifies how a query is formulated and submitted to the
database. In the case of databases that are used for other database. In the case of databases that are used for other
purposes (such as DNS), the specification must be clear as to how purposes (such as DNS), the specification must be clear as to how
a query is formulated specifically for the database to be a DDDS a query is formulated specifically for the database to be a DDDS
database. For example, a DNS based Database must specify which database. For example, a DNS based Database must specify which
Resource Records or Query Types are used. Resource Records or Query Types are used.
Key Format: Key Format:
skipping to change at page 12, line 5 skipping to change at page 11, line 47
Keys must be constructed as valid domain-names. Keys must be constructed as valid domain-names.
Rule Format: Rule Format:
The specification for the output format of a rule. The specification for the output format of a rule.
Rule Insertion Procedure: Rule Insertion Procedure:
A specification for how a Rule is inserted into the database. A specification for how a Rule is inserted into the database.
This can include policy statements about whether or not a Rule is This can include policy statements about whether or not a Rule is
allowed to be added. allowed to be added.
Rule Collision Avoidance:
Since a Database may be used by multiple Applications (ENUM and
URI Resolution for example), the specification must be clear
about collisions will be avoided. There are usually two methods
for handling this: 1) disallow one key from being valid in two
different Applications; 2) if 1 isn't possible then write the
substitution expression such that the regular expression part
contains enough of the Application Unique String as part of its
match to differentiate between the two Applications.
6. Examples 6. Examples
The examples given here are for pedagogical purposes only. They are The examples given here are for pedagogical purposes only. They are
specifically taken from fictious applications that have not been specifically taken from fictious applications that have not been
specified in any published document. specified in any published document.
6.1 An Automobile Parts Identification System 6.1 An Automobile Parts Identification System
In this example imagine a system setup where by all automobile In this example imagine a system setup where by all automobile
manufacturers come together and create a standardized part numbering manufacturers come together and create a standardized part numbering
skipping to change at page 13, line 22 skipping to change at page 14, line 22
get a manufacturer ID you must be a member of the Auto Parts get a manufacturer ID you must be a member of the Auto Parts
Manufacturers Association Manufacturers Association
In order to illustrate how the system would work, imagine the part In order to illustrate how the system would work, imagine the part
number "4747301AB7D". The system would take the first 5 digits, number "4747301AB7D". The system would take the first 5 digits,
'47473' and ask the network for that Rewrite Rule. This Rule would '47473' and ask the network for that Rewrite Rule. This Rule would
be provided by the parts manufacturers database and would allow the be provided by the parts manufacturers database and would allow the
manufacturer to either further sub-delegate the space or point the manufacturer to either further sub-delegate the space or point the
querier directly at the EDIFAC information in the system. querier directly at the EDIFAC information in the system.
In this example lets suppose that the manufacturer returns a Rule In this example let's suppose that the manufacturer returns a Rule
that states that the next 3 digits should be used as part of a query that states that the next 3 digits should be used as part of a query
to their service in order to find a new Rule. This new Rule would to their service in order to find a new Rule. This new Rule would
allow the parts manufacturer to further delegate the query to their allow the parts manufacturer to further delegate the query to their
parts factories for each auto line. In our example part number the parts factories for each auto line. In our example part number the
number '01A' denotes the Toyota line of cars. The Rule that the number '01A' denotes the Toyota line of cars. The Rule that the
manufacturer returns further delegates the query to a supply house manufacturer returns further delegates the query to a supply house
in Japan. This rule also denotes that this Rule is terminal and thus in Japan. This rule also denotes that this Rule is terminal and thus
the result of this last query will be the actual information about the result of this last query will be the actual information about
the part. the part.
skipping to change at page 13, line 47 skipping to change at page 14, line 47
example. The difference here is that the information about the example. The difference here is that the information about the
document is kept very close to the author (usually on their document is kept very close to the author (usually on their
desktop). Thus there is the probability that the number of desktop). Thus there is the probability that the number of
delegations can be very deep. Also, in order to keep from having a delegations can be very deep. Also, in order to keep from having a
large flat space of authors, the authors are organized by large flat space of authors, the authors are organized by
organizations and departments. organizations and departments.
Let's suppose that the Application Unique String in this example Let's suppose that the Application Unique String in this example
looks like the following: looks like the following:
<organization>-<department>-<author>:<project>-<bookcase>-<book>
The Application specification would look like this: The Application specification would look like this:
o Application Unique String: the Document ID string given above o Application Unique String: the Document ID string given above
o First Well Known Rule: the characters up to but not including the o First Well Known Rule: the characters up to but not including the
first '-' is treated as the first Key. first '-' is treated as the first Key.
o Valid Databases: the DIS LDAP Directory o Valid Databases: the DIS LDAP Directory
o Expected Output: a record from an LDAP server containing o Expected Output: a record from an LDAP server containing
bibliographic information about the document in XML bibliographic information about the document in XML
The Database specification for the DIS LDAP Directory would look The Database specification for the DIS LDAP Directory would look
like this: like this:
skipping to change at page 15, line 17 skipping to change at page 16, line 17
[1] Moats, R., "URN Syntax", RFC 2141, May 1997. [1] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Sollins, K., "Architectural Principles of Uniform Resource Name [2] Sollins, K., "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998. Resolution", RFC 2276, January 1998.
[3] The Institute of Electrical and Electronics Engineers, "IEEE [3] The Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information Technology - Portable Operating System Standard for Information Technology - Portable Operating System
Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE
Std 1003.2-1992, ISBN 1-55937-255-9, January 1993. Std 1003.2-1992, ISBN 1-55937-255-9, January 1993.
[4] Mealling, M.M., "A DDDS Database Using The Domain Name System", [4] Mealling, M., "A DDDS Database Using The Domain Name System",
Internet-Draft draft-ietf-urn-dns-ddds-database-00.txt, May RFC YYYY, Internet-Draft
2000. draft-ietf-urn-dns-ddds-database-00.txt, May 2000.
[5] Mealling, M.M., "URI Resolution using the Dynamic Delegation [5] Mealling, M., "URI Resolution using the Dynamic Delegation
Discovery System", Internet-Draft Discovery System", RFC XXXX, Internet-Draft
draft-ietf-urn-uri-res-ddds-00.txt, July 2000. draft-ietf-urn-uri-res-ddds-00.txt, July 2000.
[6] Danie1, R. and M. Mealling, "Resolution of Uniform Resource [6] Mealling, M. and R.D. 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. Identifiers using the Domain Name System", RFC 2168, June 1997.
Author's Address Author's Address
Michael Mealling Michael Mealling
Network Solutions, Inc. Network Solutions, Inc.
505 Huntmar Park Drive 505 Huntmar Park Drive
Herndon, VA 22070 Herndon, VA 22070
US US
 End of changes. 25 change blocks. 
51 lines changed or deleted 86 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/