draft-ietf-urn-ddds-04.txt   draft-ietf-urn-ddds-05.txt 
Network Working Group M. Mealling Network Working Group M. Mealling
Internet-Draft Verisign Internet-Draft Verisign
Expires: August 9, 2001 February 8, 2001 Expires: April 28, 2002 October 28, 2001
Dynamic Delegation Discovery System (DDDS) Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
draft-ietf-urn-ddds-04 draft-ietf-urn-ddds-05.txt
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-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference 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."
To view the entire list of Internet-Draft Shadow Directories, see 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. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 9, 2001. This Internet-Draft will expire on April 28, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document describes the Dynamic Delegation Discovery System This document describes the Dynamic Delegation Discovery System
(DDDS). The DDDS defines an abstract algorithm for applying (DDDS) algorithm for applying dynamically retrieved string
dynamically retrieved string transformation rules to an transformation rules to an application-unique string. Well-formed
application-unique string. Well-formed transformation rules will transformation rules will reflect the delegation of management of
reflect the delegation of management of information associated with information associated with the string. This document is also part
the string. Other documents specify applications and rule databases of a series that is completely specified in "Dynamic Delegation
with which this algorithm may be used. Discovery System (DDDS) Part One: The Comprehensive DDDS Standard"
(RFC WWWW). It is very important to note that it is impossible to
read and understand any document in this series without reading the
others.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 6 3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 7 3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 7
3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 8 3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 8
3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 9 3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 10
4. Specifying An Application . . . . . . . . . . . . . . . . . . 11 4. Specifying An Application . . . . . . . . . . . . . . . . . . 11
5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 13 5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 13
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1 An Automobile Parts Identification System . . . . . . . . . . 15 6.1 An Automobile Parts Identification System . . . . . . . . . . 15
6.2 A Document Identification Service . . . . . . . . . . . . . . 16 6.2 A Document Identification Service . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The Dynamic Delegation Discovery System is used to map some unique The Dynamic Delegation Discovery System is used to implement lazy
string to data stored within the DDDS by iteratively applying string binding of strings to data, in order to support dynamically
transformation rules until a terminal condition is reached. This configured delegation systems. The DDDS functions by mapping some
document describes the general algorithm, not any particular unique string to data stored within a DDDS Database by iteratively
application or usage scenario. It is up to other documents to applying string transformation rules until a terminal condition is
describe how they use the DDDS algorithms. Two such documents are reached.
RFXXXX[5] which describes the URI Resolution Application and
RFC2916[7] which describes the E.164 Telephone Number to URI Mapping This document describes the general DDDS algorithm, not any
Application. particular application or usage scenario. The entire series of
documents is specified in "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS Standard" (RFC WWWW) [1]. It is
very important to note that it is impossible to read and understand a
single document in that series without reading the related documents.
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 [6] were
originally formulated there was the desire to locate an originally formulated there was the desire to locate an authoritative
authoritative server for a URN that (by design) contained no server for a URN that (by design) contained no information about
information about network locations. A system was formulated that network locations. A system was formulated that could use a database
could use a database of rules that could be applied to a URN to find of rules that could be applied to a URN to find out information about
out information about specific chunks of syntax. This system was specific chunks of syntax. This system was originally called the
originally called the Resolver Discovery System[2] and only applied Resolver Discovery System [7] 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 (see Section 6 for infrastructure to other, non-URN related, systems (see Section 6 for
examples of other ways of using the DDDS). This caused some of the examples of other ways of using the DDDS). This caused some of the
underlying assumptions to change and need clarification. This underlying assumptions to change and need clarification. These
document, which is one of a series, is an update of those original document are an update of those original URN specifications in order
URN specifications in order to allow new applications and rule to allow new applications and rule databases to be developed in a
databases to be developed in a standardized manner. standardized manner.
This document, RFC YYYY[4] and RFC XXXX[5] comprise a suite of
specifications based on the generic DDDS algorithm:
o This document describes the generic algorithm, assuming access to
a seperately defined database of transformation rules and a
specification of the actual application that makes use of the
algorithm.
o RFC YYYY describes a rule database that uses the DNS as its data
store.
o RFC XXXX describes how to use the above two specifications for
pulling apart Uniform Resource Identifiers and finding
authoritative metadata servers for those URIs.
These three documents obsolete RFC 2168[8] and RFC 2915[6] as well This document obsoletes RFC 2168 [11] and RFC 2915 [9] as well as
as updates RFC 2276[2]. updates RFC 2276 [7].
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
this document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
Application Unique String Application Unique String
A string that is the initial input to a DDDS application. The A string that is the initial input to a DDDS application. The
lexical structure of this string must imply a unique delegation lexical structure of this string must imply a unique delegation
path, which is analyzed and traced by the repeated selection and path, which is analyzed and traced by the repeated selection and
application of Rewrite Rules. application of Rewrite Rules.
Rewrite Rule Rewrite Rule
A rule that is applied to an Application Unique String to produce A rule that is applied to an Application Unique String to produce
either a new key to select a new rewrite rule from the rule either a new key to select a new rewrite rule from the rule
database, or a final result string that is returned to the database, or a final result string that is returned to the calling
calling application. Also simply known as a Rule. application. 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.
Terminal Rule Terminal Rule
A Rewrite Rule that, when used, yields a string that is the final A Rewrite Rule that, when used, yields a string that is the final
result of the DDDS process, rather than another database key. result of the DDDS process, rather than another database key.
skipping to change at page 4, line 45 skipping to change at page 4, line 45
Application must define the syntax and semantics of the Application must define the syntax and semantics of the
Application Unique String, the First Well Known Rule, and one or Application Unique String, the First Well Known Rule, and one or
more Databases that are valid for the Application. more Databases that are valid for the Application.
Rule Database Rule Database
Any store of Rules such that a unique key can identify a set of Any store of Rules such that a unique key can identify a set of
Rules that specify the delegation step used when that particular Rules that specify the delegation step used when that particular
Key is used. Key is used.
Services Services
A common rule database may be used to associate different A common rule database may be used to associate different services
services with a given Application Unique String; e.g. different with a given Application Unique String; e.g. different protocol
protocol functions, different operational characteristics, functions, different operational characteristics, geographic
geographic segregation, backwards compatibility, etc. Possible segregation, backwards compatibility, etc. Possible service
service differences might be message receiving services for differences might be message receiving services for
email/fax/voicemail, load balancing over web servers, selection email/fax/voicemail, load balancing over web servers, selection of
of a nearby mirror server, cost vs performance trade-offs, etc. a nearby mirror server, cost vs performance trade-offs, etc.
These Services are included as part of a Rule to allow the These Services are included as part of a Rule to allow the
Application to make branching decisions based on the Application to make branching decisions based on the applicability
applicability of one branch or the other from a Service of one branch or the other from a Service standpoint.
standpoint.
Flags Flags
Most Applications will require a way for a Rule to signal to the Most Applications will require a way for a Rule to signal to the
Application that some Rules provide particular outcomes that Application that some Rules provide particular outcomes that
others do not; e.g. different output formats, extensibility others do not; e.g. different output formats, extensibility
mechanisms, terminal rule signaling, etc. Most Datatabases will mechanisms, terminal rule signaling, etc. Most Datatabases will
define a Flags field that an Application can use to encode define a Flags field that an Application can use to encode various
various values that express these signals. values that express these signals.
3. The Algorithm 3. The Algorithm
The DDDS algorithm is based on the concept of Rewrite Rules. These The DDDS algorithm is based on the concept of Rewrite Rules. These
rules are collected into a DDDS Rule Database, and accessed by given rules are collected into a DDDS Rule Database, and accessed by given
unique keys. A given Rule, when applied to an Application Unique unique keys. A given Rule, when applied to an Application Unique
String, transforms that String into new Key that can be used to String, transforms that String into new Key that can be used to
retrieve a new Rule from the Rule Database. This new rule is then retrieve a new Rule from the Rule Database. This new rule is then
re-applied to the original Application Unique String and the cycle re-applied to the original Application Unique String and the cycle
repeats itself until a terminating condition is reached. repeats itself until a terminating condition is reached. An
Application MUST NOT apply a Rule to the output of a previous Rule.
All Rewrite Rules for all Applications must ALWAYS apply to the exact
same Application Unique String that the algorithm started with.
It is a fundamental assumption that the Application Unique String It is a fundamental assumption that the Application Unique String has
has some kind of regular, lexical structure that the rules can be some kind of regular, lexical structure that the rules can be applied
applied to. It is an assumption of the DDDS that the lexical element to. It is an assumption of the DDDS that the lexical element used to
used to make a delegation decision is simple enough to be contained make a delegation decision is simple enough to be contained within
within the Application Unique String itself. The DDDS does not solve the Application Unique String itself. The DDDS does not solve the
the case where a delegation decision is made using knowledge case where a delegation decision is made using knowledge contained
contained outside the AUS and the Rule (time of day, financial outside the AUS and the Rule (time of day, financial transactions,
transactions, rights management, etc). rights management, etc).
Diagramatically the algorithm looks like this: Diagramatically the algorithm looks like this:
+--------- Application Unique String +--------- Application Unique String
| +-----+ | +-----+
| |input| | |input|
| +-------+ +---------+ | +-------+ +---------+
| | First Well Known Rule | | | First Well Known Rule |
| +-------+ +--------+ | +-------+ +--------+
| |output| | |output|
skipping to change at page 7, line 40 skipping to change at page 7, line 44
3.1 Components of a Rule 3.1 Components of a Rule
A Rule is made up of 4 pieces of information: A Rule is made up of 4 pieces of information:
A Priority A Priority
Simply a number used to show which of two otherwise equal rules Simply a number used to show which of two otherwise equal rules
may have precedence. This allows the database to express rules may have precedence. This allows the database to express rules
that are equivalent but weighted for load balancing reasons. that are equivalent but weighted for load balancing reasons.
A set of Flags A set of Flags
Flags are used to specify attributes of the rule that determine Flags are used to specify attributes of the rule that determine if
if this rule is the last one to be applied. The last rule is this rule is the last one to be applied. The last rule is called
called the terminal rule and its output should be the intended the terminal rule and its output should be the intended result for
result for the application. the application. Flags are unique across Applications. An
Application may specify that it is using a flag defined by yet
another Application but it must use that other Application's
definition. One Application cannot re-define a Flag used by
another Application. This may mean that a registry of Flags will
be needed in the future but at this time it is not a requirement.
A description of Services A description of Services
Services are used to specify semantic attributes of a particular Services are used to specify semantic attributes of a particular
delegation branch. There are many cases where two delegation delegation branch. There are many cases where two delegation
branches are identical except that one delegates down to a result branches are identical except that one delegates down to a result
that provides one set of features while another provides some that provides one set of features while another provides some
other set. Features may include operational issues such as load other set. Features may include operational issues such as load
balancing, geographically based traffic segregation, degraded but balancing, geographically based traffic segregation, degraded but
backwardly compatibile functions for older clients, etc. For backwardly compatibile functions for older clients, etc. For
example, two rules may equally apply to a specific delegation example, two rules may equally apply to a specific delegation
decision for a string. One rule can lead to a terminal rule that decision for a string. One rule can lead to a terminal rule that
produces information for use in high availability environments produces information for use in high availability environments
while another may lead to an archival service that may be slower while another may lead to an archival service that may be slower
but is more stable over long periods of time. but is more stable over long periods 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 [8] and a
replacement string similar to Unix sed-style substitution replacement string similar to Unix sed-style substitution
expression. expression.
3.2 Substitution Expression Syntax 3.2 Substitution Expression Syntax
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
being 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 below only have meaning encoded. The grammar-required characters below only have meaning
once a specific character set is defined for the Database and/or once a specific character set is defined for the Database and/or
Application. Application.
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-
sed-style substitution expression. True sed-style substitution style substitution expression. True sed-style 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
delim-char = "/" / "!" / <Any octet not in 'POS-DIGIT' or 'flags'> delim-char = "/" / "!" / <Any octet not in 'POS-DIGIT' or 'flags'>
; All occurances of a delim_char in a subst_expr must ; All occurances of a delim_char in a subst_expr must
; be the same character.> ; be the same character.>
ere = <POSIX Extended Regular Expression> ere = <POSIX Extended Regular Expression>
repl = *(string / backref) repl = *(string / backref)
string = *(anychar / escapeddelim) string = *(anychar / escapeddelim)
anychar = <any character other than delim-char> anychar = <any character other than delim-char>
escapeddelim = "\" delim-char escapeddelim = "\" delim-char
backref = "\" POS-DIGIT backref = "\" POS-DIGIT
flags = "i" flags = "i"
POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
The result of applying the substitution expression to the String The result of applying the substitution expression to the String MUST
MUST result in a key which obeys the rules of the Database (unless result in a key which obeys the rules of the Database (unless of
of course it is a Terminal Rule in which case the output follows the course it is a Terminal Rule in which case the output follows the
rules of the application). Since it is possible for the regular rules of the application). Since it is possible for the regular
expression to be improperly specified, such that a non-conforming expression to be improperly specified, such that a non-conforming key
key can be constructed, client software SHOULD verify that the can be constructed, client software SHOULD verify that the result is
result is a legal database key before using it. a legal database key before using it.
Backref expressions in the repl portion of the substitution Backref expressions in the repl portion of the substitution
expression are replaced by the (possibly empty) string of characters expression are replaced by the (possibly empty) string of characters
enclosed by '(' and ')' in the ERE portion of the substitution enclosed by '(' and ')' in the ERE portion of the substitution
expression. N is a single digit from 1 through 9, inclusive. It expression. N is a single digit from 1 through 9, inclusive. It
specifies the N'th backref expression, the one that begins with the specifies the N'th backref expression, the one that begins with the
N'th '(' and continues to the matching ')'. For example, the ERE N'th '(' and continues to the matching ')'. For example, the ERE
(A(B(C)DE)(F)G) (A(B(C)DE)(F)G)
skipping to change at page 9, line 36 skipping to change at page 10, line 5
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. This flag be normalized to lower case when the "i" flag is given. This flag
has meaning only when both the Application and Database define a has meaning only when both the Application and Database define a
character set where case insensitivity is valid. 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.
delimiters. Backrefs would be confused with literal digits were this Backrefs would be confused with literal digits were this allowed.
allowed. Similarly, if flags are specified in the substitution Similarly, if flags are specified in the substitution expression, the
expression, the delimiter character must not also be a flag delimiter character must not also be a flag character.
character.
3.3 The Complete Algorithm 3.3 The Complete Algorithm
The following is the exact DDDS algorithm: The following is the exact DDDS algorithm:
1. The First Well Known Rule is applied to the Application Unique 1. The First Well Known Rule is applied to the Application Unique
String which produces a Key String which produces a Key
2. The Application asks the Database for the ordered set of Rules 2. The Application asks the Database for the ordered set of Rules
that are bound to that Key (see NOTE below on order details) that are bound to that Key (see NOTE below on order details)
skipping to change at page 11, line 17 skipping to change at page 11, line 17
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 only string that the rewrite rules will apply to. The This is the only string that the rewrite rules will apply to. The
string must have some regular structure and be unique within the string must have some regular structure and be unique within the
application such that anyone applying Rules taken from the same application such that anyone applying Rules taken from the same
Database will end up with the same Keys. For example, the URI Database will end up with the same Keys. For example, the URI
Resolution application defines the Application Unique String to Resolution application defines the Application Unique String to be
be a URI. 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 The one single exception to this is when an Application defines
some flag or state where the rules for that application are some flag or state where the rules for that application are
suspended and a new DDDS Application or some other arbitrary set 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 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 of these rules apply. One such case can be found in the URI
Resolution application which defines the 'p' flag which states Resolution application which defines the 'p' flag which states
that the next step is 'protocol specific' and thus outside of the that the next step is 'protocol specific' and thus outside of the
scope of DDDS. 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
the rule is that the sequence of characters in the URI up to but rule is that the sequence of characters in the URI up to but not
not including the first colon (the URI scheme) is the first Key. 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
skipping to change at page 13, line 33 skipping to change at page 13, line 33
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:
If any operations are needed in order to turn a Key into If any operations are needed in order to turn a Key into something
something that is valid for the database then these must be that is valid for the database then these must be clearly defined.
clearly defined. For example, in the case of a DNS database, the For example, in the case of a DNS database, the Keys must be
Keys must be constructed as valid domain-names. 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: Rule Collision Avoidance:
Since a Database may be used by multiple Applications (ENUM and Since a Database may be used by multiple Applications (ENUM and
URI Resolution for example), the specification must be clear URI Resolution for example), the specification must be clear about
about how rule collisions will be avoided. There are usually two how rule collisions will be avoided. There are usually two
methods for handling this: 1) disallow one key from being valid methods for handling this: 1) disallow one key from being valid in
in two different Applications; 2) if 1 isn't possible then write two different Applications; 2) if 1 isn't possible then write the
the substitution expression such that the regular expression part substitution expression such that the regular expression part
contains enough of the Application Unique String as part of its contains enough of the Application Unique String as part of its
match to differentiate between the two Applications. 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
skipping to change at page 16, line 28 skipping to change at page 16, line 29
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 let's 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
in Japan. This rule also denotes that this Rule is terminal and thus 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.
6.2 A Document Identification Service 6.2 A Document Identification Service
This example is very similar to the last since the documents in this This example is very similar to the last since the documents in this
system can simply be thought of as the auto part in the last system can simply be thought of as the auto part in the last example.
example. The difference here is that the information about the The difference here is that the information about the document is
document is kept very close to the author (usually on their kept very close to the author (usually on their desktop). Thus there
desktop). Thus there is the probability that the number of is the probability that the number of delegations can be very deep.
delegations can be very deep. Also, in order to keep from having a Also, in order to keep from having a large flat space of authors, the
large flat space of authors, the authors are organized by 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> <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
like this: this:
o General Specification: the Database uses the LDAP directory o General Specification: the Database uses the LDAP directory
service. Each LDAP server has a record that contains the Rewrite service. Each LDAP server has a record that contains the Rewrite
Rule. Rules refer to other LDAP servers using the LDAP URL scheme. Rule. Rules refer to other LDAP servers using the LDAP URL
scheme.
o Lookup Procedure: using standard LDAP queries, the client asks o Lookup Procedure: using standard LDAP queries, the client asks the
the LDAP server for information about the Key. LDAP server for information about the Key.
o Key Format: no conversion is necessary. o Key Format: no conversion is necessary.
o Rule Format: See the LDAP Rewrite Rule specification o Rule Format: See the LDAP Rewrite Rule specification
o Rule Insertion Procedure: See the procedures published by the o Rule Insertion Procedure: See the procedures published by the
entity that has authority over that section of the DIS tree. The entity that has authority over that section of the DIS tree. The
first section, the organization, is owned by the DIS Agency. first section, the organization, is owned by the DIS Agency.
In this example, the first lookup is for the organization's Rule. At In this example, the first lookup is for the organization's Rule. At
skipping to change at page 19, line 8 skipping to change at page 19, line 8
This document simply defines the DDDS algorithm and thus, by itself, This document simply defines the DDDS algorithm and thus, by itself,
does not imply any security issues. It is when this algorithm is does not imply any security issues. It is when this algorithm is
coupled with a Database and an Application that security coupled with a Database and an Application that security
considerations can be known well enough to enumerate them beyond considerations can be known well enough to enumerate them beyond
simply saying that dynamic delegation points are a possible point of simply saying that dynamic delegation points are a possible point of
attack. attack.
8. IANA Considerations 8. IANA Considerations
This document does not create any requirements on the IANA. Database This document does not create any requirements on the IANA. Database
and Application specifications may have considerable requirements and Application specifications may have considerable requirements but
but they cannot be enumerated here. they cannot be enumerated here.
References References
[1] Moats, R., "URN Syntax", RFC 2141, May 1997. [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-
urn-ddds-toc-00.txt (work in progress), October 2001.
[2] Sollins, K., "Architectural Principles of Uniform Resource Name [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work
in progress), May 2000.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-
database-07.txt (work in progress), May 2000.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The URI Resolution Application", RFC YYYY, draft-ietf-
urn-uri-res-ddds-05.txt (work in progress), October 2000.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-
urn-net-procedures-09.txt (work in progress), October 2001.
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7] 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 [8] 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., "A DDDS Database Using The Domain Name System", [9] Mealling, M. and R. Daniel, "The Naming Authority Pointer
RFC YYYY, Internet-Draft
draft-ietf-urn-dns-ddds-database-00.txt, May 2000.
[5] Mealling, M., "URI Resolution using the Dynamic Delegation
Discovery System", RFC XXXX, Internet-Draft
draft-ietf-urn-uri-res-ddds-00.txt, July 2000.
[6] Mealling, M. and R.D. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, August 2000. (NAPTR) DNS Resource Record", RFC 2915, August 2000.
[7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. [10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource [11] 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
505 Huntmar Park Drive 505 Huntmar Park Drive
Herndon, VA 22070 Herndon, VA 22070
US US
Phone: +1 770 921-2251 Phone: +1 770 921-2251
EMail: michaelm@netsol.com EMail: michaelm@netsol.com
URI: http://www.verisign.com URI: http://www.verisign.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
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.
 End of changes. 45 change blocks. 
148 lines changed or deleted 161 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/