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