idnits 2.17.1 draft-ietf-urn-ddds-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 211 has weird spacing: '...ule set is th...' == Line 299 has weird spacing: '...im-char ere ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2002) is 8100 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 686, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 690, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 694, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 698, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 715, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-urn-ddds-toc-02 ** Downref: Normative reference to an Informational draft: draft-ietf-urn-ddds-toc (ref. '1') == Outdated reference: A later version (-07) exists of draft-ietf-urn-ddds-06 == Outdated reference: A later version (-09) exists of draft-ietf-urn-dns-ddds-database-08 == Outdated reference: A later version (-07) exists of draft-ietf-urn-uri-res-ddds-06 == Outdated reference: A later version (-11) exists of draft-ietf-urn-net-procedures-10 ** Obsolete normative reference: RFC 2141 (ref. '6') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2915 (ref. '9') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2916 (ref. '10') (Obsoleted by RFC 3761) ** Obsolete normative reference: RFC 2168 (ref. '11') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mealling 3 Internet-Draft VeriSign 4 Expires: August 20, 2002 February 19, 2002 6 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm 7 draft-ietf-urn-ddds-06.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 20, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document describes the Dynamic Delegation Discovery System 39 (DDDS) algorithm for applying dynamically retrieved string 40 transformation rules to an application-unique string. Well-formed 41 transformation rules will reflect the delegation of management of 42 information associated with the string. This document is also part 43 of a series that is completely specified in "Dynamic Delegation 44 Discovery System (DDDS) Part One: The Comprehensive DDDS Standard" 45 (RFC WWWW). It is very important to note that it is impossible to 46 read and understand any document in this series without reading the 47 others. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 7 55 3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 8 56 3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 10 57 4. Specifying An Application . . . . . . . . . . . . . . . . . . 12 58 5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 14 59 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 6.1 An Automobile Parts Identification System . . . . . . . . . . 16 61 6.2 A Document Identification Service . . . . . . . . . . . . . . 17 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 64 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23 68 1. Introduction 70 The Dynamic Delegation Discovery System is used to implement lazy 71 binding of strings to data, in order to support dynamically 72 configured delegation systems. The DDDS functions by mapping some 73 unique string to data stored within a DDDS Database by iteratively 74 applying string transformation rules until a terminal condition is 75 reached. 77 This document describes the general DDDS algorithm, not any 78 particular application or usage scenario. The entire series of 79 documents is specified in "Dynamic Delegation Discovery System (DDDS) 80 Part One: The Comprehensive DDDS Standard" (RFC WWWW) [1]. It is 81 very important to note that it is impossible to read and understand a 82 single document in that series without reading the related documents. 84 The DDDS's history is an evolution from work done by the Uniform 85 Resource Name Working Group. When Uniform Resource Names [6] were 86 originally formulated there was the desire to locate an authoritative 87 server for a URN that (by design) contained no information about 88 network locations. A system was formulated that could use a database 89 of rules that could be applied to a URN to find out information about 90 specific chunks of syntax. This system was originally called the 91 Resolver Discovery System [7] and only applied to URNs. 93 Over time other systems began to apply this same algorithm and 94 infrastructure to other, non-URN related, systems (see Section 6 for 95 examples of other ways of using the DDDS). This caused some of the 96 underlying assumptions to change and need clarification. These 97 document are an update of those original URN specifications in order 98 to allow new applications and rule databases to be developed in a 99 standardized manner. 101 This document obsoletes RFC 2168 [11] and RFC 2915 [9] as well as 102 updates RFC 2276 [7]. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119. 110 Application Unique String 111 A string that is the initial input to a DDDS application. The 112 lexical structure of this string must imply a unique delegation 113 path, which is analyzed and traced by the repeated selection and 114 application of Rewrite Rules. 116 Rewrite Rule 117 A rule that is applied to an Application Unique String to produce 118 either a new key to select a new rewrite rule from the rule 119 database, or a final result string that is returned to the calling 120 application. Also simply known as a Rule. 122 First Well Known Rule 123 This is a rewrite rule that is defined by the application and not 124 actually in the Rule Database. It is used to produce the first 125 valid key. 127 Terminal Rule 128 A Rewrite Rule that, when used, yields a string that is the final 129 result of the DDDS process, rather than another database key. 131 Application 132 A set of protocols and specifications that specify actual values 133 for the various generalized parts of the DDDS algorithm. An 134 Application must define the syntax and semantics of the 135 Application Unique String, the First Well Known Rule, and one or 136 more Databases that are valid for the Application. 138 Rule Database 139 Any store of Rules such that a unique key can identify a set of 140 Rules that specify the delegation step used when that particular 141 Key is used. 143 Services 144 A common rule database may be used to associate different services 145 with a given Application Unique String; e.g. different protocol 146 functions, different operational characteristics, geographic 147 segregation, backwards compatibility, etc. Possible service 148 differences might be message receiving services for 149 email/fax/voicemail, load balancing over web servers, selection of 150 a nearby mirror server, cost vs performance trade-offs, etc. 151 These Services are included as part of a Rule to allow the 152 Application to make branching decisions based on the applicability 153 of one branch or the other from a Service standpoint. 155 Flags 156 Most Applications will require a way for a Rule to signal to the 157 Application that some Rules provide particular outcomes that 158 others do not; e.g. different output formats, extensibility 159 mechanisms, terminal rule signaling, etc. Most Datatabases will 160 define a Flags field that an Application can use to encode various 161 values that express these signals. 163 3. The Algorithm 165 The DDDS algorithm is based on the concept of Rewrite Rules. These 166 rules are collected into a DDDS Rule Database, and accessed by given 167 unique keys. A given Rule, when applied to an Application Unique 168 String, transforms that String into new Key that can be used to 169 retrieve a new Rule from the Rule Database. This new rule is then 170 re-applied to the original Application Unique String and the cycle 171 repeats itself until a terminating condition is reached. An 172 Application MUST NOT apply a Rule to the output of a previous Rule. 173 All Rewrite Rules for all Applications must ALWAYS apply to the exact 174 same Application Unique String that the algorithm started with. 176 It is a fundamental assumption that the Application Unique String has 177 some kind of regular, lexical structure that the rules can be applied 178 to. It is an assumption of the DDDS that the lexical element used to 179 make a delegation decision is simple enough to be contained within 180 the Application Unique String itself. The DDDS does not solve the 181 case where a delegation decision is made using knowledge contained 182 outside the AUS and the Rule (time of day, financial transactions, 183 rights management, etc). 185 Diagramatically the algorithm looks like this: 187 +--------- Application Unique String 188 | +-----+ 189 | |input| 190 | +-------+ +---------+ 191 | | First Well Known Rule | 192 | +-------+ +--------+ 193 | |output| 194 | +------+ 195 | First Key 196 | | 197 | | 198 | +----<--------------<--------------+ 199 | | | 200 | key (a DDDS database always | 201 | +-----+ takes a key and returns | 202 | |input| a rule) ^ 203 | +---------+ +------------+ | 204 | | Lookup key in DDDS Database| | 205 | +---------+ +-----------+ | 206 | |output| | 207 | +------+ | 208 | rule set | 209 | | | 210 | | (the input to a rule | 211 | rule set is the rule and the AUS. ^ 212 | +-----+ The output is always | 213 +---------------->|input| either a key or the result) | 214 +---------------+ +------------------+ | 215 | Apply Rules to Application Unique String| | 216 | until non-empty result are obtained | | 217 | that meet the applications requirements | | 218 +---------------+ +-----------------+ | 219 |output| | 220 +------+ ^ 221 key | 222 | | 223 | | 224 | | 225 | | 226 v | 227 +--------------------------------------+ | 228 | Was the last matching rule terminal? | No >------+ 229 +--------------------------------------+ 230 Yes (if the rule isn't terminal 231 | then its output is the new 232 | key which is used to find a 233 | new rule set) 234 | 235 +------------------------------------+ 236 | The output of the last rule is the | 237 | result desired by the application | 238 +------------------------------------+ 240 3.1 Components of a Rule 242 A Rule is made up of 4 pieces of information: 244 A Priority 245 Simply a number used to show which of two otherwise equal rules 246 may have precedence. This allows the database to express rules 247 that may offer roughly the same results but one delegation path 248 may be faster, better, cheaper than the other. 250 A set of Flags 251 Flags are used to specify attributes of the rule that determine if 252 this rule is the last one to be applied. The last rule is called 253 the terminal rule and its output should be the intended result for 254 the application. Flags are unique across Applications. An 255 Application may specify that it is using a flag defined by yet 256 another Application but it must use that other Application's 257 definition. One Application cannot re-define a Flag used by 258 another Application. This may mean that a registry of Flags will 259 be needed in the future but at this time it is not a requirement. 261 A description of Services 262 Services are used to specify semantic attributes of a particular 263 delegation branch. There are many cases where two delegation 264 branches are identical except that one delegates down to a result 265 that provides one set of features while another provides some 266 other set. Features may include operational issues such as load 267 balancing, geographically based traffic segregation, degraded but 268 backwardly compatibile functions for older clients, etc. For 269 example, two rules may equally apply to a specific delegation 270 decision for a string. One rule can lead to a terminal rule that 271 produces information for use in high availability environments 272 while another may lead to an archival service that may be slower 273 but is more stable over long periods of time. 275 A Substitution Expression 276 This is the actual string modification part of the rule. It is a 277 combination of a POSIX Extended Regular Expression [8] and a 278 replacement string similar to Unix sed-style substitution 279 expression. 281 3.2 Substitution Expression Syntax 283 The character set(s) that the substitution expression is in and can 284 act on are dependent both on the Application and on the Database 285 being used. An Application must define what the allowed character 286 sets are for the Application Unique String. A DDDS Database 287 specification must define what character sets are required for 288 producing its keys and for how the substitution expression itself is 289 encoded. The grammar-required characters below only have meaning 290 once a specific character set is defined for the Database and/or 291 Application. 293 The syntax of the Substitution Expression part of the rule is a sed- 294 style substitution expression. True sed-style substitution 295 expressions are not appropriate for use in this application for a 296 variety of reasons, therefore the contents of the regexp field MUST 297 follow this grammar: 299 subst-expr = delim-char ere delim-char repl delim-char *flags 300 delim-char = "/" / "!" / 301 ; All occurances of a delim_char in a subst_expr must 302 ; be the same character.> 303 ere = 304 repl = *(string / backref) 305 string = *(anychar / escapeddelim) 306 anychar = 307 escapeddelim = "\" delim-char 308 backref = "\" POS-DIGIT 309 flags = "i" 310 POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 312 The result of applying the substitution expression to the String MUST 313 result in a key which obeys the rules of the Database (unless of 314 course it is a Terminal Rule in which case the output follows the 315 rules of the application). Since it is possible for the regular 316 expression to be improperly specified, such that a non-conforming key 317 can be constructed, client software SHOULD verify that the result is 318 a legal database key before using it. 320 Backref expressions in the repl portion of the substitution 321 expression are replaced by the (possibly empty) string of characters 322 enclosed by '(' and ')' in the ERE portion of the substitution 323 expression. N is a single digit from 1 through 9, inclusive. It 324 specifies the N'th backref expression, the one that begins with the 325 N'th '(' and continues to the matching ')'. For example, the ERE 327 (A(B(C)DE)(F)G) 329 has backref expressions: 331 \1 = ABCDEFG 332 \2 = BCDE 333 \3 = C 334 \4 = F 335 \5..\9 = error - no matching subexpression 337 The "i" flag indicates that the ERE matching SHALL be performed in a 338 case-insensitive fashion. Furthermore, any backref replacements MAY 339 be normalized to lower case when the "i" flag is given. This flag 340 has meaning only when both the Application and Database define a 341 character set where case insensitivity is valid. 343 The first character in the substitution expression shall be used as 344 the character that delimits the components of the substitution 345 expression. There must be exactly three non-escaped occurrences of 346 the delimiter character in a substitution expression. Since escaped 347 occurrences of the delimiter character will be interpreted as 348 occurrences of that character, digits MUST NOT be used as delimiters. 349 Backrefs would be confused with literal digits were this allowed. 350 Similarly, if flags are specified in the substitution expression, the 351 delimiter character must not also be a flag character. 353 3.3 The Complete Algorithm 355 The following is the exact DDDS algorithm: 357 1. The First Well Known Rule is applied to the Application Unique 358 String which produces a Key 360 2. The Application asks the Database for the ordered set of Rules 361 that are bound to that Key (see NOTE below on order details) 363 3. The Substitution Expression for each Rule in the list is applied 364 to the Application Unique String until a non-empty string is 365 yielded. The rule that produced the non-empty string is used for 366 the next step. If the list is exhausted without a valid match 367 then the application is notified that no valid output was 368 available. 370 4. If the Service description of the rule does not match the 371 Application requirements, go back to step 3 and continue through 372 the already retrieved list of rules. 374 5. If the Flags part of the Rule designate that this Rule is NOT 375 Terminal, go back to step 2 with the substitution result as the 376 new Key. 378 6. Notify the Application that the process has finished and provide 379 the Application with the Flags and Services part of the Rule 380 along with the output of the last Substitution Expression. 382 NOTE 1: In some applications and/or databases the result set can 383 express the case where two or more Rules are considered equal. These 384 Rules are treated as the same Rule, each one possibly having a 385 Priority which is used to communicate a preference for otherwise 386 equivalent Rules. This allows for Rules to act as fallbacks for 387 others. It should be noted that this is a real Preference, not a 388 load balancing mechanism. Applications should define the difference 389 carefully. 391 NOTE 2: In some applications and/or databases the matching rules that 392 determine applicability to the clients requirements may depend on 393 what other paths may be available at that step in the delegation 394 tree. For example, if there are 4 rules that are applicable the last 395 one may be more desirable than the first. The client may be 396 satisfied by the first but if it chooses that one record it will 397 never know about the 4th one which is better. Therefore it is 398 considered safe to use more complex interaction between steps 3 and 4 399 in order to find the optimal path to follow. For example, once a 400 client has found a rule who's Substitution Expression produces a 401 result and who's Service description is acceptible, it may make note 402 of this but continue to look at further rules that apply (all the 403 while adherering to the Order!) in order to find a better one. If 404 none are found it can use the one it made note of. 406 Keep in mind that in order for this to remain safe, the input to step 407 3 and the output of step 4 MUST be identical to the basic algorithm. 408 The client software MUST NOT attempt to do this optimization outside 409 a specific set of Rewrite Rules (i.e. across delegation paths). 411 4. Specifying An Application 413 In order for this algorithm to have any usefulness, a specification 414 must be written describing an application and one or more databases. 415 In order to specify an application the following pieces of 416 information are required: 418 Application Unique String: 419 This is the only string that the rewrite rules will apply to. The 420 string must have some regular structure and be unique within the 421 application such that anyone applying Rules taken from the same 422 Database will end up with the same Keys. For example, the URI 423 Resolution application defines the Application Unique String to be 424 a URI. 426 No application is allowed to define an Application Unique String 427 such that the Key obtained by a rewrite rule is treated as the 428 Application Unique String for input to a new rule. This leads to 429 sendmail style rewrite rules which are fragile and error prone. 430 The one single exception to this is when an Application defines 431 some flag or state where the rules for that application are 432 suspended and a new DDDS Application or some other arbitrary set 433 of rules take over. If this is the case then, by definition, none 434 of these rules apply. One such case can be found in the URI 435 Resolution application which defines the 'p' flag which states 436 that the next step is 'protocol specific' and thus outside of the 437 scope of DDDS. 439 First Well Known Rule: 440 This is the first rule that, when applied to the Application 441 Unique String, produces the first valid Key. It can be expressed 442 in the same form as a Rule or it can be something more complex. 443 For example, the URI Resolution application might specify that the 444 rule is that the sequence of characters in the URI up to but not 445 including the first colon (the URI scheme) is the first Key. 447 Valid Databases: 448 The application can define which Databases are valid. For each 449 Database the Application must define how the First Well Known 450 Rule's output (the first Key) is turned into something that is 451 valid for that Database. For example, the URI Resolution 452 application could use the Domain Name System (DNS) as a Database. 453 The operation for turning this first Key into something that was 454 valid for the database would be to to turn it into some DNS-valid 455 domain-name. Additionally, for each Database an Application 456 defines, it must also specify what the valid character sets are 457 that will produce the correct Keys. In the URI Resolution example 458 shown here, the character set of a URI is 7 bit ASCII which 459 matches fairly well with DNS's 8 bit limitation on characters in 460 its zone files. 462 Expected Output: 463 The Application must define what the expected output of the 464 Terminal Rule should be. For example, the URI Resolution 465 application is concerned with finding servers that contain 466 authoritative data about a given URI. Thus the output of the 467 terminal rule would be information (hosts, ports, protocols, etc) 468 that would be used to contact that authoritative server. 470 In the past there has been some confusion concerning load balancing 471 and the use of the DDDS 'Priority'. Applications should be aware 472 that the Priority of a given rule is just that: a way of specifying 473 that one rule is "better, faster, cheaper" than another. If an 474 application needs some method of allowing a client to load balance 475 between servers (i.e. weighted random selection, etc) then it should 476 do so outside the DDDS algorithm. For example, Applications that 477 make use of the DNS Database may use the SRV record as a way of 478 signifying that a particular service is actually handled by several 479 hosts cooperating with each other. The difference being that load 480 balancing is done between hosts that are identical to each other 481 where as DDDS is concerned with delegation paths that have some 482 particular feature set or administrative domain. 484 5. Specifying A Database 486 Additionally, any Application must have at least one corresponding 487 Database from which to retrieve the Rules. It is important to note 488 that a given Database may be used by more than one Application. If 489 this is the case, each rule must be use some combination of its 490 Services and/or substitution expression to match only those 491 Application Unique Strings for which it is valid. 493 A Database specification must include the following pieces of 494 information: 496 General Specification: 497 The Database must have a general specification. This can 498 reference other standards (SQL, DNS, etc) or it can fully specify 499 a novel database system. This specification MUST be clear as to 500 what allowed character sets exist in order to know in which 501 character set the Keys and Rules are encoded. 503 Lookup Procedure: 504 This specifies how a query is formulated and submitted to the 505 database. In the case of databases that are used for other 506 purposes (such as DNS), the specification must be clear as to how 507 a query is formulated specifically for the database to be a DDDS 508 database. For example, a DNS based Database must specify which 509 Resource Records or Query Types are used. 511 Key Format: 512 If any operations are needed in order to turn a Key into something 513 that is valid for the database then these must be clearly defined. 514 For example, in the case of a DNS database, the Keys must be 515 constructed as valid domain-names. 517 Rule Format: 518 The specification for the output format of a rule. 520 Rule Insertion Procedure: 521 A specification for how a Rule is inserted into the database. 522 This can include policy statements about whether or not a Rule is 523 allowed to be added. 525 Rule Collision Avoidance: 526 Since a Database may be used by multiple Applications (ENUM and 527 URI Resolution for example), the specification must be clear about 528 how rule collisions will be avoided. There are usually two 529 methods for handling this: 1) disallow one key from being valid in 530 two different Applications; 2) if 1 isn't possible then write the 531 substitution expression such that the regular expression part 532 contains enough of the Application Unique String as part of its 533 match to differentiate between the two Applications. 535 6. Examples 537 The examples given here are for pedagogical purposes only. They are 538 specifically taken from fictious applications that have not been 539 specified in any published document. 541 6.1 An Automobile Parts Identification System 543 In this example imagine a system setup where by all automobile 544 manufacturers come together and create a standardized part numbering 545 system for the various parts (nuts, bolts, frames, instruments, etc) 546 that make up the automobile manufacturing and repair process. The 547 problem with such a system is that the auto industry is a very 548 distributed system where parts are built by various third parties 549 distributed around the world. In order to find information about a 550 given part a system must be able to find out who makes that part and 551 contact them about it. 553 To facilitate this distributed system the identification number 554 assigned to a part is assigned hierarchically such that the first 5 555 digits make up a parts manufacturer ID number. The next 3 digits are 556 an auto line identifier (Ford, Toyota, etc). The rest of the digits 557 are assigned by the parts manufacturer according to rules that the 558 manufacturer decides. 560 The auto industry decides to use the DDDS to create a distributed 561 information retrieval system that routes queries to the actual owner 562 of the data. The industry specifies a database and a query syntax 563 for retrieving rewrite rules (the APIDA Network) and then specifies 564 the Auto Parts Identification DDDS Application (APIDA). 566 The APIDA specification would define the following: 568 o Application Unique String: the part number 570 o First Well Known Rule: take the first 5 digits (the manufacturers 571 ID number) and use that as the Key 573 o Valid Databases: The APIDA Network 575 o Expected Output: EDIFAC information about the part 577 The APIDA Network Database specification would define the following: 579 o General Specification: a network of EDI enabled databases and 580 services that, when given a subcomponent of a part number will 581 return an XML encoded rewrite rule 583 o Lookup Procedure: following normal APIDA Network protocols, ask 584 the network for a rewrite rule for the Key. 586 o Key Format: no conversion is required 588 o Rule Format: see APIDA Network documentation for the XML DTD 590 o Rule Insertion Procedure: determined by the authority that has 591 control over each section of the part number. I.e. in order to 592 get a manufacturer ID you must be a member of the Auto Parts 593 Manufacturers Association 595 In order to illustrate how the system would work, imagine the part 596 number "4747301AB7D". The system would take the first 5 digits, 597 '47473' and ask the network for that Rewrite Rule. This Rule would 598 be provided by the parts manufacturers database and would allow the 599 manufacturer to either further sub-delegate the space or point the 600 querier directly at the EDIFAC information in the system. 602 In this example let's suppose that the manufacturer returns a Rule 603 that states that the next 3 digits should be used as part of a query 604 to their service in order to find a new Rule. This new Rule would 605 allow the parts manufacturer to further delegate the query to their 606 parts factories for each auto line. In our example part number the 607 number '01A' denotes the Toyota line of cars. The Rule that the 608 manufacturer returns further delegates the query to a supply house in 609 Japan. This rule also denotes that this Rule is terminal and thus 610 the result of this last query will be the actual information about 611 the part. 613 6.2 A Document Identification Service 615 This example is very similar to the last since the documents in this 616 system can simply be thought of as the auto part in the last example. 617 The difference here is that the information about the document is 618 kept very close to the author (usually on their desktop). Thus there 619 is the probability that the number of delegations can be very deep. 620 Also, in order to keep from having a large flat space of authors, the 621 authors are organized by organizations and departments. 623 Let's suppose that the Application Unique String in this example 624 looks like the following: 626 --:-- 628 The Application specification would look like this: 630 o Application Unique String: the Document ID string given above 631 o First Well Known Rule: the characters up to but not including the 632 first '-' is treated as the first Key. 634 o Valid Databases: the DIS LDAP Directory 636 o Expected Output: a record from an LDAP server containing 637 bibliographic information about the document in XML 639 The Database specification for the DIS LDAP Directory would look like 640 this: 642 o General Specification: the Database uses the LDAP directory 643 service. Each LDAP server has a record that contains the Rewrite 644 Rule. Rules refer to other LDAP servers using the LDAP URL 645 scheme. 647 o Lookup Procedure: using standard LDAP queries, the client asks the 648 LDAP server for information about the Key. 650 o Key Format: no conversion is necessary. 652 o Rule Format: See the LDAP Rewrite Rule specification 654 o Rule Insertion Procedure: See the procedures published by the 655 entity that has authority over that section of the DIS tree. The 656 first section, the organization, is owned by the DIS Agency. 658 In this example, the first lookup is for the organization's Rule. At 659 that point the organization may point the client directly at some 660 large, organization wide database that contains the expected output. 661 Other organizations may decentralize this process so that Rules end 662 up delegating the query all the way down to the authors document 663 management environment of choice. 665 7. Security Considerations 667 This document simply defines the DDDS algorithm and thus, by itself, 668 does not imply any security issues. It is when this algorithm is 669 coupled with a Database and an Application that security 670 considerations can be known well enough to enumerate them beyond 671 simply saying that dynamic delegation points are a possible point of 672 attack. 674 8. IANA Considerations 676 This document does not create any requirements on the IANA. Database 677 and Application specifications may have considerable requirements but 678 they cannot be enumerated here. 680 References 682 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 683 One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf- 684 urn-ddds-toc-02.txt (work in progress), February 2002. 686 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 687 Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work 688 in progress), February 2002. 690 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 691 Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- 692 database-08.txt (work in progress), February 2002. 694 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 695 Four: The URI Resolution Application", RFC YYYY, draft-ietf- 696 urn-uri-res-ddds-06.txt (work in progress), February 2002. 698 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 699 Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf- 700 urn-net-procedures-10.txt (work in progress), February 2002. 702 [6] Moats, R., "URN Syntax", RFC 2141, May 1997. 704 [7] Sollins, K., "Architectural Principles of Uniform Resource Name 705 Resolution", RFC 2276, January 1998. 707 [8] The Institute of Electrical and Electronics Engineers, "IEEE 708 Standard for Information Technology - Portable Operating System 709 Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE 710 Std 1003.2-1992, ISBN 1-55937-255-9, January 1993. 712 [9] Mealling, M. and R. Daniel, "The Naming Authority Pointer 713 (NAPTR) DNS Resource Record", RFC 2915, August 2000. 715 [10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 716 2000. 718 [11] Daniel, R. and M. Mealling, "Resolution of Uniform Resource 719 Identifiers using the Domain Name System", RFC 2168, June 1997. 721 Author's Address 723 Michael Mealling 724 VeriSign 725 21345 Ridgetop Circle 726 Sterling, VA 20166 727 US 729 EMail: michael@neonym.net 730 URI: http://www.verisignlabs.com 732 Full Copyright Statement 734 Copyright (C) The Internet Society (2002). All Rights Reserved. 736 This document and translations of it may be copied and furnished to 737 others, and derivative works that comment on or otherwise explain it 738 or assist in its implementation may be prepared, copied, published 739 and distributed, in whole or in part, without restriction of any 740 kind, provided that the above copyright notice and this paragraph are 741 included on all such copies and derivative works. However, this 742 document itself may not be modified in any way, such as by removing 743 the copyright notice or references to the Internet Society or other 744 Internet organizations, except as needed for the purpose of 745 developing Internet standards in which case the procedures for 746 copyrights defined in the Internet Standards process must be 747 followed, or as required to translate it into languages other than 748 English. 750 The limited permissions granted above are perpetual and will not be 751 revoked by the Internet Society or its successors or assigns. 753 This document and the information contained herein is provided on an 754 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 755 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 756 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 757 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 758 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 760 Acknowledgement 762 Funding for the RFC Editor function is currently provided by the 763 Internet Society.