idnits 2.17.1 draft-girod-urn-res-using-wire-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 660 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 213 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([8], [9], [11]), 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 411: '...by including the OPTIONAL header in th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 545 has weird spacing: '...service regex...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? '11' on line 583 looks like a reference -- Missing reference section? '8' on line 536 looks like a reference -- Missing reference section? '9' on line 82 looks like a reference -- Missing reference section? '7' on line 388 looks like a reference -- Missing reference section? '10' on line 592 looks like a reference -- Missing reference section? '4' on line 56 looks like a reference -- Missing reference section? '5' on line 56 looks like a reference -- Missing reference section? '2' on line 112 looks like a reference -- Missing reference section? '3' on line 387 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Lewis Girod 3 Date: March 13, 1998 Benjie Chen 4 Expires: September 18, 1998 MIT Laboratory for Computer Science 5 draft-girod-urn-res-using-wire-00.txt John Mallery 6 MIT Artificial Intelligence Laboratory 8 URN Resolution Using WIRE 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working documents of 13 the Internet Engineering Task Force (IETF), its areas, and its working 14 groups. Note that other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months and 18 may be updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet- Drafts as reference material or to cite them 20 other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au 25 (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West 26 Coast). 28 Abstract 30 The identifier resolution extensions proposed in WIRE [11] add new 31 mechanisms for redirection and resolver delegation to HTTP. While these 32 mechanisms are generalized to support resolution of all URIs, they were 33 designed in part to meet the specific needs of URN resolution systems. 35 This document describes how the WIRE model maintains consistency with 36 existing models of URN resolution, how WIRE can be used as a URN resolution 37 protocol, and how WIRE fits into the existing URN resolution infrastructure, 38 including NAPTR [8] and THTTP [9]. 40 1 Introduction 42 This section comprises about half of this document. This lengthy 43 introduction is an effort to summarize the history of URN resolution, 44 explain the URN-oriented design rationale behind WIRE, and present a model 45 for resolution that we have found useful for thinking about URN resolution 46 while avoiding endless confusion. 48 The rest of the document is organized as follows: Section 2 describes the 49 syntax and semantics of URN resolution hints; Section 3 describes some 50 examples of URN resolution with WIRE; Section 4 describes the caching of URN 51 resolution responses; Section 5 discusses security issues. 53 Details about URN syntax, URN resolution architecture, and particular URN 54 resolution systems are outside the scope of this document. We expect readers 55 of this document to be familiar with the various URN documents 56 ([7][8][9][10]), HTTP ([4][5]), and WIRE ([11]). 58 1.1 Background 60 Uniform Resource Names, or URNs, are identifiers for Internet resources that 61 have the capability to be maintained persistently for long periods of time. 62 Each URN is globally unique and fits into a namespace that can be resolved 63 globally. Rather than specifying a location and a fixed resolution 64 mechanism, URNs are generally location-independent and are resolved using a 65 mechanism that can evolve over time. Some URNs are considered to refer to 66 "conceptual" resources that may have many different versions or may change 67 dynamically. See [2] for a description of URN properties. 69 A large database containing resolution data for every URN is not a scalable 70 approach to URN resolution. Instead, the URN Working Group of the IETF has 71 been coordinating an effort to engineer a distributed authority model for 72 URN namespaces. In this model, many resolvers worldwide serve different 73 parts of a global URN namespace, implementing a federation of diverse 74 resolution systems and protocols. This architecture enables the global URN 75 infrastructure to scale to large numbers of URNs, to large volumes of 76 requests, and to diverse administrative policies. This architecture requires 77 that a URN resolver not only be able to resolve URNs within its own 78 namespace, but also delegate spaces of URNs to other resolvers. 80 Until recently, URN resolution has exclusively been implemented using the 81 Naming Authority PoinTeR (NAPTR) ([8]) resolution algorithm and the Trivial 82 HTTP (THTTP) ([9]) convention for URI resolution. The NAPTR algorithm uses 83 special records in the Domain Name System to achieve flexibility of 84 delegation. There are two powerful advantages to this approach: first, the 85 DNS is widely implemented and no significant changes to the server are 86 required, and second, the DNS is designed with the desired mechanisms for 87 distributing authority built in. Similarly, the THTTP convention is 88 advantageous because it defines a simple interface for performing URN 89 resolution that does can be added to an existing web server through the CGI 90 interface. 92 However, early experimentation with the THTTP convention has shown some 93 weaknesses. For example, it is not always clear how errors should be 94 reported to the client, and it does not include a well-defined way to invoke 95 methods other than "GET" on the referenced object. Redirection, which would 96 be a powerful tool for delegation of URN spaces, is also not well defined by 97 the convention. No recommendations are made about the behavior of caching 98 proxies or client side caches. 100 WIRE [11] is an attempt to integrate functionality necessary for URN 101 resolution into HTTP and to reduce that functionality to the more general 102 case of URI resolution. WIRE is an extension of HTTP/1.0 or above that 103 defines new semantics for resolver delegation. WIRE combines the 104 functionality of a "terminal" resolution protocol such as THTTP with 105 redirection and delegation functionality similar to that of the NAPTR 106 algorithm. WIRE can both act as a gateway to other systems as well as return 107 delegation responses that can "escape" to arbitrary alternate protocols. 109 1.2 Requirements 111 Work in the IETF URN Working Group has led to a set of requirements for URN 112 resolution infrastructure [2][10]. WIRE was designed with the following 113 goals in mind: 115 1. Enable new resolver implementations to work immediately with the 116 existing infrastructure. WIRE must act as a gateway interface to new 117 resolution services, while permitting new services to independently 118 choose whether to proxy a resolution request or redirect it to another 119 resolver. 120 2. Permit resolver delegations to reference other protocols or services. A 121 resource may be accessible via protocols other than HTTP (e.g. CORBA 122 objects). Some resolution protocols may specify local caching resolvers 123 (e.g. HTTP clients can be configured to use a caching proxy; a web 124 client might use the local DNS server to resolve NAPTR records). 125 3. Encourage the development of hint-based mechanisms by defining new data 126 structures that bind hint information to URIs. Implement the idea of 127 "delegation" as resolution to incremental metadata, and unify that idea 128 with "terminal" resolution to resources. Specify mechanisms whereby 129 client-side interpretation of metadata can act as a vehicle for 130 delegation, redirection, and content negotiation. 132 URN infrastructure enables persistent references by building flexibility 133 into URN resolution mechanisms. In order to speed deployment, these 134 mechanisms need to be incorporated into existing infrastructures. The W3 135 infrastructure is a particularly appealing choice because of its wide 136 acceptance and its potential to benefit from persistent naming. A number of 137 reasons make adding URN resolution to HTTP a viable approach: 139 1. HTTP is a very widely deployed protocol. It is simple and human 140 readable. It defines proxy semantics that can be used to implement new 141 features in a proxy server. WIRE extends HTTP and therefore retains 142 those properties. 143 2. HTTP has many useful features and semantics that WIRE also inherit. 144 These include proxy servers, caching, authentication, etc. 145 3. Through the use of resolution hints, WIRE gives clients the power to 146 choose methods of resolution. This allows a flexible and scalable 147 architecture. 149 1.3 Resolution Model 151 One of the recurring problems experienced by the URI community has been a 152 tendency to get trapped in the cavernous ratholes surrounding references to 153 resources. WIRE [11] includes a section describing a simplified resolution 154 model for URI resolution. Here we explain how this model applies to URN 155 resolution. In doing so we hope to address some of areas that have 156 historically led to confusion. 158 Rather than repeat the description in [11], we summarize: to resolve a URN, 159 ask the right server to resolve it, supplying any appropriate arguments, and 160 that server will perform the resolution. If that server is not the right 161 server, it returns a redirection/delegation, or an error message: 163 _____________________ 164 GET | | Standard 165 URN[?argument] --->| Right Resolver? | Yes ---> HTTP 166 [hint: "hint"] |_____________________| Response 167 ^ | No | Error 168 | | | 169 | v v 170 +------- 350 Redirect 400 Bad Request 172 The resolver in the box can do as much work on the client's behalf as its 173 local policy allows. Arguments specified in the request can cause particular 174 methods to be performed on the resource when it is resolved; for example 175 "resolution services" can be implemented this way. The 350 redirect can 176 redirect resolution to other protocols, which may in turn provide similar 177 delegation capabilities. Just as WIRE's resolution model borrows many ideas 178 from the NAPTR algorithm [8], a similar model could easily be applied to 179 other resolution protocols. 181 1.3.1 Popular Modes of Confusion 183 This model is designed to avoid certain areas of confusion that crop up with 184 URN resolution. First, it clears up confusion about what a URN resolves to, 185 by declaring that a URN resolves to typed data, with the type indicated 186 dynamically by response headers. In this way, the WIRE model rejects the 187 idea that a URN is constrained to resolve to a particular type (e.g. a 188 "special" metadata type), instead providing identical semantics to any other 189 HTTP request. This allows WIRE to be used more readily as a gateway 190 protocol. 192 The notion of "resolution services" [10] tends to further blur the question 193 of what a URN resolves to. By implementing a resolver that supports a set of 194 resolution services, in essence this means that the URN resolves to an 195 object to which resolution services may be applied as method calls on an 196 object. This is not a problem as long as it remains clear that the object 197 named by a URN is not the "resource" that might eventually be retrieved 198 (say, by servicing an "I2R" request) but rather the server-side instance 199 that provides the resolution services. Historically this distinction has 200 been the source of no small amount of confusion. 202 The idea of "metadata" is another source of confusion. It is clear that the 203 association of metadata with an object is something that we would like to 204 work into our more advanced and more flexible concept of identifier 205 resolution. URNs can be mapped to collections of metadata that in turn 206 reference more concrete resources; this metadata can be used by the client 207 to do content negotiation, or can be exploited by indexing agents. All of 208 these ideas stem from the possibility that a URN identifies a "conceptual 209 resource", a resource that might move or change over time but can retain the 210 same mapping from name to concept as a result of a flexible URN resolution 211 mechanism. However, "conceptual resources" are problematic because it 212 rapidly becomes unclear whether the URN references the metadata that 213 describes the resource, the whole abstract resource, or any given part of 214 the resource. Which should a resolution operation return? 216 1.3.2 An Axiomatic Model of Resolution 218 To make sense of these problems, we propose a set of axioms that define a 219 way to think about resolution processes. These axioms look at resolution 220 processes as a scoped set of processes that can be observed at varying 221 levels of detail. Often this leads to confusion when there is ambiguity 222 about which layer of abstraction is in focus and which stage of the 223 discovery process is in process. The critical idea here is that the same URN 224 might resolve differently at different layers of abstraction and stages of 225 discovery. In order to understand how a particular URN should resolve it is 226 important to keep the relevant contextual information clearly in mind. 228 1. In general, outside of the context of a particular resolution 229 mechanism, a URI resolves to bits. 230 2. Within the context of a particular resolution mechanism, there are 231 intermediate resolution steps and a final resolution step. External to 232 that mechanism, we can ignore the intermediate steps, and consider the 233 final step to be resolution of the URI. 234 3. In general, the final resolution step is a method call on some remote 235 object, which may be as simple as "GET". The resolution mechanism 236 defines whether the results of any given operation are best considered 237 to be metadata, or data, or any other type of thing. 238 4. Any particular resolution process can be considered to be an 239 intermediate step inside a more complex resolution process. 240 5. Different resolution mechanisms may resolve the same URI to different 241 data. Different resolution mechanisms may consider "resolution" 242 complete at different stages of the process. 244 1.3.3 Some Examples 246 These ideas are best explained with an example. A user clicks on a link that 247 contains the text of URN X. The browser performs a sequence of intermediate 248 steps to resolve URN X, resulting in a displayed HTML page. From the user's 249 point of view, URN X resolves to that page. 251 If we zoom in on the browser, we see three intermediate steps, and we see 252 that at this level X really resolves to metadata: 254 1. URN X resolves to bits that the browser understands as metadata 255 2. The metadata tells the browser that the English version is accessible 256 at URN Y 257 3. Since the browser knows that the user wants the English version, it 258 resolves URN Y to an HTML page that is in turn displayed. 260 If we zoom in on step (1), we see three intermediate steps, and we see that 261 locally X resolves to a 350 response that points to resolver R: 263 1. A "GET X" request is sent to a local WIRE resolver. 264 2. That resolver returns a 350 redirect pointing to resolver R. 265 3. A "GET X" request is sent to resolver R, and a 200 response containing 266 metadata is returned. 268 1.4 Clarification 270 In previous URN resolution documents ([8][10]) the term "Resolver Discovery 271 System", or RDS, has been used to describe the interactions of a set of 272 servers designed solely to locate a resolver, which can then be used to 273 resolve the URN. In our opinion, this distinction between RDS and resolver 274 unnecessarily increases the complexity of the model. It also puts an 275 unnecessary constraint on designers of URN resolution systems: for example, 276 some systems might include servers that can act both as resolvers and 277 resolver locators. 279 In this document, we use the term "resolver" to describe a server that can 280 either resolve a URN or delegate the resolution authority to another 281 resolver. This second behavior allows us to use the term "resolver" as a 282 replacement for "RDS". 284 2 Resolution Hints 286 WIRE defines a general form for resolution hints, and leaves the definition 287 of specific hint schemes to the resolution applications that use them. In 288 this section we present a hint syntax designed to support URN resolvers. 290 2.1 Resolution Starting Point 292 Namespace identifiers, stored in a global registry ([10]), identify URN 293 namespaces. A namespace can be further divided into subspaces. When a child 294 subspace and its parent namespace are covered by different resolvers, the 295 resolution process of a URN in the child subspace must be delegated from the 296 parent namespace resolver to the subspace resolver. 298 If a resolver covers more than one subspace, then prior to resolving the 299 request URN it must first determine to which subspace the URN belongs. 300 Because the lexical ordering of a URN is not guaranteed to be uniform across 301 delegation boundaries (see section 4 for an example), a URN's enclosing 302 subspace cannot be identified syntactically, and can only be reliably 303 discovered by performing the entire resolution process from the beginning. 305 This means that in order to make progress in the resolution, the hint passed 306 to a URN resolver may need to contain a token that tells the resolver which 307 URN space to begin searching. We call this token a resolution starting 308 point. A resolution starting point has the following grammar: 310 resolution-starting-pt = urn 312 The only syntactical constraint on resolution starting point is that it must 313 follow the URN syntax ([7]). Its syntax and semantics are defined by the 314 resolver that receives and interprets it. A child resolver that needs to 315 receive a specific starting point specifies this to be part of the hint 316 information served by the resolver of the parent namespace. 318 2.2 Resolution Hints for Resolving URNs 320 A resolution hint tells a client how to continue resolving a specific URI. 321 When a client uses a hint to contact a new WIRE resolver, a derivative of 322 that hint is included in the request to that resolver. For the purposes of 323 URN resolution, a hint needs to contain the location and protocol of a 324 resolver, and it may optionally specify a resolution starting point to be 325 interpreted by that resolver and a type model pertaining to that resolver. 326 Resolution hints for URN resolution have the following grammar: 328 resolution-hint = "res-hint:" url [starting-point] [type-model] 329 starting-point = ";scope=" resolution-starting-pt 330 type-model = ";type=" type-specifier * ( "+" type-specifier ) 331 type-specifier = urn 333 Operationally speaking, the URL specified in the resolution hint tells the 334 client how to contact the resolver. The type model tells the client what 335 types of object are stored at the target resolver or what services are 336 provided there. This can allow the client to invoke a particular method on 337 the object through the '?' construct, if the type model is one that the 338 client understands. The client can indicate which type(s) it wants to use by 339 modifying the type parameter in the hint passed along in the request. If it 340 is included in the original hint, the scope parameter helps the target 341 resolver perform the search; if present this should be passed along to the 342 target resolver unchanged. 344 For example, the resolution hint 346 res-hint:http://thebe.lcs.mit.edu;scope=urn:cid:;type=urn:type:N2C+urn:type:N2L 348 states that the URN can be further resolved at thebe.lcs.mit.edu using the 349 HTTP WIRE extensions. The server expects the starting point "urn:cid:", and 350 that the object there can perform methods corresponding to both "N2C" and 351 "N2L" service types. 353 The protocol scheme of the URL portion of the resolution hint is used to 354 specify the protocol used by the target resolver. Native resolver protocols 355 can enable great performance improvements through more effective caching 356 strategies, smarter cache sharing, and local caching servers. For example, 357 NAPTR is efficient because the client is configured to query a local DNS 358 server that can perform transparent caching, as well as numerous other 359 performance tricks. Resolution hints might refer to the NAPTR client 360 algorithm or the THTTP terminal resolution protocol: 362 res-hint:naptr://cid.urn.net 363 res-hint:thttp://thebe.lcs.mit.edu;type=urn:type:N2C+urn:type:N2L 365 Clients that understand the NAPTR algorithm could use the first hint to 366 start following NAPTR records beginning with "cid.urn.net". Clients that 367 understand THTTP could use the second hint to connect to a resolver and 368 request either the N2C or N2L services. 370 The scope attribute in the hint is optional. In many instances it is 371 unnecessary, for example in hints for servers that serve only a single, 372 clearly defined subspace. If a resolver requires a scope attribute but it is 373 missing, the resolver may either return an error or attempt to discover the 374 URN's subspace beginning with the root URN registry, possibly returning a 375 350 code as a result. 377 For various purposes such as caching and loop avoidance ([11]), it is often 378 desirable to determine if two resolution hints are the same. WIRE defines 379 generic hint equivalence as lexical equivalence after URI normalization. For 380 clients that understand the "res-hint" scheme, an extended set of 381 normalization rules can be applied. Two resolution hints are lexically 382 equivalent if they are octet-by-octet equal after the following 383 preprocessing: 385 1. normalize the case of the leading "res-hint:" token, the ";scope=" 386 token, and the ";type=" token. 387 2. %-escape the url portion using octet encoding rules from [3] 388 3. %-escape the urn portions using rules from [7] 390 2.3 Applications of Resolution Hints 392 2.3.1 Resolver Behaviors 394 A resolution hint is said to be "local to a resolver" if and only if the url 395 portion of the hint identifies that resolver. Otherwise, it is a remote 396 resolution hint. 398 If a resolver receives a resolution request with a local resolution hint, it 399 must try to resolve the URN. If a request contains a remote resolution hint, 400 the resolver may proxy the resolution request to the remote server 401 indicated, according to local policy. If proxying the request violates local 402 policy, the resolver may return a 400 error code. 404 When resolution is successful, normal HTTP semantics take over. A 404 error 405 message should ONLY be returned if the resolver is the authoritative 406 resolver but the URN cannot be resolved. When a resolver cannot resolve a 407 URN because the URN is under a different subspace, a 350 response or a 408 non-404 error message should be returned to the client. Encapsulated in this 409 350 responses are a set of URIs, each bound to zero or more resolution 410 hints. Note that 350 responses may only be returned to clients that indicate 411 compliance with WIRE by including the OPTIONAL header in the request. A 412 resolver that receives a request from a non-WIRE client may choose to proxy 413 the remainder of the resolution process according to local policy. 414 Otherwise, a 400 response code must be returned. 416 When a URN resolver needs to delegate the resolution process, it should use 417 a 350 response code to return a set of alternate URIs and hints that would 418 allow the continuation of the current URN. These set should include hints 419 for resolving the current URN and/or alternate URIs and hints that resolve 420 to the same resource as the URN, where equivalence is defined by the 421 authoritative resolver. The client should be able to use any of the URI 422 bindings to complete the resolution process. 424 2.3.2 Client Behaviors 426 When a client receives a 350 response from a URN resolver, it should attempt 427 to continue the resolution process by parsing the list of URI-hint bindings, 428 and choose a URI and a resolution hint to use in a follow up request. If the 429 protocol specified in the resolution hint indicates WIRE, then the followup 430 request should request the selected URI and should include the hint in the 431 Resolution-Hint request header. The client may use the type field to 432 indicate which type or service it is attempting to use. If a protocol other 433 than WIRE is specified in the hint, the client must follow the specification 434 of that protocol. 436 2.3.3 Proxy Behaviors 438 Proxy resolvers can forward resolution requests with remote resolution hints 439 to the remote resolver specified in the hint. When a resolver running in 440 proxy mode receives a resolution request with a remote resolution hint, it 441 should construct a resolution request using the request URI and the value of 442 the Resolution-Hint header. That is, the location of the resolver to forward 443 the request to should be the location specified by the hint. Furthermore, 444 the Resolution-Hint header should also be forwarded to the remote resolver. 446 If a proxy resolver receives a URN resolution request without a hint, and 447 the resolver cannot find an appropriate hint in its cache, it may reject the 448 request, or it may attempt to discover a resolution hint by starting the 449 resolution process from the root NID registry. 451 3 Examples 453 In this section we describe a few scenarios of URN resolution. In all these 454 scenarios, we will try to resolve the name 455 urn:cid:9802032044@thebe.lcs.mit.edu. 457 3.1 Trivial Example - No Cache 459 A client (C) would like to resolve the URN by making the following 460 resolution request to a local URN resolver (R). Note, C does not send the 461 Optional header, therefore R must assume C is not WIRE compliant. 463 GET urn:cid:9802032044@thebe.lcs.mit.edu HTTP/1.0 465 The local URN resolver is not the authoritative resolver, and did not 466 receive a hint. Therefore it attempts to discover an authoritative resolver, 467 first using NAPTR. A series of NAPTR lookups is performed by the resolver. 468 At some point, the resolver receives a "p" record from NAPTR, and the record 469 contains the resolution hint "http://urn.mit.edu;scope=urn:cid:mit:" The 470 resolver then makes the following connection to urn.mit.edu 472 GET urn:cid:9802032044@thebe.lcs.mit.edu HTTP/1.0 473 Host: urn.mit.edu 474 Resolution-Hint: res-hint:http://urn.mit.edu;scope=urn:cid:mit: 475 Optional: "urn:specs:WIRE/0.0" 477 urn.mit.edu returns back a 350 delegation response: 479 HTTP/1.0 350 Resolution Delegated 480 Resolver-Location: "";"res-hint:http://thebe.lcs.mit.edu/;scope=urn:cid:mit.lcs.thebe:" 481 Expires: Fri, 13 Mar 1998 17:00:00 GMT 483 The resolver R parses the Resolver-Location header, and makes a subsequent 484 request to thebe.lcs.mit.edu 486 GET urn:cid:9802032044@thebe.lcs.mit.edu HTTP/1.0 487 Host: thebe.lcs.mit.edu 488 Resolution-Hint: res-hint:http://thebe.lcs.mit.edu;scope=urn:cid:mit:lcs:thebe: 489 Optional: "urn:specs:WIRE/0.0" 491 It turns out that thebe.lcs.mit.edu is the authoritative resolver, and 492 returns a 200 response. 494 HTTP/1.0 200 OK 496 498 The resolver R returns this response to the original client C. 500 3.2 Effects of Caching 502 Now that a request for that particular URN has been fulfilled, it is in the 503 cache of the resolver R. Let's assume that the resolver R does not cache the 504 final resolved entity, but it does remember the last 350 delegation and its 505 expiration time. The next time a request from C to R for the same URN can be 506 fulfilled by directly applying the 350 delegation response from cache. That 507 is, the resolver R can directly contact the authoritative server at 508 thebe.lcs.mit.edu, skipping the NAPTR lookups and the first WIRE lookup. Of 509 course, any resolvers in the resolution sequence in section 3.1 can maintain 510 their own caches. 512 3.3 Variation on a protocol 514 The resolver at thebe.lcs.mit.edu decides that HTTP is not secure enough, 515 and it would like to use POP+Kerberos to perform resolution on its part of 516 the cid namespace. In this case, the resolver at urn.mit.edu would have 517 responded with 519 HTTP/1.0 350 Resolution Delegated 520 Resolver-Location: "";"res-hint:pop://thebe.lcs.mit.edu/;scope=urn:cid:mit.lcs.thebe:;\ 521 auth-method=kerberos/5" 522 Expires: Fri, 13 Mar 1998 17:00:00 GMT 524 If resolver R understands both POP and can perform KERBEROS authentication 525 for the client, the resolver may perform a pop request and return the client 526 C the resolved data. If the local resolver R does not understand POP, or if 527 it cannot perform kerberos authentication for the client, it would have to 528 return a 400 response to the client, and with an entity explaining the 529 situation. 531 This example demonstrates that WIRE allows flexible switching of resolution 532 protocols. 534 3.4 How WIRE interacts with NAPTR 536 Most of existing URN resolvers use the NAPTR ([8]) protocol. To reduce 537 complexity, we assume any WIRE compliant client that wishes to resolve URNs 538 also understands NAPTR. That is, it is up to the client to perform NAPTR 539 lookups when necessary, and keep any internal state information necessary 540 for NAPTR lookups. 542 A NAPTR record can point to a WIRE resolver by returning a record that looks 543 like 545 ;; order pref flags service regexp replacement 546 IN NAPTR 100 10 "p" "WIRE+N2R" "" http://urn.mit.edu;scope=urn:cid:mit: 548 To switching back to NAPTR, we can use a resolution hint that looks like 550 res-hint:NAPTR://z3950.gatech.edu 552 4 Caching 554 URN resolution using WIRE has a great need for caching 350 responses because 555 of the number of delegations each URN resolution process may involve. URN 556 resolution using WIRE should follow the same cache semantics as defined for 557 WIRE ([11]). 559 It is an unfortunate consequence of the flexibility of URN delegation that 560 it is presently impossible to specify a generalized form for wildcards that 561 can describe delegated subsets of URN space. URN delegation generally does 562 not occur along a single model of hierarchy, for a variety of reasons 563 including the need to grandfather existing persistent namespaces and the 564 need to permit delegation structures to evolve and fragment over time. 566 For example, within a single namespace different portions of the syntax can 567 exhibit different directions of hierarchy. In the following diagram, 568 consider one possible grandfathered namespace incorporating content-IDs. 569 (The notation L.R means left-to-right hierarchy delimited by '.', while R@L 570 means right-to-left hierarchy delimited by '@'.) 572 urn:cid:9802030121.AA21353@thebe.lcs.mit.edu 573 <-L:R--------------------------------------> 574 <-R@L------------------------------> 575 <-L.R------------> <-R.L-----------> 577 This means that, with the exception of circumstances where the cache agent 578 understands the delegation structures involved, it is not possible to cache 579 information about spaces of URNs. 581 5 Security Considerations 583 WIRE security considerations are discussed in [11]. 585 6 Acknowledgments 587 The requirements for URN resolution that this protocol intends to address 588 have been discussed and developed in meetings of the IETF URN Working Group, 589 as well as in separate conversations among its many members. The emphasis on 590 extensibility and delegation via metadata in 350 redirects is an 591 implementation of RDS switching ideas that are described in the URN 592 architecture document, RFC 2276 [10]. This in turn has its roots in the 593 "Knoxville Compromise" which defined a basic architecture for URN 594 resolution. 596 A great deal of the design of this protocol and the accompanying participant 597 behaviors is inherited directly from the NAPTR algorithm and record format. 598 The design of the metadata response format includes similar notions of 599 preference and order; the service request header copies the syntax for 600 specifying services in NAPTR. Following the example of NAPTR, this protocol 601 treats URN resolution as a discovery process, emphasizing that throughout 602 the discovery process some portion of a URN is opaque and does not have a 603 strict syntax imposed from above. 605 Henrik Frystk Nielson provided invaluable feedback and comments on an 606 original version of this document. Discuss with Henrik on the concept of 607 resolution and the generic URI resolution model led to the current versions 608 of this document and the WIRE specification. 610 Last but not the least, Karen Sollins and Dorothy Curtis have provided many 611 insightful ideas and feedback on the general URN resolution architecture and 612 on this document. 614 7. Authors Addresses 616 Lewis Girod 617 Benjie Chen 618 MIT Laboratory for Computer Science 619 545 Technology Square 620 Cambridge, MA 02139, USA 621 Email: {girod,benjie}@lcs.mit.edu 623 John Mallery 624 MIT Artificial Intelligence Laboratory 625 545 Technology Square 626 Cambridge, MA 02139, USA 627 Email: jcma@ai.mit.edu 629 References 631 1. RFC 1630 "Uniform Resource Identifiers in WWW", T. Berners-Lee, June 632 1994 633 2. RFC 1737 "Functional Requirements for Uniform Resource Names" K. 634 Sollins, L. Masinter, December, 1994. 635 3. RFC 1738 "Uniform Resource Locators", T. Berners-Lee, L. Masinter, M. 636 McCahill, December 1994 637 4. RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, R. 638 Fielding, H. Frystyk, May, 1996 639 5. RFC 2068 "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. 640 Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, January 1997 641 6. RFC 2119 "Key words for use in RFCs to Indicate Requirement Levels", S. 642 Bradner, March 1997 643 7. RFC 2141 "URN Syntax", R. Moats. May 1997 644 8. RFC 2168 "Resolution of Uniform Resource Identifiers using the Domain 645 Name System", R. Daniel, M. Mealling, June 1997 646 9. RFC 2169 "A Trivial Convention for using HTTP in URN Resolution", R. 647 Daniel, June 1997 648 10. RFC 2276 "Architectural Principles of Uniform Resource Name 649 Resolution", K. Sollins, September, 1997 650 11. Internet Draft draft-girod-w3-id-res-ext-00 "WIRE: W3 Identifier 651 Resolution Extensions", L. Girod, B. Chen, H. Frystyk, J. Mallery, 652 March 1998 (work in progress) 653 12. Internet Draft draft-ietf-urn-resolution-services-05 "URI Resolution 654 Services Necessary for URN Resolution" M. Mealling, March, 1998 (work 655 in progress)