idnits 2.17.1 draft-ietf-urn-http-conv-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-04-18) 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 Internet-Drafts being working documents. ** 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 421 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 an Authors' Addresses Section. ** There are 23 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** 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 101: '.... HTTP resolvers MUST return identical...' RFC 2119 keyword, line 128: '...s above. The URL MUST be returned in a...' RFC 2119 keyword, line 130: '... 30X status line SHOULD be returned. H...' RFC 2119 keyword, line 147: '... media type, the result MUST be a list...' RFC 2119 keyword, line 180: '...d by the URN, it MAY be returned witho...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 304 has weird spacing: '... to url resol...' -- 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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? '1' on line 347 looks like a reference -- Missing reference section? '2' on line 351 looks like a reference -- Missing reference section? '3' on line 354 looks like a reference -- Missing reference section? '4' on line 358 looks like a reference -- Missing reference section? '5' on line 360 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Ron Daniel 2 draft-ietf-urn-http-conv-00.txt Los Alamos National Laboratory 3 21 Nov, 1996 5 Conventions for the Use of HTTP for URN Resolution 7 Status of this Memo 8 =================== 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 This draft expires 21 May, 1997. 29 Abstract: 30 ========= 32 The URN-WG was formed to specify persistent, location-independent names 33 for network accessible resources, and resolution mechanisms to retrive 34 the resources given such a name. At this time the URN-WG is considering 35 one particular resolution mechanism, the NAPTR proposal [1]. That proposal 36 does not get the client software all the way from the URN to the resource. 37 Instead, it gets the client from a URN to a "resolver", which is a system 38 that can then tell the client where the resource is. The NAPTR draft 39 defines a "resolution protocol" to be the protocol used to speak to a 40 resolver in order to obtain the resource, its location(s), or other 41 information about the resource. The NAPTR proposal allows different 42 resolution protocols to be used for commuicating with resolvers. 44 This draft establishes conventions for encoding URN resolution requests 45 and responses in HTTP 1.0 (and 1.1) requests and responses. The primary 46 goal of this draft is to define a convention that is simple to implement 47 and will allow existing HTTP servers to easily add support for URN 48 resolution. We expect that the resolution databases that arise will be 49 useful when more sophisticated resolution protocols are developed later. 51 1.0 Introduction: 52 ================== 54 The NAPTR draft[1] describes a way of using DNS to locate resolvers for 55 URIs. That draft provides places to specify the "resolution protocol" 56 spoken by the resolver, as well as the "resolution services" it offers. 57 As of this writing, the "resolution protocols" allowed by the NAPTR draft 58 are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow over time). 59 The NAPTR draft also lists a variety of resolution services, such 60 as N2L (given a URN, return a URL); N2R (Given a URN, return the named 61 resource), etc. This draft specifies the conventions to follow to 62 encode resolution service requests in the HTTP protocol, allowing 63 widely available HTTP daemons to serve as URN resolvers. 65 The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3] 66 specifications. 68 2.0 General Approach: 69 ===================== 71 The general approach used to encode resolution service requests in HTTP 72 is quite simple: 74 GET /uri-res// HTTP/1.0 76 For example, if we have the URN "cid:foo@huh.com" and want a URL, 77 we would send the request: 79 GET /uri-res/N2L/cid:foo@huh.com HTTP/1.0 81 Because of the character set limitations on URIs, we might wish to 82 encode the '@' character as its hex equivalent, thus the request would be 84 GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 86 The request could also be encoded as an HTTP 1.1 request. This would look 87 like: 89 GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.1 90 Host: 92 Handling these requests on the server side is easy to implement in a 93 number of ways. The N2L request could be handled by a CGI script that 94 took the incoming URN, looked it up in a database, and returned the URL 95 as an HTTP redirect. Service requests like N2R or N2C could be set up 96 so that the daemon answered the request by returning files out of N2R/ 97 and N2C/ directories, or they could be handled by a script. 99 One caveat should be kept in mind. The "urn:" prefix is still the 100 subject of controversy, so some URN documents advocate treating it 101 as optional. HTTP resolvers MUST return identical results for URIs 102 that do and do not contain the "urn:" prefix. For example, the two 103 request below must return identical results: 104 GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 105 GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0 107 Responses from the HTTP server follow standard HTTP practice. Status 108 codes, such as 200 (OK) or 404 (Not Found) shall be returned. 109 The normal rules for determining cachability, negotiating formats, etc. 110 apply. 112 3.0 Service-specific details: 113 ============================= 115 This section goes through the various resolution services established 116 in the URN Framework draft [4] and states how to encode each of them, 117 how the results should be returned, and any special status codes that 118 are likely to arise. 120 Unless stated otherwise, the HTTP requests are formed according to 121 the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response 122 is assumed to be an entity with normal headers and body unless stated 123 otherwise. (N2L is the only request that does not return a body). 125 3.1 N2L (URN to URL): 126 ---------------------- 128 The request is encoded as above. The URL MUST be returned in a Location: 129 header for the convienience of the most common case of wanting the resource. 130 A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the 131 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) 132 status code unless the resolver has particular resons for using 301 133 (moved permanently) or 304 (not modified) codes. 135 3.2 N2Ls (URN to URLs): 136 ------------------------ 138 The request is encoded as above. The result is a list of 0 or 139 more URLs. The Internet Media Type (aka ContentType) of the result 140 may be negotiated using standard HTTP mechanisms if desired. At a 141 minimum the resolver should support the text/uri-list media type. 142 (See Appendix A for the definition of this media type). That media 143 type is suitable for machine-processing of the list of URLs. Resolvers 144 may also return the results as text/html, text/plain, or any other 145 media type they deem suitable. 147 No matter what the particular media type, the result MUST be a list 148 of the URLs which may be used to obtain an instance of the resource 149 identified by the URN. All URIs shall be encoded according to the 150 URI specification [5]. 152 If the client has requested the result be returned as text/html or 153 application/html, the result should be encoded as: 154 159 where the strings ...url n... are replaced by the n'th URL in the list. 161 3.3 N2R (URN to Resource): 162 --------------------------- 164 The request is encoded as above. The resource is returned using 165 standard HTTP mechanisms. The request may be modified using the 166 Accept: header as in normal HTTP to specify that the result 167 be given in a preferred Internet Media Types. 169 3.4 N2Rs (URN to Resources): 170 ----------------------------- 172 This resolution service returns multiple instances of a resource, 173 for example, GIF and JPEG versions of an image. The judgment about 174 the resources being "the same" resides with the naming authority that 175 issued the URN. 177 The request is encoded as above. The result shall be a MIME 178 multipart/alternative message with the alternative versions of the 179 resource in seperate body parts. If there is only one version of 180 the resource identified by the URN, it MAY be returned without the 181 multipart/alternative wrapper. Resolver software SHOULD look at the 182 Accept: header, if any, and only return versions of the resource 183 that are acceptable according to that header. 185 3.5 N2C (URN to URC): 186 ---------------------- 188 URCs (Uniform Resource Characteristics) are descriptions of other 189 resources. This request allows us to obtain a description of the 190 resource identified by a URN, as opposed to the resource itself. 191 The description might be a bibliographic citation, a digital signature, 192 a revision history, etc. This draft does not specify the content of 193 any response to a URC request. That content is expected to vary from 194 one resolver to another. 196 The format of any response to a N2C request MUST be communicated using the 197 ContentType header, as is standard HTTP practice. The Accept: header 198 SHOULD be honored. 200 3.6 N2Ns (URN to URNs): 201 ------------------------ 203 While URNs are supposed to identify one and only one resource, that 204 does not mean that a resource may have one and only one URN. For 205 example, consider a resource that has something like 206 "current-weather-map" for one URN and "weather-map-for-datetime-x" for 207 another URN. The N2Ns service request lets us obtain lists of URNs that 208 are believed equivalent at the time of the request. As the weathermap 209 example shows, some of the equivalances will be transitory, so the 210 standard HTTP mechanisms for communicating cachability MUST be honored. 212 The request is encoded as above. The result is a list of all the 213 URNs, known to the resolver, which identify the same resource as the 214 input URN. The result shall be encoded as for the N2Ls request 215 above (text/uri-list unless specified otherwise by an Accept: header). 217 3.7 L2Ns (URL to URNs): 218 ---------------------- 220 The request is encoded as above. The response is a list of any URNs 221 known to be assigned to the resource at the given URL. The result 222 shall be encoded as for the N2Ls and N2Ns requests. 224 3.8 L2Ls (URL to URLs): 225 ------------------------ 227 The request is encoded as described above. The result is a list of 228 all the URLs that the resolver knows are associated with the resource 229 located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns 230 requests. 232 3.9 L2C (URL to URC): 233 ---------------------- 235 The request is encoded as above, the response is the same as for the 236 N2C request. 238 Implementation Notes: 239 ===================== 241 This section gives an example of how to configure a web server to 242 respond to the N2L resolution request. It is not intended to specify 243 standard behavior, it is provided here merely as a courtesy for 244 implementors. 246 First, we assume the presence of a CGI script, n2l.pl, that processes 247 the provided URN, converting it into a canonical format. It would remove 248 any "urn:" prefix, decode any %encoded special characters, normalize 249 case-insensitive parts of the URN to lower case, etc. It would then use 250 the normalized URN as the key for a search in a database, which we assume 251 returns the URL as a string. A sample of our implementation of that script 252 is provided as Appendix B. We will further assume that the n2l.pl script 253 is in the cgi-bin directory of the web server. 255 The easiest way to invoke the n2l.pl script in response to N2L requests 256 is to set up a Redirect directive in the srm.conf file. (This works for 257 servers based on the original NCSA HTTP daemon, such as Apache.) The 258 relevant Redirect directives might look like: 260 Redirect /uri-res/N2L http://urn.acl.lanl.gov/cgi-bin/n2l.pl 261 Redirect /uri-res/L2N http://urn.acl.lanl.gov/cgi-bin/l2n.pl 263 Appendix A: The text/uri-list Internet Media Type 264 ================================================= 265 [This appendix will be augmented or replaced by the registration 266 of the text/uri-list IMT once that registration has been performed]. 268 Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, 269 L2Ls, result in a list of URIs being returned to the client. The 270 text/uri-list Internet Media Type is defined to provide a simple format 271 for the automatic processing of such lists of URIs. 273 The format of text/uri-list resources is: 274 1) Any lines beginning with the '#' character are comment lines 275 and are ignored during processing. (Note that '#' is a character 276 that may appear in URIs, so it only denotes a comment when it is the 277 first character on a line). 278 2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded 279 according to the URI specification RFC[5]. Each URI shall appear on 280 one and only one line. 281 3) As for all text/* formats, lines are terminated with a CR LF pair. 283 In applications where one URI has been mapped to a list of URIs, such 284 as in response to the N2Ls request, the first line of the text/uri-list 285 response SHOULD be a comment giving the original URI. 287 An example of such a result for the N2L request is shown below in figure 1. 289 # urn:cid:foo@huh.org 290 http://www.huh.org/cid/foo.html 291 http://www.huh.org/cid/foo.pdf 292 ftp://ftp.foo.org/cid/foo.txt 294 Figure 1: Example of the text/uri-list format 296 Appendix B: n2l.pl script 297 ========================== 299 This is a simple perl script for the N2L resolution service. It 300 assumes the presence of a DBM database to store the URN to URL 301 mappings. 303 #!/bin/perl 304 # N2L - performs urn to url resolution 306 $n2l_File = "...filename for DBM database..."; 308 $urn = $ENV{'PATH_INFO'} ; 309 if(length($urn)<3) 310 { 311 $error=1; 312 } 314 if(!$error) 315 { 316 $urn =~s/^(\/)(urn:)?(.*)/$3/i; 317 # Additional canonicalization should be performed here 319 dbmopen(%lu,$n2l_File,0444); 320 if($lu{$urn}) 321 { 322 $url=$lu{$urn}; 323 print STDOUT "Location: $url\n\n"; 324 }else{ 325 $error=2; 326 } 327 dbmclose(%lu); 328 } 330 if($error) 331 { 332 print "Content-Type: text/html \n\n"; 333 print "\n"; 334 print "URN Resolution: N2L\n"; 335 print "\n"; 336 print "

URN to URL resolution failed for the URN:

\n"; 337 print "

$urn

\n"; 338 print "\n"; 339 print "\n"; 340 } 342 exit; 344 References: 345 =========== 347 [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource 348 Identifiers using the Domain Name System", draft-ietf-urn-naptr-01.txt, 349 November, 1996. 351 [2] RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, 352 R. Fielding, H. Frystyk, May 1996. 354 [3] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, 355 "Hypertext Transfer Protocol -- HTTP/1.1", draft-ietf-http-v11-spec-06, 356 July 1996. 358 [4] URN Framework draft - 360 [5] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for 361 the Expression of Names and Addresses of Objects on the Network as 362 used in the World-Wide Web", T. Berners-Lee, June 1994. 364 Security Considerations 365 ======================= 366 Communications with a resolver may be of a sensitive nature. Some 367 resolvers will hold information that should only be released to 368 authorized users. The results from resolvers may be the target of 369 spoofing, especially once electronic commerce transactions are common 370 and ther is money to be made by directing users to pirate repositories 371 rather than repositories which pay royalties to rightsholders. Resolution 372 requests may be of interest to traffic analysts. The requests may also 373 be subject to spoofing. 375 The requests and responses in this draft are amenable to encoding, 376 signing, and authentication in the manner of any other HTTP traffic. 378 Author Contact Information: 379 =========================== 381 Ron Daniel 382 Los Alamos National Laboratory 383 MS B287 384 Los Alamos, NM, USA, 87545 385 voice: +1 505 665 0597 386 fax: +1 505 665 4939 387 email: rdaniel@lanl.gov 389 This draft expires 21 May, 1997. 390 Ron Daniel Jr. email: rdaniel@acl.lanl.gov 391 Advanced Computing Lab voice: (505) 665-0597 392 MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939 393 Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/ 394 Los Alamos, NM, 87545 obscure_term: "hypernym"