--- 1/draft-ietf-urn-ddds-06.txt 2007-12-18 19:09:29.000000000 +0100 +++ 2/draft-ietf-urn-ddds-07.txt 2007-12-18 19:09:29.000000000 +0100 @@ -1,40 +1,40 @@ -Network Working Group M. Mealling +URN M. Mealling 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 - draft-ietf-urn-ddds-06.txt + draft-ietf-urn-ddds-07.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 20, 2002. + This Internet-Draft will expire on November 5, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed @@ -138,26 +138,26 @@ Rule Database Any store of Rules such that a unique key can identify a set of Rules that specify the delegation step used when that particular Key is used. Services A common rule database may be used to associate different services with a given Application Unique String; e.g. different protocol functions, different operational characteristics, geographic segregation, backwards compatibility, etc. Possible service - differences might be message receiving services for - email/fax/voicemail, load balancing over web servers, selection of - a nearby mirror server, cost vs performance trade-offs, etc. - These Services are included as part of a Rule to allow the - Application to make branching decisions based on the applicability - of one branch or the other from a Service standpoint. + differences might be message receiving services for email/fax/ + voicemail, load balancing over web servers, selection of a nearby + mirror server, cost vs performance trade-offs, etc. These + Services are included as part of a Rule to allow the Application + to make branching decisions based on the applicability of one + branch or the other from a Service standpoint. Flags Most Applications will require a way for a Rule to signal to the Application that some Rules provide particular outcomes that others do not; e.g. different output formats, extensibility mechanisms, terminal rule signaling, etc. Most Datatabases will define a Flags field that an Application can use to encode various values that express these signals. 3. The Algorithm @@ -353,67 +353,66 @@ 3.3 The Complete Algorithm The following is the exact DDDS algorithm: 1. The First Well Known Rule is applied to the Application Unique String which produces a Key 2. The Application asks the Database for the ordered set of Rules that are bound to that Key (see NOTE below on order details) - 3. The Substitution Expression for each Rule in the list is applied - to the Application Unique String until a non-empty string is - yielded. The rule that produced the non-empty string is used for - the next step. If the list is exhausted without a valid match - then the application is notified that no valid output was - available. + 3. The Substitution Expression for each Rule in the list is applied, + in order, to the Application Unique String until a non-empty + string is produced. The position in the list is noted and the + Rule that produced the non-empty string is used for the next + step. If the next step rejects this rule and returns to this + 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 - Application requirements, go back to step 3 and continue through - the already retrieved list of rules. + 4. If the Service description of the rule does not meet the client's + requirements, go back to step 3 and continue through the already + 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 Terminal, go back to step 2 with the substitution result as the new Key. 6. Notify the Application that the process has finished and provide the Application with the Flags and Services part of the Rule along with the output of the last Substitution Expression. NOTE 1: In some applications and/or databases the result set can express the case where two or more Rules are considered equal. These Rules are treated as the same Rule, each one possibly having a Priority which is used to communicate a preference for otherwise equivalent Rules. This allows for Rules to act as fallbacks for 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). + NOTE 2: Databases may or may not have rules that determine when and + how records within that database expire (expiration dates, times to + live, etc). These expiration mechanisms must be adhered to in all + cases. Specfically, since the expiration of a databases record could + cause a new Rule to be retrieved that is inconsistent with previous + Rules, while in the algorithm any attempts to optimize the process by + falling back to previous keys and Rules MUST ensure that no + previously retrieved Rule has expired. If a Rule has expired then + the application MUST start over at Step 1. 4. Specifying An Application In order for this algorithm to have any usefulness, a specification must be written describing an application and one or more databases. In order to specify an application the following pieces of information are required: Application Unique String: This is the only string that the rewrite rules will apply to. The @@ -533,21 +532,21 @@ match to differentiate between the two Applications. 6. Examples The examples given here are for pedagogical purposes only. They are specifically taken from fictious applications that have not been specified in any published document. 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 system for the various parts (nuts, bolts, frames, instruments, etc) that make up the automobile manufacturing and repair process. The problem with such a system is that the auto industry is a very distributed system where parts are built by various third parties 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 contact them about it. To facilitate this distributed system the identification number @@ -673,37 +672,37 @@ 8. IANA Considerations This document does not create any requirements on the IANA. Database and Application specifications may have considerable requirements but they cannot be enumerated here. References [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 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 - Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work - in progress), February 2002. + Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-07.txt (work + in progress), May 2002. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 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 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 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. [7] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. [8] The Institute of Electrical and Electronics Engineers, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 1-55937-255-9, January 1993.