draft-ietf-urn-ddds-06.txt   draft-ietf-urn-ddds-07.txt 
Network Working Group M. Mealling URN M. Mealling
Internet-Draft VeriSign Internet-Draft VeriSign
Expires: August 20, 2002 February 19, 2002 Expires: November 5, 2002 May 7, 2002
Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
draft-ietf-urn-ddds-06.txt draft-ietf-urn-ddds-07.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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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://
http://www.ietf.org/ietf/1id-abstracts.txt. 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 August 20, 2002. This Internet-Draft will expire on November 5, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document 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
skipping to change at page 4, line 49 skipping to change at page 4, line 49
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 services A common rule database may be used to associate different services
with a given Application Unique String; e.g. different protocol with a given Application Unique String; e.g. different protocol
functions, different operational characteristics, geographic functions, different operational characteristics, geographic
segregation, backwards compatibility, etc. Possible service segregation, backwards compatibility, etc. Possible service
differences might be message receiving services for differences might be message receiving services for email/fax/
email/fax/voicemail, load balancing over web servers, selection of voicemail, load balancing over web servers, selection of a nearby
a nearby mirror server, cost vs performance trade-offs, etc. mirror server, cost vs performance trade-offs, etc. These
These Services are included as part of a Rule to allow the Services are included as part of a Rule to allow the Application
Application to make branching decisions based on the applicability to make branching decisions based on the applicability of one
of one branch or the other from a Service standpoint. branch or the other from a Service 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 various define a Flags field that an Application can use to encode various
values that express these signals. values that express these signals.
3. The Algorithm 3. The Algorithm
skipping to change at page 10, line 20 skipping to change at page 10, line 20
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)
3. The Substitution Expression for each Rule in the list is applied 3. The Substitution Expression for each Rule in the list is applied,
to the Application Unique String until a non-empty string is in order, to the Application Unique String until a non-empty
yielded. The rule that produced the non-empty string is used for string is produced. The position in the list is noted and the
the next step. If the list is exhausted without a valid match Rule that produced the non-empty string is used for the next
then the application is notified that no valid output was step. If the next step rejects this rule and returns to this
available. step then the Substitution Expression application process
continues at the point where it left off. If the list is
exhausted without a valid match then the application is notified
that no valid output was available.
4. If the Service description of the rule does not match the 4. If the Service description of the rule does not meet the client's
Application requirements, go back to step 3 and continue through requirements, go back to step 3 and continue through the already
the already retrieved list of rules. retrieved list of rules. If it does match the client's
requirements then this Rule is used for the next step. If and
only if the client is capable of handling it and if it is deemed
safe to do so by the Application's specification, the client may
make a note of the current Rule but still return to step 3 as
though it had rejected it. In either case, the output of this
step is one and only one Rule.
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 1: 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 communicate a preference for otherwise Priority which is used to communicate a preference for otherwise
equivalent Rules. This allows for Rules to act as fallbacks for equivalent Rules. This allows for Rules to act as fallbacks for
others. It should be noted that this is a real Preference, not a others. It should be noted that this is a real Preference, not a
load balancing mechanism. Applications should define the difference load balancing mechanism. Applications should define the difference
carefully. carefully.
NOTE 2: In some applications and/or databases the matching rules that NOTE 2: Databases may or may not have rules that determine when and
determine applicability to the clients requirements may depend on how records within that database expire (expiration dates, times to
what other paths may be available at that step in the delegation live, etc). These expiration mechanisms must be adhered to in all
tree. For example, if there are 4 rules that are applicable the last cases. Specfically, since the expiration of a databases record could
one may be more desirable than the first. The client may be cause a new Rule to be retrieved that is inconsistent with previous
satisfied by the first but if it chooses that one record it will Rules, while in the algorithm any attempts to optimize the process by
never know about the 4th one which is better. Therefore it is falling back to previous keys and Rules MUST ensure that no
considered safe to use more complex interaction between steps 3 and 4 previously retrieved Rule has expired. If a Rule has expired then
in order to find the optimal path to follow. For example, once a the application MUST start over at Step 1.
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 16, line 13 skipping to change at page 16, line 13
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
In this example imagine a system setup where by all automobile In this example imagine a system setup where all automobile
manufacturers come together and create a standardized part numbering manufacturers come together and create a standardized part numbering
system for the various parts (nuts, bolts, frames, instruments, etc) system for the various parts (nuts, bolts, frames, instruments, etc)
that make up the automobile manufacturing and repair process. The that make up the automobile manufacturing and repair process. The
problem with such a system is that the auto industry is a very problem with such a system is that the auto industry is a very
distributed system where parts are built by various third parties distributed system where parts are built by various third parties
distributed around the world. In order to find information about a distributed around the world. In order to find information about a
given part a system must be able to find out who makes that part and given part a system must be able to find out who makes that part and
contact them about it. contact them about it.
To facilitate this distributed system the identification number To facilitate this distributed system the identification number
skipping to change at page 21, 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-02.txt (work in progress), February 2002. urn-ddds-toc-02.txt (work in progress), May 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-06.txt (work Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-07.txt (work
in progress), February 2002. in progress), May 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-08.txt (work in progress), February 2002. database-09.txt (work in progress), May 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-06.txt (work in progress), February 2002. urn-uri-res-ddds-07.txt (work in progress), May 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-10.txt (work in progress), February 2002. urn-net-procedures-11.txt (work in progress), May 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.
 End of changes. 15 change blocks. 
47 lines changed or deleted 46 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/