idnits 2.17.1 draft-ietf-urn-uri-res-ddds-05.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 24 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 93 has weird spacing: '..., their britt...' == Line 449 has weird spacing: '...service reg...' == Line 487 has weird spacing: '... order pref...' == Line 501 has weird spacing: '...f flags serv...' -- 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 (October 28, 2001) is 8206 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) == Missing Reference: '0' is mentioned on line 684, but not defined == Unused Reference: '2' is defined on line 587, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 606, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 625, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 628, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 641, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-urn-ddds-toc-00 ** 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-05 == Outdated reference: A later version (-09) exists of draft-ietf-urn-dns-ddds-database-07 == Outdated reference: A later version (-07) exists of draft-ietf-urn-uri-res-ddds-05 == Outdated reference: A later version (-11) exists of draft-ietf-urn-net-procedures-09 ** Downref: Normative reference to an Informational RFC: RFC 1737 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2141 (ref. '8') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '10') ** Downref: Normative reference to an Experimental RFC: RFC 2483 (ref. '11') -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '13') ** Obsolete normative reference: RFC 2168 (ref. '14') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2396 (ref. '15') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2611 (ref. '16') (Obsoleted by RFC 3406) ** Obsolete normative reference: RFC 2717 (ref. '17') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2915 (ref. '18') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) Summary: 14 errors (**), 0 flaws (~~), 18 warnings (==), 4 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: April 28, 2002 October 28, 2001 6 Dynamic Delegation Discovery System (DDDS) Part Four: The URI 7 Resolution Application 8 draft-ietf-urn-uri-res-ddds-05.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 28, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 A specification for taking a URI and locating an authoritative server 40 for information about that URI. The method used to locate that 41 authoritative server is the Dynamic Delegation Discovery System. 43 This document is part of a series that is specified in "Dynamic 44 Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS 45 Standard" (RFC WWWW). It is very important to note that it is 46 impossible to read and understand any document in this series without 47 reading the others. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. The Distinction between URNs and URLs . . . . . . . . . . . 6 54 4. The URI and URN Resolution Application Specifications . . . 7 55 4.1 Application Unique String . . . . . . . . . . . . . . . . . 7 56 4.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 7 57 4.3 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.4 Services Parameters . . . . . . . . . . . . . . . . . . . . 8 59 4.4.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.4.2 protocols . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 4.5 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 9 62 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5.1 An example using a URN . . . . . . . . . . . . . . . . . . . 11 64 5.2 CID URI Scheme Example . . . . . . . . . . . . . . . . . . . 12 65 5.3 Resolving an HTTP URI Scheme . . . . . . . . . . . . . . . . 14 66 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 68 8. Security Considerations . . . . . . . . . . . . . . . . . . 18 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 70 References . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . 21 72 A. Pseudo Code . . . . . . . . . . . . . . . . . . . . . . . . 22 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . 25 75 1. Introduction 77 The Dynamic Delegation Discovery System is used to implement lazy 78 binding of strings to data, in order to support dynamically 79 configured delegation systems. The DDDS functions by mapping some 80 unique string to data stored within a DDDS Database by iteratively 81 applying string transformation rules until a terminal condition is 82 reached. 84 This document describes a DDDS Application for resolving URIs. It 85 does not define the DDDS Algorithm or a Database. The entire series 86 of documents that do so are specified in "Dynamic Delegation 87 Discovery System (DDDS) Part One: The Comprehensive DDDS Standard" 88 (RFC WWWW) [1]. It is very important to note that it is impossible 89 to read and understand any document in that series without reading 90 the related documents. 92 Uniform Resource Identifiers have been a significant advance in 93 retrieving Internet-accessible resources. However, their brittle 94 nature over time has been recognized for several years. The Uniform 95 Resource Identifier working group proposed the development of Uniform 96 Resource Names [8] to serve as persistent, location-independent 97 identifiers for Internet resources in order to overcome most of the 98 problems with URLs. RFC 1737 [6] sets forth requirements on URNs. 100 During the lifetime of the URI-WG, a number of URN proposals were 101 generated. The developers of several of those proposals met in a 102 series of meetings, resulting in a compromise known as the Knoxville 103 framework. The major principle behind the Knoxville framework is 104 that the resolution system must be separate from the way names are 105 assigned. This is in marked contrast to most URLs, which identify 106 the host to contact and the protocol to use. Readers are referred to 107 [7]for background on the Knoxville framework and for additional 108 information on the context and purpose of this proposal. 110 Separating the way names are resolved from the way they are 111 constructed provides several benefits. It allows multiple naming 112 approaches and resolution approaches to compete, as it allows 113 different protocols and resolvers to be used. There is just one 114 problem with such a separation - how do we resolve a name when it 115 can't give us directions to its resolver? 117 For the short term, DNS is the obvious candidate for the resolution 118 framework, since it is widely deployed and understood. However, it 119 is not appropriate to use DNS to maintain information on a per- 120 resource basis. First of all, DNS was never intended to handle that 121 many records. Second, the limited record size is inappropriate for 122 catalog information. Third, domain names are not appropriate as 123 URNs. 125 Therefore our approach is to use the DDDS to locate "resolvers" that 126 can provide information on individual resources, potentially 127 including the resource itself. To accomplish this, we "rewrite" the 128 URI into a Key following the rules found in the Dynamic Delegation 129 Discovery System (DDDS). This document describes URI Resolution as 130 an application of the DDDS and specifies the use of at least one 131 Database based on DNS. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119. 139 All capitalized terms are taken from the vocabulary found in the DDDS 140 algorithm specification found in RFC ZZZZ [3]. 142 3. The Distinction between URNs and URLs 144 From the point of view of this system, there is no theoretical 145 difference between resolving URIs in the general case and URNs in the 146 specific case. Operationally however, there is a difference that 147 stems from URI resolution possibly not becoming of widespread use. 148 If URN resolution is collapsed into generic URI resolution, URNs may 149 suffer by the lack of adoption of URI resolution. 151 The solution is to allow for shortcutting for URN resolution. In the 152 following specification generic URI resolution starts by inserting 153 rules for known URI schemes into the 'uri.arpa' registry. For the 154 'URN:' URI scheme, one of the rules found in 'uri.arpa' would be for 155 the 'urn' URI scheme. This rule would simply delegate to the 156 'urn.arpa' zone for additional NAPTRs based on the URN namespace. 157 Essentially, the URI Resolution Rewrite Rule for 'URN:' is the URN 158 Resolution Application's First Well Known Rule. 160 Therefore, this document specifies two DDDS Applications. One is for 161 URI Resolution and the other is for URN Resolution. Both are 162 technically identical but by separating the two URN Resolution can 163 still proceed without the dependency. 165 4. The URI and URN Resolution Application Specifications 167 This template defines the URI and URN Resolution DDDS Application 168 according to the rules and requirements found in [3]. The DDDS 169 database used by this Application is found in [4] which is the 170 document that defines the NAPTR DNS Resource Record type. 172 4.1 Application Unique String 174 The Application Unique String is the Uniform Resource Identifier or 175 Uniform Resource Name for which an authoritative server is being 176 located. This URI or URN MUST be canonicalized and hex encoded 177 according to the "absolute-uri" production found in the Collected 178 ABNF from RFC 2396 [15]. 180 4.2 First Well Known Rule 182 In the URI case, the first known key is created by taking the URI 183 scheme. In the URN case, the first known key is the Namespace 184 Identifier. For example, the URI 'http://www.example.com/' would 185 have a 'http' as its Key. The URN 'urn:foo:foospace' would have 186 'foo' as its first Key. 188 4.3 Flags 190 At this time only four flags, "S", "A", "U", and "P", are defined. 191 The "S", "A" and "U" flags are for a terminal lookup. This means 192 that the Rule is the last one and that the flag determines what the 193 next stage should be. The "S" flag means that the output of this 194 Rule is a domain-name for which one or more SRV [9] records exist. 195 See Section 5 for additional information on how URI and URN 196 Resolution use the SRV record type. "A" means that the output of the 197 Rule is a domain-name and should be used to lookup either A, AAAA, or 198 A6 records for that domain. The "U" flag means that the output of 199 the Rule is a URI [15]. 201 The "P" flag says that the remainder of the DDDS Algorithm is ignored 202 and that the rest of the process is application specific and outside 203 the scope of this document. An application can use the Protocol part 204 found in the Services field to identify which Application specific 205 set of rules that should be followed next. The record that contains 206 the 'P' flag is the last record that is interpreted by the rules in 207 this document. One might think that this would also make the "P" 208 flag an indicator of a terminal lookup but this would be incorrect 209 since a "terminal" Rule is a DDDS concept and this flag indicates 210 that anything after this rule does not adhere to DDDS concepts at 211 all. 213 The remaining alphabetic flags are reserved for future versions of 214 this specification. The numeric flags may be used for local 215 experimentation. The S, A, U and P flags are all mutually exclusive, 216 and resolution libraries MAY signal an error if more than one is 217 given. (Experimental code and code for assisting in the creation of 218 Rewrite Rules would be more likely to signal such an error than a 219 client such as a browser). It is anticipated that multiple flags 220 will be allowed in the future, so implementers MUST NOT assume that 221 the flags field can only contain 0 or 1 characters. Finally, if a 222 client encounters a record with an unknown flag, it MUST ignore it 223 and move to the next Rule. This test takes precedence over any 224 ordering since flags can control the interpretation placed on fields. 225 A novel flag might change the interpretation of the regexp and/or 226 replacement fields such that it is impossible to determine if a 227 record matched a given target. 229 The "S", "A", and "U" flags are called 'terminal' flags since they 230 halt the looping DDDS algorithm. If those flags are not present, 231 clients may assume that another Rule exists at the Key produced by 232 the current Rewrite Rule. 234 4.4 Services Parameters 236 Service Parameters for this Application take the form of a string of 237 characters that follow this ABNF: 239 service_field = [ [protocol] *("+" rs)] 240 protocol = ALPHA *31ALPHANUM 241 rs = ALPHA *31ALPHANUM 242 ; The protocol and rs fields are limited to 32 243 ; characters and must start with an alphabetic. 245 In other words, an optional protocol specification followed by 0 or 246 more resolution services. Each resolution service is indicated by an 247 initial '+' character. 249 The empty string is also valid. This will typically be seen at the 250 beginning of a series of Rules, when it is impossible to know what 251 services and protocols will be offered at the end of a particular 252 delegation path. 254 4.4.1 Services 256 The service identifiers that make up the 'rs' production are generic 257 for both URI and URN resolution since the input value types itself 258 based on the URI scheme. The list of valid services are defined in 260 [11]. 262 Examples of some of these services are: 264 I2L: given a URI return one URL that identifies a location where the 265 original URI can be found 267 I2Ls: given a URI return one or more URLs that identify multiple 268 locations where the original URI can be found 270 I2R: given a URI return one instance of the resource identified by 271 that URI. 273 I2Rs: given a URI return one or more instances of the resources 274 identified by that URI. 276 I2C: given a URI return one instance of a description of that 277 resource. 279 I2N: given a URI return one URN that names the resource (Caution: 280 equality with respect to URNs is non-trivial. See [6]for examples 281 of why.) 283 4.4.2 protocols 285 The protocol identifiers that are valid for the 'protocol' production 286 MUST be defined by documents that are specific to URI resolution. At 287 present the THTTP [10] protocol is the only such specification. 289 It is extremely important to realize that simply specifying any 290 protocol in the services field is insufficient since there are 291 additional semantics surrounding URI resolution that are not defined 292 within the protocols. For example, if Z39.50 were to be specified as 293 a valid protocol it would have to additionally define how it would 294 encode requests for specific services, how the URI is encoded, and 295 what information is returned. 297 4.5 Valid Databases 299 At present only one DDDS Database is specified for this Application. 300 "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS 301 Database" (RFC ZZZZ) [4] specifies a DDDS Database that uses the 302 NAPTR DNS resource record to contain the rewrite rules. The Keys for 303 this database are encoded as domain-names. 305 The output of the First Well Known Rule for the URI Resolution 306 Application is the URI's scheme. In order to convert this to a 307 unique key in this Database the string 'uri.arpa.' is appended to the 308 end. This domain-name is used to request NAPTR records which 309 produces new keys in the form of domain-names. 311 The output of the First Well Known Rule of the URN Resolution 312 Application is the URN's namespace id. In order to convert this to a 313 unique key in this Database the string 'urn.arpa.' is appended to the 314 end. This domain-name is used to request NAPTR records which 315 produces new keys in the form of domain-names. 317 DNS servers MAY interpret Flag values and use that information to 318 include appropriate SRV and A records in the Additional Information 319 portion of the DNS packet. Clients are encouraged to check for 320 additional information but are not required to do so. See the 321 Additional Information Processing section of RFC YYYY for more 322 information on NAPTR records and the Additional Information section 323 of a DNS response packet. 325 The character set used to encode the substitution expression is UTF- 326 8. The allowed input characters are all those characters that are 327 allowed anywhere in a URI. The characters allowed to be in a Key are 328 those that are currently defined for DNS domain-names. The "i" flag 329 to the substitution expression is used to denote that, where 330 appropriate for the code points in question, any matches should be 331 done in a case-insensitive way. 333 5. Examples 335 5.1 An example using a URN 337 Consider a URN that uses the hypothetical FOO namespace. FOO numbers 338 are identifiers for approximately 30 million registered businesses 339 around the world, assigned and maintained by Fred, Otto and Orvil, 340 Inc. The URN might look like: 342 urn:foo:002372413:annual-report-1997 344 The first step in the resolution process is to find out about the FOO 345 namespace. The namespace identifier [8], "foo", is extracted from 346 the URN and prepended to 'urn.arpa', producing 'foo.urn.arpa'. The 347 DNS is queried for NAPTR records for this domain which produces the 348 following results: 350 foo.urn.arpa. 351 ;; order pref flags service regexp replacement 352 IN NAPTR 100 10 "s" "foolink+I2L+I2C" "" foolink.udp.example.com. 353 IN NAPTR 100 20 "s" "rcds+I2C" "" rcds.udp.example.com. 354 IN NAPTR 100 30 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.example.com. 356 The order field contains equal values, indicating that no order has 357 to be followed. The preference field indicates that the provider 358 would like clients to use the special 'foolink' protocol, followed by 359 the RCDS protocol, and that THTTP is offered as a last resort. All 360 the records specify the "s" flag which means that the record is 361 terminal and that the next step is to retrieve an SRV record from DNS 362 for the given domain-name. 364 The service fields say that if we speak of foolink, we will be able 365 to issue either the I2L, I2C or I2R requests to obtain a URL or ask 366 some complicated questions about the resource. The Resource 367 Cataloging and Distribution Service (RCDS) [12] could be used to get 368 some metadata for the resource, while THTTP could be used to get a 369 URL for the current location of the resource. 371 Assuming our client does not know the foolink protocol but does know 372 the RCDS protocol, our next action is to lookup SRV RRs for 373 rcds.udp.example.com, which will tell us hosts that can provide the 374 necessary resolution service. That lookup might return: 376 ;; Pref Weight Port Target 377 rcds.udp.example.com IN SRV 0 0 1000 deffoo.example.com. 378 IN SRV 0 0 1000 dbexample.com.au. 379 IN SRV 0 0 1000 ukexample.com.uk. 381 telling us three hosts that could actually do the resolution, and 382 giving us the port we should use to talk to their RCDS server. (The 383 reader is referred to the SRV specification [9] for the 384 interpretation of the fields above). 386 There is opportunity for significant optimization here. RFC YYYY 387 defines that Additional Information section may be available. In 388 this case the the SRV records may be returned as additional 389 information for terminal NAPTRs lookups (as well as the A records for 390 those SRVs). This is a significant optimization. In conjunction 391 with a long TTL for *.urn.arpa records, the average number of probes 392 to DNS for resolving most URIs would approach one. 394 Note that the example NAPTR records above are intended to represent 395 the result of a NAPTR lookup using some client software like 396 nslookup; zone administrators should consult the documentation 397 accompanying their domain name servers to verify the precise syntax 398 they should use for zone files. 400 Also note that there could have been an additional first step where 401 the URN was resolved as a generic URI by looking up urn.uri.arpa. 402 The resulting rule would have specified that the NID be extracted 403 from the URN and 'urn.arpa' appended to it resulting in the new key 404 'foo.urn.arpa' which is the first step from above. 406 5.2 CID URI Scheme Example 408 Consider a URI scheme based on MIME Content-Ids. The URI might look 409 like this: 411 cid:199606121851.1@bar.example.com 413 (Note that this example is chosen for pedagogical purposes, and does 414 not conform to the CID URL scheme.) 416 The first step in the resolution process is to find out about the CID 417 scheme. The schem is extracted from the URI, prepended to 418 'uri.arpa', and the NAPTR for 'cid.uri.arpa' looked up in the DNS. 419 It might return records of the form: 421 cid.uri.arpa. 422 ;; order pref flags service regexp replacement 423 IN NAPTR 100 10 "" "" "!cid:.+@(.*)$!\1!i" . 425 We have only one NAPTR response, so ordering the responses is not a 426 problem. The replacement field is empty, so we check the regexp 427 field and use the pattern provided there. We apply that regexp to 428 the entire URI to see if it matches, which it does. The \1 part of 429 the substitution expression returns the string "bar.example.com". 430 Since the flags field does not contain "s" or "a", the lookup is not 431 terminal and our next probe to DNS is for more NAPTR records at the 432 domain-name 'bar.example.com'. 434 At first glance this would make it sound as though a NAPTR would need 435 to exist for every single past and future domain-name in a particular 436 zone. This is partially correct but is handled very nicely by the 437 DNS wildcard convention. For each delegated zone in the example.com 438 domain, simply add the following records with the label set to "*". 439 In the case where the substitution expression from above generates a 440 domain-name that doesn't explicitly have a NAPTR record for it, the 441 ones listed below will be returned. If a particular domain-name was 442 an exception to this rule, simply add it to the zone explicitly and 443 those records will be returned instead of the default records. 445 The record returned from the query on "bar.example.com" might look 446 like: 448 * 449 ;; order pref flags service regexp replacement 450 IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" z3950.tcp.gatech.edu. 451 IN NAPTR 100 50 "s" "rcds+I2C" "" rcds.udp.gatech.edu. 452 IN NAPTR 100 50 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.gatech.edu. 454 Continuing with our example, we note that the values of the order and 455 preference fields are equal in all records, so the client is free to 456 pick any record. The flags field tells us that these are the last 457 NAPTR patterns we should see, and after the rewrite (a simple 458 replacement in this case) we should look up SRV records to get 459 information on the hosts that can provide the necessary service. 461 Assuming we prefer the Z39.50 protocol, our lookup might return: 463 ;; Pref Weight Port Target 464 z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu. 465 IN SRV 0 0 1000 z3950.cc.gatech.edu. 466 IN SRV 0 0 1000 z3950.uga.edu. 468 telling us three hosts that could actually do the resolution, and 469 giving us the port we should use to talk to their Z39.50 server. 471 5.3 Resolving an HTTP URI Scheme 473 Even if URN systems were in place now, there would still be a 474 tremendous number of URLs. It should be possible to develop a URI 475 resolution system that can also provide location independence for 476 those URLs. 478 Assume we have the URL for a very popular piece of software that the 479 publisher wishes to mirror at multiple sites around the world: 481 http://www.example.com/software/latest-beta.exe 483 We extract the prefix, "http", and lookup NAPTR records for 484 'http.uri.arpa'. This might return a record of the form: 486 http.uri.arpa. IN NAPTR 487 ;; order pref flags service regexp replacement 488 100 90 "" "" "!http://([^/:]+)!\1!i" . 490 This expression returns everything after the first double slash and 491 before the next slash or colon. (We use the '!' character to delimit 492 the parts of the substitution expression. Otherwise we would have to 493 use backslashes to escape the forward slashes, and would have a 494 regexp in the zone file that looked like this: 495 "/http:\\/\\/([^\\/:]+)/\\1/i"). 497 Applying this pattern to the URL extracts "www.example.com". Looking 498 up NAPTR records for that might return: 500 www.example.com. 501 ;; order pref flags service regexp replacement 502 IN NAPTR 100 100 "s" "thttp+L2R" "" thttp.example.com. 503 IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.example.com. 505 Looking up SRV records for thttp.example.com would return information 506 on the hosts that example.com has designated to be its mirror sites. 507 The client can then pick one for the user. 509 6. Notes 511 o Registration procedures for the 'urn.arpa' and 'uri.arpa' DNS 512 zones are specified in "Dynamic Delegation Discovery System 513 (DDDS) Part Five: URI.ARPA Assignment Procedures" (RFC VVVV) [5]. 515 o If a record at a particular order matches the URI, but the client 516 doesn't know the specified protocol and service, the client SHOULD 517 continue to examine records that have the same order. The client 518 MUST NOT consider records with a higher value of order. This is 519 necessary to make delegation of portions of the namespace work. 520 The order field is what lets site administrators say "all requests 521 for URIs matching pattern x go to server 1, all others go to 522 server 2". 524 o Note that SRV RRs impose additional requirements on clients. 526 7. IANA Considerations 528 The use of the "urn.arpa" and "uri.arpa" zones requires registration 529 policies and procedures to be followed and for the operation of those 530 DNS zones to be maintained. These policies and procedures are 531 spelled out in a "Dynamic Delegation Discovery System (DDDS) Part 532 Five: URI.ARPA Assignment Procedures (RFC VVVV)" [5]. The operation 533 of those zones imposes operational and administrative 534 responsibilities on the IANA. 536 The registration method used for values in the Services and Flags 537 fields is for a specification to be approved by the IESG and 538 published as either an Informational or standards track RFC. 540 The registration policies for URLs is found in RFC2717 [17]. URN NID 541 registration policies are found in RFC2611 [16]. 543 8. Security Considerations 545 The use of "urn.arpa" and "uri.arpa" as the registry for namespaces 546 is subject to denial of service attacks, as well as other DNS 547 spoofing attacks. The interactions with DNSSEC are currently being 548 studied. It is expected that NAPTR records will be signed with SIG 549 records once the DNSSEC work is deployed. 551 The rewrite rules make identifiers from other namespaces subject to 552 the same attacks as normal domain names. Since they have not been 553 easily resolvable before, this may or may not be considered a 554 problem. 556 Regular expressions should be checked for sanity, not blindly passed 557 to something like PERL. 559 This document has discussed a way of locating a resolver, but has not 560 discussed any detail of how the communication with the resolver takes 561 place. There are significant security considerations attached to the 562 communication with a resolver. Those considerations are outside the 563 scope of this document, and must be addressed by the specifications 564 for particular resolver communication protocols. 566 9. Acknowledgments 568 The editors would like to thank Keith Moore for all his consultations 569 during the development of this draft. We would also like to thank 570 Paul Vixie for his assistance in debugging our implementation, and 571 his answers on our questions. Finally, we would like to acknowledge 572 our enormous intellectual debt to the participants in the Knoxville 573 series of meetings, as well as to the participants in the URI and URN 574 working groups. 576 Specific recognition is given to Ron Daniel who was co-author on the 577 original versions of these documents. His early implementations and 578 clarity of thinking was invaluable in clearing up many of the 579 potential boundary cases. 581 References 583 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 584 One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf- 585 urn-ddds-toc-00.txt (work in progress), October 2001. 587 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 588 Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work 589 in progress), May 2000. 591 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 592 Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- 593 database-07.txt (work in progress), May 2000. 595 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 596 Four: The URI Resolution Application", RFC YYYY, draft-ietf- 597 urn-uri-res-ddds-05.txt (work in progress), October 2000. 599 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 600 Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf- 601 urn-net-procedures-09.txt (work in progress), October 2001. 603 [6] Sollins, K. and L. Masinter, "Functional Requirements for 604 Uniform Resource Names", RFC 1737, December 1994. 606 [7] Arms, B., "The URN Implementors, Uniform Resource Names: A 607 Progress Report", D-Lib Magazine, February 1996. 609 [8] Moats, R., "URN Syntax", RFC 2141, May 1997. 611 [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 612 specifying the location of services (DNS SRV)", RFC 2782, 613 February 2000. 615 [10] Daniel, R., "A Trivial Convention for using HTTP in URN 616 Resolution", RFC 2169, June 1997. 618 [11] Mealling, M., "URI Resolution Services Necessary for URN 619 Resolution", RFC 2483, January 1999. 621 [12] Moore, K., Browne, S., Cox, J. and J. Gettler, "Resource 622 Cataloging and Distribution System", Technical Report CS-97- 623 346, December 1996. 625 [13] Sollins, K., "Architectural Principles of Uniform Resource Name 626 Resolution", RFC 2276, January 1998. 628 [14] Daniel, R. and M. Mealling, "Resolution of Uniform Resource 629 Identifiers using the Domain Name System", RFC 2168, June 1997. 631 [15] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 632 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 633 1998. 635 [16] Daigle, L., van Gulik, D., Iannella, R. and P. Falstrom, "URN 636 Namespace Definition Mechanisms", RFC 2611, BCP 33, June 1999. 638 [17] Petke, R. and I. King, "Registration Procedures for URL Scheme 639 Names", RFC 2717, BCP 35, November 1999. 641 [18] Mealling, M. and R. Daniel, "The Naming Authority Pointer 642 (NAPTR) DNS Resource Record", RFC 2915, August 2000. 644 Author's Address 646 Michael Mealling 647 Verisign 648 505 Huntmar Park Drive 649 Herndon, VA 22070 650 US 652 Phone: +1 770 921-2251 653 EMail: michaelm@netsol.com 654 URI: http://www.verisign.com 656 Appendix A. Pseudo Code 658 For the edification of implementers, pseudocode for a client routine 659 using NAPTRs is given below. This code is provided merely as a 660 convenience, it does not have any weight as a standard way to process 661 NAPTR records. Also, as is the case with pseudocode, it has never 662 been executed and may contain logical errors. You have been warned. 664 // 665 // findResolver(URN) 666 // Given a URN, find a host that can resolve it. 667 // 668 findResolver(string URN) { 669 // prepend prefix to urn.arpa 670 sprintf(key, "%s.urn.arpa", extractNS(URN)); 671 do { 672 rewrite_flag = false; 673 terminal = false; 674 if (key has been seen) { 675 quit with a loop detected error 676 } 677 add key to list of "seens" 678 records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' 680 discard any records with an unknown value in the "flags" field. 681 sort NAPTR records by "order" field and "preference" field 682 (with "order" being more significant than "preference"). 683 n_naptrs = number of NAPTR records in response. 684 curr_order = records[0].order; 685 max_order = records[n_naptrs-1].order; 687 // Process current batch of NAPTRs according to "order" field. 688 for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { 689 if (unknown_flag) // skip this record and go to next one 690 continue; 691 newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); 692 if (!newkey) // Skip to next record if the rewrite didn't 693 match continue; 694 // We did do a rewrite, shrink max_order to current value 695 // so that delegation works properly 696 max_order = naptr[j].order; 697 // Will we know what to do with the protocol and services 698 // specified in the NAPTR? If not, try next record. 699 if(!isKnownProto(naptr[j].services)) { 700 continue; 701 } 702 if(!isKnownService(naptr[j].services)) { 703 continue; 704 } 706 // At this point we have a successful rewrite and we will 707 // know how to speak the protocol and request a known 708 // resolution service. Before we do the next lookup, check 709 // some optimization possibilities. 710 if (strcasecmp(flags, "S") 711 || strcasecmp(flags, "P")) 712 || strcasecmp(flags, "A")) { 713 terminal = true; 714 services = naptr[j].services; 715 addnl = any SRV and/or A records returned as additional 716 info for naptr[j]. 717 } 718 key = newkey; 719 rewriteflag = true; 720 break; 721 } 722 } while (rewriteflag && !terminal); 724 // Did we not find our way to a resolver? 725 if (!rewrite_flag) { 726 report an error 727 return NULL; 728 } 730 // Leave rest to another protocol? 731 if (strcasecmp(flags, "P")) { 732 return key as host to talk to; 733 } 735 // If not, keep plugging 736 if (!addnl) { // No SRVs came in as additional info, look them up 737 srvs = lookup(type=SRV, key); 738 } 740 sort SRV records by preference, weight, ... 741 foreach (SRV record) { // in order of preference 742 try contacting srv[j].target using the protocol and one of the 743 resolution service requests from the "services" field of the 744 last NAPTR record. 745 if (successful) 746 return (target, protocol, service); 747 // Actually we would probably return a result, but this 748 // code was supposed to just tell us a good host to talk to. 749 } 750 die with an "unable to find a host" error; 751 } 753 Full Copyright Statement 755 Copyright (C) The Internet Society (2001). All Rights Reserved. 757 This document and translations of it may be copied and furnished to 758 others, and derivative works that comment on or otherwise explain it 759 or assist in its implementation may be prepared, copied, published 760 and distributed, in whole or in part, without restriction of any 761 kind, provided that the above copyright notice and this paragraph are 762 included on all such copies and derivative works. However, this 763 document itself may not be modified in any way, such as by removing 764 the copyright notice or references to the Internet Society or other 765 Internet organizations, except as needed for the purpose of 766 developing Internet standards in which case the procedures for 767 copyrights defined in the Internet Standards process must be 768 followed, or as required to translate it into languages other than 769 English. 771 The limited permissions granted above are perpetual and will not be 772 revoked by the Internet Society or its successors or assigns. 774 This document and the information contained herein is provided on an 775 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 776 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 777 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 778 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 779 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 781 Acknowledgement 783 Funding for the RFC Editor function is currently provided by the 784 Internet Society.