idnits 2.17.1 draft-girod-w3-id-res-ext-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-28) 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 501 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 164 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([4], [5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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? '4' on line 275 looks like a reference -- Missing reference section? '5' on line 275 looks like a reference -- Missing reference section? '6' on line 148 looks like a reference -- Missing reference section? '1' on line 148 looks like a reference -- Missing reference section? '10' on line 184 looks like a reference -- Missing reference section? '8' on line 437 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 8 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-w3-id-res-ext-00.txt Henrik Frystyk 6 World Wide Web Consortium 7 John Mallery 8 MIT Artificial Intelligence Laboratory 10 WIRE - W3 Identifier Resolution Extensions 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working documents of 15 the Internet Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months and 20 may be updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet- Drafts as reference material or to cite them 22 other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au 27 (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West 28 Coast). 30 Note: This is a very rough draft suitable only for experimental 31 implementations. It is expected to change in the near future. 33 Abstract 35 WIRE extends HTTP with a new type of redirect response that permits a 36 resolver to explicitly delegate a resolution to other resolvers and 37 protocols. WIRE is an effort to make delegation more explicit, redirection 38 more flexible, and resolution processes more efficient through the use of 39 hints. This document defines WIRE and describes the expected behaviors of 40 resolvers and clients using WIRE. WIRE is an extension of the HyperText 41 Transfer Protocol (HTTP), and is intended to be compatible with HTTP/1.0 and 42 above [4][5]. 44 WIRE encourages use of long-lived URIs and at the same time supports 45 protocol evolution without having to change currently deployed URIs or URI 46 schemes. The extension is based on a simple URI resolution model that allows 47 an application to dynamically request metadata describing where and how to 48 access a resource. The model can use any generic metadata description 49 language (e.g. RDF) and as the metadata itself is interpreted as a first 50 class resource, metadata resources are no different than any other resource 51 on the Web. 53 1 Introduction 55 1.1 Terminology 57 A resolver is an application that translates a URI into another URI or in 58 case it is the authoritative resolver, directly to the requested resource. 60 A resolution process is the sequenced set of operations performed by a set 61 of one or more resolvers is a nested set of operations that eventually will 62 result in an entity being generated and returned to the requestor. 64 1.2 Resolution Model 66 URI resolution models have been a perennial source of confusion. In this 67 section we present a new, clearer resolution model. 69 The WIRE model of URI resolution is fairly simple: to resolve a URI, ask the 70 right server to resolve it, supplying any appropriate arguments or hints. 71 The following diagram and discussion shows how this works for the "GET" 72 method (other methods apply the same resolution process, differing only in 73 the processing at the origin server): 75 _____________________ 76 GET | | Standard 77 URI[?argument] --->| Right Resolver? | Yes ---> HTTP 78 [hint: "hint"] |_____________________| Response 79 ^ | No | Error 80 | | | 81 | v v 82 +------- 350 Redirect 400 Bad Request 84 If the location of the "right" resolver is unknown, the client sends a 85 request to a favored or local resolver, optionally including a hint. This 86 resolver will do some amount of work on the client's behalf, and will either 87 return one of the following responses: 89 * A standard HTTP response, indicating that the resolver is authoritative 90 for that URI and that resolution is complete 91 * A 350 redirect indicating that the resolution process is not done yet 92 * A 400 response, indicating that a failure occurred in the resolution 93 infrastructure, and no further authoritative data can be obtained 95 A 200 response returns a view of the URI, or in the case of a query 96 containing an argument, a view resulting from a method call on the resource 97 identified by the URI. A 350 response returns hint information intended to 98 help the client continue the resolution process. The hint information might 99 describe resolvers that can further resolve the URI in question, or it might 100 list alternate URIs that also resolve to the resource named by the original 101 URI. 103 To understand this model it is important to have a broader understanding of 104 URI resolution. First, completion of resolution is largely in the eye of the 105 beholder; the data one client resolves might be interpreted by another 106 client as metadata that can be used to continue resolving the URI. In one 107 sense a 350 redirect from an initial attempt at resolution is a view of the 108 URI; in another sense it is simply metadata containing a hint for continued 109 resolution at another site. When thinking about URI resolution it is 110 important to keep this contextual information in mind. Second, the final 111 step of resolution is performed by the resource itself, although in current 112 implementations this activity is coordinated by the "server" process. 114 A very important semantic difference between the 350 response and other HTTP 115 responses has to do with the trust model for a 350 response. Unlike other 116 HTTP responses, the content of metadata contained within a 350 response is 117 the responsibility of the resolver that serves it, and is not in any way 118 linked to the origin server for the resource it describes. If the resolvers 119 are not trusted there is no guarantee that the metadata is accurate. The 120 efforts to specify signed RDF metadata should provide methods for correcting 121 these deficiencies in the future. 123 1.3 Problems this model does NOT solve 125 Resolution using WIRE does not guarantee that a resolution process converges 126 to a resolved resource. It does not guarantee that the resource returned is 127 the correct or authoritative resource. It does not guarantee that a resolver 128 understands every URI, nor that the authoritative resolver for any given URI 129 exists or can be located. It does not guarantee that URIs are maintained in 130 a persistent fashion or that URIs consistently resolve to resources that are 131 conceptually equivalent. WIRE is designed to enable the construction of 132 resolution systems that can provide some or all of these guarantees over 133 specific namespaces. 135 1.4 Guide to this Document 137 This document is organized as follows: Section 2 describes the syntax of 138 WIRE; Section 3 describes the semantics and behaviors of resolver, clients 139 and proxies; Section 4 gives a short example; Section 5 discusses the merit 140 of caching; and Section 6 discusses security issues. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 ([6]). In grammar 145 definitions, this document uses the same parsing constructs as RFC 1630[1], 146 RFC 2068 ([5]). In particular, the non-terminals uri is defined in 147 [1][4][5]. 149 2 Syntax of Extended Headers and Responses 151 This section introduces the headers and the response code defined by WIRE. 152 This specification attempts to define minimal syntactical requirements for 153 WIRE conformance. 155 2.1 Hints 157 URI resolution can be streamlined through the use of resolution hints. 158 Resolution hints are encoded as URIs. Apart from the URI encoding rules, the 159 syntax and semantics of resolution hints is specific to the resolution 160 system indicated by the hint. For the purpose of caching and loop avoidance, 161 two hints are lexically equivalent if they are octet-by-octet equal after 162 applying URI normalization rules. 164 Resolution hints are intended to be processed by both clients and resolvers 165 during the resolution process. To the client, hints convey resolver 166 locations and supported protocols and type models. To the resolver indicated 167 by the hint, hints convey client preferences and tokens important to the 168 resolution process. For example, it is essential that URN resolvers receive 169 a hint that includes a token describing a starting point for resolution. 170 This allows the resolver to skip delegation steps that would otherwise be 171 necessary to obtain the hint. 173 2.2 Extended Request Headers 175 2.2.1 Optional Header 177 The Optional request-header allows a client to declare itself to support 178 WIRE. This header is optional. The presence of this header indicates that 179 the resolver may return WIRE specific responses to the client. In the 180 absence of this header the resolver must assume the client is not WIRE 181 compliant. In this case the resolver may complete the resolution of the URI 182 if it can do so without sending back WIRE specific responses, or it may 183 reject the request with a 400 response code. Proxy behaviors are discussed 184 in more detail in section 3.3. See [10] for a description of the use of the 185 Optional header. 187 The Optional header has the following grammar: 189 Optional-Header = "Optional" ":" WIRE-specification-URN 190 WIRE-specification-URN = "urn:specs:WIRE/0.0" 192 2.2.2 Resolution-Hint header 194 The Resolution-Hint request-header can be used by a client to supply a 195 resolution hint to the resolver. It has the following grammar: 197 Resolution-Hint-Header = "Resolution-Hint" ":" hint 198 hint = quoted-absolute-uri 199 quoted-absolute-uri = "\"" absolute-uri "\"" 201 The Resolution-Hint header is optional. If this header is absent from a 202 request, the resolver may either attempt to resolve the URI without a hint 203 (in many cases this may slow down the resolution process) or reject the 204 request with a 400 response code. 206 2.3 Extended Response Code - 350 208 In order to support distribution of resolution authority, WIRE includes the 209 350 response, a new response code intended to express delegation and 210 redirection in the resolution framework. To delegate or redirect the 211 resolution of a URI, a WIRE resolver may return one or more alternate URIs, 212 each bound to zero or more resolution hints. The Resolver-Location header in 213 a 350 response encodes this comma delimited set of bindings. Within each 214 binding, the list of hints is delimited by semicolons. The Resolver-Location 215 header has the following grammar: 217 Resolver-Location-Header = "Resolver-Location" ":" binding *("," binding) 218 binding = alternate-uri *(";" hint) 219 alternate-uri = "\"\"" | quoted-relative-uri | quoted-absolute-uri 220 hint = quoted-absolute-uri 221 quoted-relative-uri = "\"" relative-uri "\"" 223 As shown above, the alternate URI specified in the binding may appear as an 224 absolute URI or in two other forms. If the binding applies to the original 225 request-URI, the empty string ("") may be used instead of repeating the 226 original request-URI. If a binding applies to a URI that can be expressed 227 relative to the original request-URI, a relative URI may be quoted in place 228 of an absolute URI. 230 A 350 response code may also include an entity containing additional 231 metadata relevant to the request-URI. Note that the data in the 232 Resolver-Location header and the optional entity in a 350 response follows 233 the amended trust model described in section 1. 235 3 Semantics and Behavior of WIRE 237 3.1 Resolver Behaviors and Response Semantics 239 When a resolver receives a resolution request on a URI, the resolver should 240 attempt to resolve the URI, making use of any supplied hint information. If 241 the resolver is able to resolve the request-URI, the resolver processes the 242 request as would a normal HTTP server. 244 If the resolver fails to make progress towards the resolution of the URI, a 245 4xx error code may be returned. The 404 error code should only be returned 246 if the resolver has authority over the request-URI and that URI is not bound 247 to a resource. Other 4xx codes indicate a temporary or permanent failure in 248 the resolution infrastructure. 250 If the resolver makes progress towards resolution of the request-URI, a 350 251 response may be used to redirect resolution to alternate URIs or to delegate 252 the resolution of the URI to alternate resolvers. Redirection and delegation 253 information is conveyed via the Resolver-Location header defined in section 254 2.3. The client may then attempt to use supplied hints to resolve any of the 255 alternate URIs listed in the header. The encoding and semantics of the hints 256 is defined by individual resolution frameworks. 258 The hints supplied in a 350 response can specify a collection of alternate 259 protocols or resolution systems. New types of hints, referring to new or 260 location-specific protocols, can be phased in along with more standard hints 261 as fallback options. This can add scalability and flexibility to the 262 resolution framework by providing information about alternate resolution 263 mechanisms to clients that are aware of those alternate mechanisms. 265 A resolver may receive both standard HTTP requests and requests from 266 WIRE-aware clients. Clients indicate awareness of WIRE by including an 267 Optional request header with the URI of the WIRE specification. A 268 WIRE-compliant resolver that receives a request without an appropriate 269 Optional header may either reject the request with a 400 response code or 270 proxy the resolution of the URI on behalf of the client. In the latter case, 271 the resolver acts as a delegation proxy (section 3.3). 273 For caching purposes, a 350 response should also include information on the 274 life-time of delegation/redirection responses. This information can be 275 encoded in one of the HTTP caching headers ([4][5]). 277 3.2 Client Behaviors 279 When a client makes a resolution request to a resolver, the resolver cannot 280 guarantee that the URI can be resolved. If the URI is within the authority 281 of another resolver, a 350 response may be returned to the client. To 282 continue the resolution process, the client should: 284 1. Parse the Resolver-Location header in the 350 response. 285 2. Select one of the alternate URIs, and select one of the resolvers 286 specified by the hints bound to that URI. 287 3. Initiate a new request to the specified resolver, using the protocol 288 and address information specified in the hint. 289 4. Request the selected URI, optionally including any appropriate hint 290 information in the Resolution-Hint request header. Some resolvers 291 require that the hint be forwarded while others do not. 293 Whenever new resolution hints are returned to a client, there is the 294 possibility of a "delegation loop", in which a new hint is lexically 295 equivalent to a hint previously applied in the resolution of the same 296 request-URI. A "redirection loop" can occur if an alternate URI is lexically 297 equivalent to a previous URI in a sequence of redirections. To detect 298 delegation loops, a client should keep for each request-URI a history of 299 resolution hints previously applied, and should lexically compare new 300 resolution hints to the history. Detection of redirection loops should 301 already be performed by web clients. 303 These methods do not guarantee the detection of delegation or redirection 304 loops. Malicious resolvers can cause delegation loops by returning 305 resolution hints that are semantically equivalent to a prior hint but are 306 not lexically equivalent to any previous hint. Loop detection is only 307 guaranteed to work for resolvers that recognize only a small set of distinct 308 resolution hints. 310 Clients that wish to receive 350 responses must include the Optional header 311 with the URN of the WIRE specification in each resolution request. Older 312 clients and clients that do not want to receive delegation responses may 313 omit the Optional header. 315 3.3 Proxying WIRE Functionalities 317 WIRE extends the normal HTTP proxy behavior and additionally defines a new 318 behavior called a delegation proxy. In both of these cases normal HTTP proxy 319 semantics should be followed in addition to the WIRE specific semantics. 321 3.3.1 HTTP/WIRE Proxy Behavior 323 A WIRE resolver used as a proxy may proxy non-local resolution requests 324 based on local policy decisions. If performing the resolution is contrary to 325 policy, an appropriate error response should be returned. Otherwise, it 326 should attempt to resolve the URI with or without a resolution hint, and the 327 results of that effort to the client. If new resolution hint is supplied, 328 the resolver should attempt to resolve the URI based on the text of the URI 329 and global information. If the resolution hint supplied indicates a remote 330 resolver, the proxy should initiate a request to that resolver. 332 3.3.2 Delegation Proxy Behavior 334 If the requesting client is not WIRE compliant, it cannot parse a 350 335 delegation/redirection response. In this case, a delegation proxy may choose 336 to perform the entire resolution process on behalf of the client and pass 337 the result of the resolution back to the original client. A delegation proxy 338 should follow the guidelines for a WIRE client when performing the 339 resolution. The first result entity that conforms to standard HTTP should be 340 returned to the client. 342 A client requests delegation proxy behavior by omitting the Optional request 343 header indicating WIRE. If a resolver's policy prohibits this behavior, or 344 if at any time the resolver decides to abort the resolution, a 400 response 345 should be returned to the client. 347 4 Example 349 A client wishes to resolve the URI urn:cid:9802032044@thebe.lcs.mit.edu. It 350 sends a resolution request to http://urn.org/ 352 GET urn:cid:9802032044@thebe.lcs.mit.edu HTTP/1.0 353 Host: urn.org 354 Optional: "urn:specs:WIRE/0.0" 356 The resolver at urn.org determines that the URI can be resolved using 357 another resolver, and sends back 359 HTTP/1.0 350 Resolution Delegated 360 Resolver-Location: "";"res-hint:http://thebe.lcs.mit.edu/;scope=urn:cid:" 362 To continue the resolution process, the client makes another resolution 363 request, this time to http://thebe.lcs.mit.edu/ 365 GET urn:cid:9802032044@thebe.lcs.mit.edu HTTP/1.0 366 Host: thebe.lcs.mit.edu 367 Optional: "urn:specs:WIRE/0.0" 368 Resolution-Hint: "res-hint:http://thebe.lcs.mit.edu/;scope=urn:cid:" 370 The resolver at thebe.lcs.mit.edu is the authoritative resolver for the URI. 371 It returns the resolution result 373 HTTP/1.0 200 OK 374 376 378 5 Caching 380 The exact behaviors of URI resolution differ from resolution framework to 381 resolution framework. For example, ignoring DNS lookups, URL resolutions are 382 usually a one step process, whereas URN resolutions may take a few 383 delegations to complete. We hope to realize significant performance gains 384 for URI resolution frameworks that require more than one delegations through 385 the caching of 350 responses. To cache a 350 response, both the request URI 386 and the value of the Resolution-Hint header that was used in the request 387 must be included in the key that maps to the cached entity. Standard HTTP 388 headers that restrict or control caching must be heeded. 390 The need for caching 350 responses stems from the delegation nature of some 391 URI resolution frameworks. Since the discovery process required to refresh a 392 cached non-350 HTTP response may be significant, caching the 350 responses 393 preceding the non-350 HTTP response may result in significant performance 394 improvements, depending on cache expiration times. 396 One optimization when caching 350 responses might retain only the response 397 that has resulted from the longest sequence of delegations, that is, 398 discarding intermediate 350 responses. Applying this optimization, 399 subsequent requests for the same URI may skip directly to the most specific 400 delegation. If this optimization is applied, the most restrictive caching 401 requirements for any response in the sequence must be applied to the most 402 specific sequence. 404 A similar optimization would be to cache all the intermediate 350 responses, 405 and for each subsequent request, re-use a non-expired delegation response 406 with the longest sequence of delegations. Applying this optimization, most 407 subsequent requests can skip many delegation steps. 409 6 Security Considerations 411 WIRE inherits the HTTP security model at the transport level. That 412 does not, however, imply the safety and authenticity of the resolution 413 metadata or resolved data. One possible approach to guarantee safety 414 and authenticity is to include signed metadata. Those problems 415 require further study and are beyond the scope of this document. 417 Possible conflicts between the HTTP trust model and the 350 response raise 418 security concerns, as mentioned in section 1. In short, 350 responses 419 without security extensions are responses from untrusted resolvers. Measures 420 such as loop-avoidance should be applied to detect and prevent 421 denial-of-service attacks. 423 Implementations of WIRE should follow the security restrictions of the 424 environment the resolver operates in. For example, Resolvers on firewalls 425 operating under both single-step and delegation proxy behaviors may be 426 required to filter out resolution requests from outside the firewall that 427 intend to use an internal resource. Such requests, in most cases, are not 428 allowed. However it is quite essential that such proxying resolvers forward 429 resolution requests from internal clients to the outside world, unless an 430 organization intend to mirror resolution services over all URI namespaces 431 internally. 433 7 Acknowledgments 435 The motivation leading to this work stemmed from a few directions. John 436 Mallery's experience with implementing the PDI namespace for URNs indicated 437 that the THTTP ([8]) spec did not adequately cover error messages and 438 redirection. Discussions with John Mallery and Henrik Frystyk Nielsen led to 439 the initial formulation of this protocol specification, in an effort to 440 rework THTTP into an official HTTP extension. Henrik Frystyk Nielsen also 441 provided invaluable ideas and feedback on modifying the original design to 442 fit into the generic ideas of URI resolution. 444 Karen Sollins and Dorothy Curtis have also provided many insightful ideas 445 and feedback on the general resolution architecture and on this document. 447 8. Authors Addresses 449 Lewis Girod 450 Benjie Chen 451 MIT Laboratory for Computer Science 452 545 Technology Square 453 Cambridge, MA 02139, USA 454 Email: {girod,benjie}@lcs.mit.edu 456 Henrik Frystyk Nielsen 457 Technical Staff, World Wide Web Consortium 458 MIT Laboratory for Computer Science 459 545 Technology Square 460 Cambridge, MA 02139, USA 461 Email: frystyk@w3.org 463 John Mallery 464 MIT Artificial Intelligence Laboratory 465 545 Technology Square 466 Cambridge, MA 02139, USA 467 Email: jcma@ai.mit.edu 469 References 471 1. RFC 1630 "Uniform Resource Identifiers in WWW", T. Berners-Lee, June 472 1994 473 2. RFC 1737 "Functional Requirements for Uniform Resource Names" K. 474 Sollins, L. Masinter, December, 1994. 475 3. RFC 1738 "Uniform Resource Locators", T. Berners-Lee, L. Masinter, M. 476 McCahill, December 1994 477 4. RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, R. 478 Fielding, H. Frystyk, May, 1996 479 5. RFC 2068 "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. 480 Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, January 1997 481 6. RFC 2119 "Key words for use in RFCs to Indicate Requirement Levels", S. 482 Bradner, March 1997 483 7. RFC 2168 "Resolution of Uniform Resource Identifiers using the Domain 484 Name System", R. Daniel, M. Mealling, June 1997 485 8. RFC 2169 "A Trivial Convention for using HTTP in URN Resolution", R. 486 Daniel, June 1997 487 9. RFC 2276 "Architectural Principles of Uniform Resource Name 488 Resolution", K. Sollins, September, 1997 489 10. Internet Draft draft-ietf-http-ext-mandatory-00.txt "Mandatory 490 Extensions in HTTP", H. Frystyk Nielsen, P. Leach, S. Lawrence, March 491 1998.