doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3402.txt b/doc/rfc/rfc3402.txt
new file mode 100644
index 0000000..f4c5843
--- /dev/null
+++ b/doc/rfc/rfc3402.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                        M. Mealling
+Request for Comments: 3402                                      Verisign
+Obsoletes: 2915, 2168                                       October 2002
+Category: Standards Track
+
+
+               Dynamic Delegation Discovery System (DDDS)
+                        Part Two: The Algorithm
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+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
+   transformation rules will reflect the delegation of management of
+   information associated with the string.  This document is also part
+   of a series that is completely specified in "Dynamic Delegation
+   Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401).
+   It is very important to note that it is impossible to read and
+   understand any document in this series without reading the others.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 1]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  The Algorithm  . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . .  6
+   3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . .  6
+   3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . .  8
+   4.  Specifying An Application  . . . . . . . . . . . . . . . . . .  9
+   5.  Specifying A Database  . . . . . . . . . . . . . . . . . . . . 11
+   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   6.1 An Automobile Parts Identification System  . . . . . . . . . . 12
+   6.2 A Document Identification Service  . . . . . . . . . . . . . . 14
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
+       References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
+       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
+
+1. Introduction
+
+   The Dynamic Delegation Discovery System (DDDS) is used to implement
+   lazy binding of strings to data, in order to support dynamically
+   configured delegation systems.  The DDDS functions by mapping some
+   unique string to data stored within a DDDS Database by iteratively
+   applying string transformation rules until a terminal condition is
+   reached.
+
+   This document describes the general DDDS algorithm, not any
+   particular application or usage scenario.  The entire series of
+   documents is specified in "Dynamic Delegation Discovery System (DDDS)
+   Part One: The Comprehensive DDDS" (RFC 3401) [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
+   Resource Name Working Group.  When Uniform Resource Names (URNs) [6]
+   were originally formulated there was the desire to locate an
+   authoritative server for a URN that (by design) contained no
+   information about network locations.  A system was formulated that
+   could use a database of rules that could be applied to a URN to find
+   out information about specific chunks of syntax.  This system was
+   originally called the Resolver Discovery Service (RDS) [7] and only
+   applied to URNs.
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 2]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   Over time other systems began to apply this same algorithm and
+   infrastructure to other, non-URN related, systems (see Section 6 for
+   examples of other ways of using the DDDS).  This caused some of the
+   underlying assumptions to change and need clarification.  These
+   documents are an update of those original URN specifications in order
+   to allow new applications and rule databases to be developed in a
+   standardized manner.
+
+   This document obsoletes RFC 2168 [11] and RFC 2915 [9] as well as
+   updates RFC 2276 [7].
+
+2. Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+   Application Unique String
+      A string that is the initial input to a DDDS application.  The
+      lexical structure of this string must imply a unique delegation
+      path, which is analyzed and traced by the repeated selection and
+      application of Rewrite Rules.
+
+   Rewrite Rule
+      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
+      database, or a final result string that is returned to the calling
+      application.  Also simply known as a Rule.
+
+   First Well Known Rule
+      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
+      valid key.
+
+   Terminal Rule
+      A Rewrite Rule that, when used, yields a string that is the final
+      result of the DDDS process, rather than another database key.
+
+   Application
+      A set of protocols and specifications that specify actual values
+      for the various generalized parts of the DDDS algorithm.  An
+      Application must define the syntax and semantics of the
+      Application Unique String, the First Well Known Rule, and one or
+      more Databases that are valid for the Application.
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 3]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   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.
+
+   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 Databases will
+      define a Flags field that an Application can use to encode various
+      values that express these signals.
+
+3. The Algorithm
+
+   The DDDS algorithm is based on the concept of Rewrite Rules.  These
+   rules are collected into a DDDS Rule Database, and accessed by given
+   unique keys.  A given Rule, when applied to an Application Unique
+   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
+   reapplied to the original Application Unique String and the cycle
+   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 has
+   some kind of regular, lexical structure that the rules can be applied
+   to.  It is an assumption of the DDDS that the lexical element used to
+   make a delegation decision is simple enough to be contained within
+   the Application Unique String itself.  The DDDS does not solve the
+   case where a delegation decision is made using knowledge contained
+   outside the AUS and the Rule (time of day, financial transactions,
+   rights management, etc.).
+
+
+
+
+
+Mealling                    Standards Track                     [Page 4]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   Diagrammatically the algorithm looks like this:
+
+          +--------- Application Unique String
+          |                 +-----+
+          |                 |input|
+          |         +-------+     +---------+
+          |         | First Well Known Rule |
+          |         +-------+      +--------+
+          |                 |output|
+          |                 +------+
+          |                First Key
+          |                    |
+          |                    +----<--------------<--------------+
+          |                    |                                  |
+          |                   key     (a DDDS database always     |
+          |                 +-----+    takes a key and returns    |
+          |                 |input|    a rule)                    ^
+          |       +---------+     +------------+                  |
+          |       | Lookup key in DDDS Database|                  |
+          |       +---------+      +-----------+                  |
+          |                 |output|                              |
+          |                 +------+                              |
+          |                 rule set                              |
+          |                    |                                  |
+          |                    |      (the input to a rule        |
+          |                 rule set  is the rule and the AUS.    ^
+          |                 +-----+   The output is always        |
+          +---------------->|input|   either a key or the result) |
+            +---------------+     +------------------+            |
+            | Apply Rules to Application Unique String|           |
+            | until non-empty result are obtained     |           |
+            | that meet the applications requirements |           |
+            +---------------+      +-----------------+            |
+                            |output|                              |
+                            +------+                              ^
+                              key                                 |
+                               |                                  |
+                               v                                  |
+               +--------------------------------------+           |
+               | Was the last matching rule terminal? | No >------+
+               +--------------------------------------+
+                              Yes     (if the rule isn't terminal then
+                               |      its output is the new key which
+                               |      is used to find a new rule set)
+              +------------------------------------+
+              | The output of the last rule is the |
+              | result desired by the application  |
+              +------------------------------------+
+
+
+
+Mealling                    Standards Track                     [Page 5]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+3.1 Components of a Rule
+
+   A Rule is made up of 4 pieces of information:
+
+   A Priority
+      Simply a number used to show which of two otherwise equal rules
+      may have precedence.  This allows the database to express rules
+      that may offer roughly the same results but one delegation path
+      may be faster, better, cheaper than the other.
+
+   A Set of Flags
+      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
+      the terminal rule and its output should be the intended result for
+      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 redefine 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
+      Services are used to specify semantic attributes of a particular
+      delegation branch.  There are many cases where two delegation
+      branches are identical except that one delegates down to a result
+      that provides one set of features while another provides some
+      other set.  Features may include operational issues such as load
+      balancing, geographically based traffic segregation, degraded but
+      backwardly compatible functions for older clients, etc.  For
+      example, two rules may equally apply to a specific delegation
+      decision for a string.  One rule can lead to a terminal rule that
+      produces information for use in high availability environments
+      while another may lead to an archival service that may be slower
+      but is more stable over long periods of time.
+
+   A Substitution Expression
+      This is the actual string modification part of the rule.  It is a
+      combination of a POSIX Extended Regular Expression [8] and a
+      replacement string similar to Unix sed-style substitution
+      expression.
+
+3.2 Substitution Expression Syntax
+
+   The character set(s) that the substitution expression is in and can
+   act on are dependent both on the Application and on the Database
+   being used.  An Application must define what the allowed character
+   sets are for the Application Unique String.  A DDDS Database
+   specification must define what character sets are required for
+
+
+
+Mealling                    Standards Track                     [Page 6]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   producing its keys and for how the substitution expression itself is
+   encoded.  The grammar-required characters below only have meaning
+   once a specific character set is defined for the Database and/or
+   Application.
+
+   The syntax of the Substitution Expression part of the rule is a
+   sed-style substitution expression.  True sed-style substitution
+   expressions are not appropriate for use in this application for a
+   variety of reasons, therefore the contents of the regexp field MUST
+   follow this grammar:
+
+subst-expr   = delim-char  ere  delim-char  repl  delim-char  *flags
+delim-char   = "/" / "!" / <Any octet not in 'POS-DIGIT' or 'flags'>
+                   ; All occurrences of a delim_char in a subst_expr
+                   ; must be the same character.>
+ere          = <POSIX Extended Regular Expression>
+repl         = *(string / backref)
+string       = *(anychar / escapeddelim)
+anychar      = <any character other than delim-char>
+escapeddelim = "\" delim-char
+backref      = "\" POS-DIGIT
+flags        = "i"
+POS-DIGIT    = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
+
+   The result of applying the substitution expression to the String MUST
+   result in a key which obeys the rules of the Database (unless of
+   course it is a Terminal Rule in which case the output follows the
+   rules of the application).  Since it is possible for the regular
+   expression to be improperly specified, such that a non-conforming key
+   can be constructed, client software SHOULD verify that the result is
+   a legal database key before using it.
+
+   Backref expressions in the repl portion of the substitution
+   expression are replaced by the (possibly empty) string of characters
+   enclosed by '(' and ')' in the ERE portion of the substitution
+   expression.  N is a single digit from 1 through 9, inclusive.  It
+   specifies the N'th backref expression, the one that begins with the
+   N'th '(' and continues to the matching ')'.  For example, the ERE
+
+                         (A(B(C)DE)(F)G)
+
+    has backref expressions:
+
+                         \1  = ABCDEFG
+                         \2  = BCDE
+                         \3  = C
+                         \4  = F
+                         \5..\9  = error - no matching subexpression
+
+
+
+Mealling                    Standards Track                     [Page 7]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   The "i" flag indicates that the ERE matching SHALL be performed in a
+   case-insensitive fashion.  Furthermore, any backref replacements MAY
+   be normalized to lower case when the "i" flag is given.  This flag
+   has meaning only when both the Application and Database define a
+   character set where case insensitivity is valid.
+
+   The first character in the substitution expression shall be used as
+   the character that delimits the components of the substitution
+   expression.  There must be exactly three non-escaped occurrences of
+   the delimiter character in a substitution expression.  Since escaped
+   occurrences of the delimiter character will be interpreted as
+   occurrences of that character, digits MUST NOT be used as delimiters.
+   Backrefs would be confused with literal digits were this allowed.
+   Similarly, if flags are specified in the substitution expression, the
+   delimiter character must not also be a flag character.
+
+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,
+       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 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.
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 8]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   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: 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.  Specifically, 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
+      string must have some regular structure and be unique within the
+      application such that anyone applying Rules taken from the same
+      Database will end up with the same Keys.  For example, the URI
+      Resolution application defines the Application Unique String to be
+      a URI.
+
+      No application is allowed to define an Application Unique String
+      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
+      sendmail style rewrite rules which are fragile and error prone.
+      The one single exception to this is when an Application defines
+      some flag or state where the rules for that application are
+
+
+
+Mealling                    Standards Track                     [Page 9]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+      suspended and a new DDDS Application or some other arbitrary set
+      of rules take over.  If this is the case then, by definition, none
+      of these rules apply.  One such case can be found in the URI
+      Resolution application which defines the 'p' flag which states
+      that the next step is 'protocol specific' and thus outside of the
+      scope of DDDS.
+
+   First Well Known Rule:
+      This is the first rule that, when applied to the Application
+      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.
+      For example, the URI Resolution application might specify that the
+      rule is that the sequence of characters in the URI up to but not
+      including the first colon (the URI scheme) is the first Key.
+
+   Valid Databases:
+      The application can define which Databases are valid.  For each
+      Database the Application must define how the First Well Known
+      Rule's output (the first Key) is turned into something that is
+      valid for that Database.  For example, the URI Resolution
+      application could use the Domain Name System (DNS) as a Database.
+      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
+      domain-name.  Additionally, for each Database an Application
+      defines, it must also specify what the valid character sets are
+      that will produce the correct Keys.  In the URI Resolution example
+      shown here, the character set of a URI is 7 bit ASCII which
+      matches fairly well with DNS's 8 bit limitation on characters in
+      its zone files.
+
+   Expected Output:
+      The Application must define what the expected output of the
+      Terminal Rule should be.  For example, the URI Resolution
+      application is concerned with finding servers that contain
+      authoritative data about a given URI.  Thus the output of the
+      terminal rule would be information (hosts, ports, protocols, etc.)
+      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
+
+
+
+Mealling                    Standards Track                    [Page 10]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   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
+
+   Additionally, any Application must have at least one corresponding
+   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
+   this is the case, each rule must be use some combination of its
+   Services and/or substitution expression to match only those
+   Application Unique Strings for which it is valid.
+
+   A Database specification must include the following pieces of
+   information:
+
+   General Specification:
+      The Database must have a general specification.  This can
+      reference other standards (SQL, DNS, etc.) or it can fully specify
+      a novel database system.  This specification MUST be clear as to
+      what allowed character sets exist in order to know in which
+      character set the Keys and Rules are encoded.
+
+   Lookup Procedure:
+      This specifies how a query is formulated and submitted to the
+      database.  In the case of databases that are used for other
+      purposes (such as DNS), the specification must be clear as to how
+      a query is formulated specifically for the database to be a DDDS
+      database.  For example, a DNS based Database must specify which
+      Resource Records or Query Types are used.
+
+   Key Format:
+      If any operations are needed in order to turn a Key into something
+      that is valid for the database then these must be clearly defined.
+      For example, in the case of a DNS database, the Keys must be
+      constructed as valid domain-names.
+
+   Rule Format:
+      The specification for the output format of a rule.
+
+   Rule Insertion Procedure:
+      A specification for how a Rule is inserted into the database.
+      This can include policy statements about whether or not a Rule is
+      allowed to be added.
+
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 11]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   Rule Collision Avoidance:
+      Since a Database may be used by multiple Applications (ENUM and
+      URI Resolution for example), the specification must be clear about
+      how rule collisions will be avoided.  There are usually two
+      methods for handling this: 1) disallow one key from being valid in
+      two different Applications; 2) if 1 isn't possible then write the
+      substitution expression such that the regular expression part
+      contains enough of the Application Unique String as part of its
+      match to differentiate between the two Applications.
+
+6. Examples
+
+   The examples given here are for pedagogical purposes only.  They are
+   specifically taken from ficticious 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 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
+   assigned to a part is assigned hierarchically such that the first 5
+   digits make up a parts manufacturer ID number.  The next 3 digits are
+   an auto line identifier (Ford, Toyota, etc.).  The rest of the digits
+   are assigned by the parts manufacturer according to rules that the
+   manufacturer decides.
+
+   The auto industry decides to use the DDDS to create a distributed
+   information retrieval system that routes queries to the actual owner
+   of the data.  The industry specifies a database and a query syntax
+   for retrieving rewrite rules (the APIDA Network) and then specifies
+   the Auto Parts Identification DDDS Application (APIDA).
+
+   The APIDA specification would define the following:
+
+   o  Application Unique String: the part number.
+
+   o  First Well Known Rule: take the first 5 digits (the manufacturers
+      ID number) and use that as the Key.
+
+
+
+
+Mealling                    Standards Track                    [Page 12]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   o  Valid Databases: The APIDA Network.
+
+   o  Expected Output: EDIFAC information about the part.
+
+   The APIDA Network Database specification would define the following:
+
+   o  General Specification: a network of EDI enabled databases and
+      services that, when given a subcomponent of a part number will
+      return an XML encoded rewrite rule.
+
+   o  Lookup Procedure: following normal APIDA Network protocols, ask
+      the network for a rewrite rule for the Key.
+
+   o  Key Format: no conversion is required.
+
+   o  Rule Format: see APIDA Network documentation for the XML DTD.
+
+   o  Rule Insertion Procedure: determined by the authority that has
+      control over each section of the part number.  I.e., in order to
+      get a manufacturer ID you must be a member of the Auto Parts
+      Manufacturers Association.
+
+   In order to illustrate how the system would work, imagine the part
+   number "4747301AB7D".  The system would take the first 5 digits,
+   '47473' and ask the network for that Rewrite Rule.  This Rule would
+   be provided by the parts manufacturers database and would allow the
+   manufacturer to either further sub-delegate the space or point the
+   querier directly at the EDIFAC information in the system.
+
+   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
+   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
+   parts factories for each auto line.  In our example part number the
+   number '01A' denotes the Toyota line of cars.  The Rule that the
+   manufacturer returns further delegates the query to a supply house in
+   Japan.  This rule also denotes that this Rule is terminal and thus
+   the result of this last query will be the actual information about
+   the part.
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 13]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+6.2 A Document Identification Service
+
+   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 example.
+   The difference here is that the information about the document is
+   kept very close to the author (usually on their desktop).  Thus there
+   is the probability that the number of delegations can be very deep.
+   Also, in order to keep from having a large flat space of authors, the
+   authors are organized by organizations and departments.
+
+   Let's suppose that the Application Unique String in this example
+   looks like the following:
+
+      <organization>-<department>-<author>:<project>-<bookcase>-<book>
+
+   The Application specification would look like this:
+
+   o  Application Unique String: the Document ID string given above.
+
+   o  First Well Known Rule: the characters up to but not including the
+      first '-' is treated as the first Key.
+
+   o  Valid Databases: the DIS LDAP Directory.
+
+   o  Expected Output: a record from an LDAP server containing
+      bibliographic information about the document in XML.
+
+   The Database specification for the DIS LDAP Directory would look like
+   this:
+
+   o  General Specification: the Database uses the LDAP directory
+      service.  Each LDAP server has a record that contains the Rewrite
+      Rule.  Rules refer to other LDAP servers using the LDAP URL
+      scheme.
+
+   o  Lookup Procedure: using standard LDAP queries, the client asks the
+      LDAP server for information about the Key.
+
+   o  Key Format: no conversion is necessary.
+
+   o  Rule Format: See the LDAP Rewrite Rule specification.
+
+   o  Rule Insertion Procedure: See the procedures published by the
+      entity that has authority over that section of the DIS tree.  The
+      first section, the organization, is owned by the DIS Agency.
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 14]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   In this example, the first lookup is for the organization's Rule.  At
+   that point the organization may point the client directly at some
+   large, organization wide database that contains the expected output.
+   Other organizations may decentralize this process so that Rules end
+   up delegating the query all the way down to the authors document
+   management environment of choice.
+
+7. Security Considerations
+
+   This document simply defines the DDDS algorithm and thus, by itself,
+   does not imply any security issues.  It is when this algorithm is
+   coupled with a Database and an Application that security
+   considerations can be known well enough to enumerate them beyond
+   simply saying that dynamic delegation points are a possible point of
+   attack.
+
+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", RFC 3401, October 2002.
+
+   [2]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+        Part Two: The Algorithm", RFC 3402, October 2002.
+
+   [3]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+        Part Three: The Domain Name System (DNS) Database", RFC 3403,
+        October 2002.
+
+   [4]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+        Part Four: The Uniform Resource Identifiers (URI) Resolution
+        Application", RFC 3404, October 2002.
+
+   [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+        Part Five: URI.ARPA Assignment Procedures", RFC 3405,
+        October 2002.
+
+   [6]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [7]  Sollins, K., "Architectural Principles of Uniform Resource Name
+        Resolution", RFC 2276, January 1998.
+
+
+
+
+
+Mealling                    Standards Track                    [Page 15]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+   [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.
+
+   [9]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
+        (NAPTR) DNS Resource Record", RFC 2915, August 2000.
+
+   [10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
+        2000.
+
+   [11] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
+        Identifiers using the Domain Name System", RFC 2168, June 1997.
+
+Author's Address
+
+   Michael Mealling
+   VeriSign
+   21345 Ridgetop Circle
+   Sterling, VA  20166
+   US
+
+   EMail: michael@neonym.net
+   URI:   http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 16]
+
+RFC 3402                  DDDS - The Algorithm              October 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 17]
+