draft-ietf-urn-ddds-05.txt   draft-ietf-urn-ddds-06.txt 
Network Working Group M. Mealling Network Working Group M. Mealling
Internet-Draft Verisign Internet-Draft VeriSign
Expires: April 28, 2002 October 28, 2001 Expires: August 20, 2002 February 19, 2002
Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
draft-ietf-urn-ddds-05.txt draft-ietf-urn-ddds-06.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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents 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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at 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 April 28, 2002. This Internet-Draft will expire on August 20, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document describes the Dynamic Delegation Discovery System This document describes the Dynamic Delegation Discovery System
(DDDS) algorithm for applying dynamically retrieved string (DDDS) algorithm for applying dynamically retrieved string
transformation rules to an application-unique string. Well-formed transformation rules to an application-unique string. Well-formed
transformation rules will reflect the delegation of management of transformation rules will reflect the delegation of management of
information associated with the string. This document is also part information associated with the string. This document is also part
of a series that is completely specified in "Dynamic Delegation of a series that is completely specified in "Dynamic Delegation
Discovery System (DDDS) Part One: The Comprehensive DDDS Standard" Discovery System (DDDS) Part One: The Comprehensive DDDS Standard"
skipping to change at page 2, line 13 skipping to change at page 2, line 13
others. 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 . . . . . . . . . . . . . . . . . . . . 10 3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 10
4. Specifying An Application . . . . . . . . . . . . . . . . . . 11 4. Specifying An Application . . . . . . . . . . . . . . . . . . 12
5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 13 5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 14
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1 An Automobile Parts Identification System . . . . . . . . . . 15 6.1 An Automobile Parts Identification System . . . . . . . . . . 16
6.2 A Document Identification Service . . . . . . . . . . . . . . 16 6.2 A Document Identification Service . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. 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. reached.
skipping to change at page 7, line 41 skipping to change at page 7, line 41
| result desired by the application | | result desired by the application |
+------------------------------------+ +------------------------------------+
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 may offer roughly the same results but one delegation path
may be faster, better, cheaper than the other.
A set of Flags A set of Flags
Flags are used to specify attributes of the rule that determine if Flags are used to specify attributes of the rule that determine if
this rule is the last one to be applied. The last rule is called this rule is the last one to be applied. The last rule is called
the terminal rule and its output should be the intended result for the terminal rule and its output should be the intended result for
the application. Flags are unique across Applications. An the application. Flags are unique across Applications. An
Application may specify that it is using a flag defined by yet Application may specify that it is using a flag defined by yet
another Application but it must use that other Application's another Application but it must use that other Application's
definition. One Application cannot re-define a Flag used by definition. One Application cannot re-define a Flag used by
another Application. This may mean that a registry of Flags will another Application. This may mean that a registry of Flags will
skipping to change at page 10, line 39 skipping to change at page 10, line 39
the already retrieved list of rules. the already retrieved list of rules.
5. If the Flags part of the Rule designate that this Rule is NOT 5. If the Flags part of the Rule designate that this Rule is NOT
Terminal, go back to step 2 with the substitution result as the Terminal, go back to step 2 with the substitution result as the
new Key. new Key.
6. Notify the Application that the process has finished and provide 6. Notify the Application that the process has finished and provide
the Application with the Flags and Services part of the Rule the Application with the Flags and Services part of the Rule
along with the output of the last Substitution Expression. along with the output of the last Substitution Expression.
NOTE: In some applications and/or databases the result set can NOTE 1: In some applications and/or databases the result set can
express the case where two or more Rules are considered equal. These express the case where two or more Rules are considered equal. These
Rules are treated as the same Rule, each one possibly having a Rules are treated as the same Rule, each one possibly having a
Priority which is used to weight a random selection among the Priority which is used to communicate a preference for otherwise
equivalent Rules (this allows for Rules to 'load balance' equivalent Rules. This allows for Rules to act as fallbacks for
themselves). others. It should be noted that this is a real Preference, not a
load balancing mechanism. Applications should define the difference
carefully.
NOTE 2: In some applications and/or databases the matching rules that
determine applicability to the clients requirements may depend on
what other paths may be available at that step in the delegation
tree. For example, if there are 4 rules that are applicable the last
one may be more desirable than the first. The client may be
satisfied by the first but if it chooses that one record it will
never know about the 4th one which is better. Therefore it is
considered safe to use more complex interaction between steps 3 and 4
in order to find the optimal path to follow. For example, once a
client has found a rule who's Substitution Expression produces a
result and who's Service description is acceptible, it may make note
of this but continue to look at further rules that apply (all the
while adherering to the Order!) in order to find a better one. If
none are found it can use the one it made note of.
Keep in mind that in order for this to remain safe, the input to step
3 and the output of step 4 MUST be identical to the basic algorithm.
The client software MUST NOT attempt to do this optimization outside
a specific set of Rewrite Rules (i.e. across delegation paths).
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 only string that the rewrite rules will apply to. The This is the only string that the rewrite rules will apply to. The
skipping to change at page 13, line 5 skipping to change at page 13, line 15
its zone 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.
In the past there has been some confusion concerning load balancing
and the use of the DDDS 'Priority'. Applications should be aware
that the Priority of a given rule is just that: a way of specifying
that one rule is "better, faster, cheaper" than another. If an
application needs some method of allowing a client to load balance
between servers (i.e. weighted random selection, etc) then it should
do so outside the DDDS algorithm. For example, Applications that
make use of the DNS Database may use the SRV record as a way of
signifying that a particular service is actually handled by several
hosts cooperating with each other. The difference being that load
balancing is done between hosts that are identical to each other
where as DDDS is concerned with delegation paths that have some
particular feature set or administrative domain.
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. It is important to note Database from which to retrieve the Rules. It is important to note
that a given Database may be used by more than one Application. If 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 this is the case, each rule must be use some combination of its
Services and/or substitution expression to match only those Services and/or substitution expression to match only those
Application Unique Strings for which it is valid. Application Unique Strings for which it is valid.
A Database specification must include the following pieces of A Database specification must include the following pieces of
skipping to change at page 20, line 9 skipping to change at page 21, line 9
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 but and Application specifications may have considerable requirements but
they cannot be enumerated here. they cannot be enumerated here.
References References
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf- One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-
urn-ddds-toc-00.txt (work in progress), October 2001. urn-ddds-toc-02.txt (work in progress), February 2002.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work
in progress), May 2000. in progress), February 2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-
database-07.txt (work in progress), May 2000. database-08.txt (work in progress), February 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The URI Resolution Application", RFC YYYY, draft-ietf- Four: The URI Resolution Application", RFC YYYY, draft-ietf-
urn-uri-res-ddds-05.txt (work in progress), October 2000. urn-uri-res-ddds-06.txt (work in progress), February 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf- Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-
urn-net-procedures-09.txt (work in progress), October 2001. urn-net-procedures-10.txt (work in progress), February 2002.
[6] Moats, R., "URN Syntax", RFC 2141, May 1997. [6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7] Sollins, K., "Architectural Principles of Uniform Resource Name [7] Sollins, K., "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998. Resolution", RFC 2276, January 1998.
[8] 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.
skipping to change at page 21, line 8 skipping to change at page 22, line 8
[10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September [10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000. 2000.
[11] 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 21345 Ridgetop Circle
Herndon, VA 22070 Sterling, VA 20166
US US
Phone: +1 770 921-2251 EMail: michael@neonym.net
EMail: michaelm@netsol.com URI: http://www.verisignlabs.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 (2002). 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 implementation 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 are kind, provided that the above copyright notice and this paragraph 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
 End of changes. 17 change blocks. 
33 lines changed or deleted 69 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/