idnits 2.17.1 draft-ietf-urn-resolution-services-06.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-25) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 59 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 104: '...e use of words like MUST and SHALL are...' RFC 2119 keyword, line 306: '...resource identified by the URN, it MAY...' RFC 2119 keyword, line 402: '...namespaces MUST have agreed that the e...' RFC 2119 keyword, line 471: '...on-comment lines MUST be URIs (URNs or...' RFC 2119 keyword, line 477: '...f the URIs given MUST be preserved upo...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2168 (ref. '2') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 1521 (ref. '4') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Outdated reference: A later version (-03) exists of draft-ietf-urn-req-frame-02 ** Obsolete normative reference: RFC 1738 (ref. '7') (Obsoleted by RFC 4248, RFC 4266) Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 URN Working Group M.Mealling 2 INTERNET-DRAFT Network Solutions, Inc. 3 Expires six months from March 1998 Ron Daniel Jr. 4 Intended category: Experimental Los Alamos National Laboratory 5 draft-ietf-urn-resolution-services-06.txt 7 URI Resolution Services 8 Necessary for URN Resolution 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at 19 any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as work in progress. 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 Abstract 29 Retrieving the resource identified by a Uniform Resource Identifier 30 (URI) [1] is only one of the operations that can be performed on a URI. 31 One might also ask for and get a list of other identifiers that are 32 aliases for the original URI or a bibliographic description of the 33 resource the URI denotes, for example. This applies to both Uniform 34 Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform 35 Resource Characteristics (URCs) are discussed in this document but only 36 as descriptions of resources rather than identifiers. 38 A service in the network providing access to a resource may provide 39 one or some of these options, but it need not provide all of them. This 40 memo specifies an initial set of these operations that can be used to 41 describe the interactions provided by a given access service. It also 42 suggests guidelines that should be adhered to when those operations 43 are encoded in a protocol. 45 1. Introduction 47 In the course of formulating current proposals [2] regarding URNs 48 [3], it became apparent that requiring servers to manage all of the desired 49 functions or requiring clients to process varied information 50 returned by a server was unrealistic and a barrier to adoption. There 51 needed to be some way for a client to be able to identify a server 52 that specialized in the complex and another that specialized in the 53 simple (but fast). Also, in subsequent conversations it became obvious 54 that, in most cases, some of the operations were inappropriate or 55 difficult for certain identifiers. 57 The Problem 59 In the process of learning about a resource in the Internet, there 60 are a variety of possible functions that may be important and/or useful, 61 such as discovery of locators, names, descriptions, and accessing the 62 resource itself. A given service may support only a subset of these; 63 hence, it is important to describe such an access service by the types 64 of functions supported and the resources of which it has some knowledge. 65 For example, in the framework for an RDS described in [5] the 66 RDS itself may provide URLs [6][7], while the resolvers may provide 67 descriptions, URLs, or even the resources themselves. The design of an 68 RDS, as proposed in RFC 2168 [2], may be more generous and provide all 69 of the above. 71 This problem requires some well understood set of identifiers that 72 specify those operations. But an exhaustive set would both be 73 impossible and not very necessary. Thus, this document will list 74 several operations, as well as, lay out requirements for specifying new 75 operations. 77 The purpose of this document is to define a list of such functions 78 and short names for them and then use them in defining the interface to an 79 access service. Previous versions of this document referred to services 80 where the arguments were specific types of URIs such as URNs or URLs. 81 These services were called "N2L" and "L2L",for example. Their use has 82 been changed in favor of the more general URI form. 84 Design Criteria 86 To meet these requirements a fairly simple design criteria 87 was used. The need to identify the operation with some token such that its 88 operands, algorithm, and errors were known proved sufficient to meet these 89 requirements. 91 2. General Specification 93 To provide a framework both for the specifications in this document 94 and for future work to be written by others, the guidelines below are 95 suggested for documents that seek to specify new operations. Any specification 96 of a member of this set of operations should address these issues with respect 97 to its operands, algorithm, output, and errors. 99 Due to the small number of listed functions, a registration mechanism 100 was dismissed as premature. If this list grows, a registration mechanism 101 will probably be needed. 103 Also, due to the experimental nature of this document and the systems 104 that use its specifications, the use of words like MUST and SHALL are 105 limited. Where used they reflect a case where this specification could 106 cause harm to existing, non-experimental systems such as HTTP and URNs. 107 Thus, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119. 111 2.1 Operands 113 Operands must contain the following pieces of information: 115 * name of the operation 116 * case insensitive mnemonic for the operation 117 * number of operands 118 * type of each operand 119 * format of each operand 121 2.2 Algorithm 123 The exact algorithm for the operation must either be specified completely 124 or it must be considered opaque and defined by the server or application. 126 2.3 Output 128 Output must specify one of the following: 130 * there is no output 131 * the output is undefined 132 * the output itself and its content 133 * the fact that the output is an object and the object's 134 type and format 135 * any non-protocol specific errors 137 2.4 Error Conditions 139 All errors that are considered applicable across all implementations 140 and application environments must be included. Errors that depend on 141 the system conveying the service are not included. Thus, many of the 142 expected errors such as service availability or operation syntax are 143 not included in this document since they are implementation dependent. 145 2.5 Security Considerations 147 Any security considerations relating to the service provided must be 148 specified. This does NOT include considerations dealing with the 149 protocol used to convey the service or to those that normally accompany 150 the results of the service. For example, a service that returned a single 151 URL would need to discuss the situation where someone maliciously inserts 152 an incorrect URL into the resolver but NOT the case where someone sends 153 personal information across the Internet to the resource identified by the 154 correct URL. 156 3. Encoding The Operations 158 To be useful, these operations have to be used within some system or 159 protocol. In many cases, these systems and protocols will place 160 restrictions on which operations make sense and how those that do are 161 syntactically represented. It is sufficient for those protocols to 162 define new operations within their own protocol specification 163 documents but care should be taken to make this fact well known. 165 Also, a given system or protocol will have its own output specifications 166 that may restrict the output formats of a given operation. 167 Additionally, a given protocol may have better solution for output 168 than the ones given here. For example, the result of an operation that 169 converts a URI to more than one URL may be encoded in a protocol- 170 specific manner that conveys information about the closeness of each 171 resource on the network. 173 Thus, the requirements on encoding these operations within a given 174 system are as follows: 176 * which subset of the operations are allowed 177 * how the operator is encoded 178 * how the operands are encoded 179 * how the error codes are returned 181 The text/uri-list MIME Media Type is specified in Section 5. This Media Type 182 is merely a suggestion for experimental systems that need a simple 183 implementation. It is included here merely as an example to show 184 completeness (however simple it may be). 186 4. The Incomplete Set 188 4.1 I2L (URI to URL) 190 * Name: URI to URL 191 * Mnemonic: I2L 192 * Number of Operands: 1 193 * Type of Each Operand: First operand is a URI. 194 * Format of Each Operand: First operand is encoded as a URI. 195 * Algorithm: Opaque 196 * Output: One and only one URL 197 * Errors Conditions: 198 o Malformed URI 199 o URI is syntactically valid but does not exist in any form. 200 o URI exists but there is no available output from this 201 operation. 202 o URI existed in the past but nothing is currently known 203 about it. 204 o Access denied 206 * Security Considerations: 207 o Malicious Redirection 208 One of the fundamental dangers related to any service such as 209 this is that a malicious entry in a resolver's database will 210 cause clients to resolve the URI into the wrong URL. The 211 possible intent may be to cause the client to retrieve a 212 resource containing fraudulent or damaging material. 213 o Denial of Service 214 By removing the URL to which the URI maps, a malicious 215 intruder may remove the client's ability to retrieve the 216 resource. 218 This operation is used to map a single URI to a single URL. It is 219 used by lightweight clients that do not have the ability to select from 220 a list of URLs or understand a URC. The algorithm for this mapping is 221 dependent on the URI scheme. 223 4.2 I2Ls (URI to URLs) 225 * Name: URI to URLs 226 * Mnemonic: I2LS 227 * Number of Operands: 1 228 * Type of Each Operand: First operand is a URI. 229 * Format of Each Operand: First operand is encoded as a URI. 230 * Algorithm: Opaque 231 * Output: A list of zero or more URLs 232 * Errors: 233 o Malformed URI 234 o URI is syntactically valid but does not exist in any form. 235 o URI exists but there is no available output from this 236 operation. 237 o URI existed in the past but nothing is currently known 238 about it. 239 o Access denied 240 * Security Considerations: 241 o Malicious Redirection (see I2L) 242 o Denial of Service (see I2L) 244 This operation is used to map a single URI to 0 or more URLs. It is 245 used by a client that can pick from a list of URLs based on some 246 criteria that are important to the client. The client should not make 247 any assumptions about the order of the URLs returned. No matter what 248 the particular media type, the result should be a list of the URLs that 249 may be used to obtain an instance of the resource identified by the 250 URI. All URIs shall be encoded according to the URL [7] and URN [3] 251 specifications. 253 4.3 I2R (URI to Resource) 255 * Name: URI to Resource 256 * Mnemonic: I2R 257 * Number of Operands: 1 258 * Type of Each Operand: First operand is a URI. 259 * Format of Each Operand: First operand is encoded as a URI. 260 * Algorithm: Opaque 261 * Output: An instance of the resource named by the URI. 262 * Errors: 263 o Malformed URI 264 o URI is syntactically valid but does not exist in any form. 265 o URI exists but there is no available output from this 266 operation. 267 o URI existed in the past but nothing is currently known 268 about it. 269 o Access denied 270 * Security Considerations: 271 o Malicious Redirection (see I2L) 272 o Denial of Service (see I2L) 274 This operation is used to return a single instance of the resource 275 that is named by the URI. The format of the output is dependent on the 276 resource itself. 278 4.4 I2Rs (URI to Resources) 280 * Name: URI to Resources 281 * Mnemonic: I2Rs 282 * Number of Operands: 1 283 * Type of Each Operand: First operand is a URI. 284 * Format of Each Operand: First operand is encoded as a URI. 285 * Algorithm: Opaque 286 * Output: Zero or more instances of the resource named by the URI. 287 * Errors: 288 o Malformed URI 289 o URI is syntactically valid but does not exist in any form. 290 o URI exists but there is no available output from this 291 operation. 292 o URI existed in the past but nothing is currently known 293 about it. 294 o Access denied 295 * Security Considerations: 296 o Malicious Redirection (see I2L) 297 o Denial of Service (see I2L) 299 This operation is used to return multiple instances of a resource, 300 for example, GIF and JPEG versions of an image. The judgment about the 301 resources being "the same" resides with the naming authority that 302 issued the URI. 304 The output shall be a MIME multipart/alternative [4] message with 305 the alternative versions of the resource in separate body parts. If 306 there is only one version of the resource identified by the URN, it MAY 307 be returned without the multipart/alternative wrapper. 309 4.5 I2C (URI to URC) 311 * Name: URI to URC 312 * Mnemonic: I2C 313 * Number of Operands: 1 314 * Type of Each Operand: First operand is a URI. 315 * Format of Each Operand: First operand is encoded as a URI. 316 * Algorithm: Opaque 317 * Output: A URC 318 * Errors: 319 o Malformed URI 320 o URI is syntactically valid but does not exist in any form. 321 o URI exists but there is no available output from this 322 operation. 323 o URI existed in the past but nothing is currently known 324 about it. 325 o Access denied 326 * Security Considerations: 327 o Malicious Redirection (see I2L) 328 o Denial of Service (see I2L) 330 Uniform Resource Characteristics are descriptions of resources. This 331 request allows the client to obtain a description of the resource 332 identified by a URI, as opposed to the resource itself or simply the 333 resource's URLs. The description might be a bibliographic citation, a 334 digital signature, or a revision history. This draft does not specify 335 the content of any response to a URC request. That content is expected 336 to vary from one server to another. 338 4.6 I2CS (URI to URCs) 340 * Name: URI to URCs 341 * Mnemonic: I2CS 342 * Number of Operands: 1 343 * Type of Each Operand: First operand is a URI. 344 * Format of Each Operand: First operand is encoded as a URI. 345 * Algorithm: Opaque 346 * Output: Zero or more URCs 347 * Errors: 348 o Malformed URI 349 o URI is syntactically valid but does not exist in any form. 350 o URI exists but there is no available output from this 351 operation. 352 o URI existed in the past but nothing is currently known 353 about it. 354 o Access denied 355 * Security Considerations: 356 o Malicious Redirection (see I2L) 357 o Denial of Service (see I2L) 359 URCs can come in different formats and types. This operation returns 360 zero or more URCs that are appropriate for the given URI. 362 4.7 I2N (URI to URN) 364 * Name: URI to URN 365 * Mnemonic: I2N 366 * Number of Operands: 1 367 * Type of Each Operand: First operand is a URN. 368 * Format of Each Operand: First operand is encoded as a URI. 369 * Algorithm: Opaque 370 * Output: One and only one URN 371 * Errors: 372 o Malformed URI 373 o URI is syntactically valid but does not exist in any form. 374 o URI exists but there is no available output from this 375 operation. 376 o URI existed in the past but nothing is currently known 377 about it. 378 o Access denied 379 * Security Considerations: 380 o Malicious Redirection (see I2L) 381 o Denial of Service (see I2L) 383 While URNs are supposed to identify one and only one resource, that 384 does not mean that a resource may have one and only one URN. For 385 example, consider a resource that one organization wishes to name 386 'foo'; another organization, in agreement with the first, wants to call 387 the resource 'bar'. Both organizations can agree that both names 'name' 388 the same resource and that the URNs 'foo' and 'bar' are equivalent. 390 The result is a URN, known to the server, that identifies the same 391 resource as the input URN. 393 Extreme care should be taken with this service as it toys with the 394 idea of equality with respect to URNs. As mentioned in several URN 395 documents, the idea of equality is very domain specific. For example, 396 a URN pointing to a weather map for a particular day and a URN pointing 397 to the map as it changes from day to day would NOT be returned in this 398 example because they point to do different resources. Some other concept 399 of temporary equivalence is at work. This service instead deals with 400 resources that have two different names where there is a binding 401 between the names that is agreed by both name assigners. I.e., both 402 namespaces MUST have agreed that the each name can be used in place of 403 the other and the meaning does not change. 405 4.8 I2Ns (URI to URNs) 407 * Name: URI to URNs 408 * Mnemonic: I2NS 409 * Number of Operands: 1 410 * Type of Each Operand: First operand is a URI. 411 * Format of Each Operand: First operand is encoded as a URI. 412 * Algorithm: Opaque 413 * Output: A list of URNs 414 * Errors: 415 o Malformed URI 416 o URI is syntactically valid but does not exist in any form. 417 o URI exists but there is no available output from this 418 operation. 419 o URI existed in the past but nothing is currently known 420 about it. 421 o Access denied 422 * Security Considerations: 423 o Malicious Redirection (see I2L) 424 o Denial of Service (see I2L) 426 This operation simply returns zero or more URNs following the same 427 criteria and cautions as the I2N operation. 429 4.9 I=I (Is URI equal to URI): 431 * Name: URI = URI 432 * Mnemonic: I=I 433 * Number of Operands: 2 434 * Type of Each Operand: Both operands are URIs. 435 * Format of Each Operand: Both operands are encoded as a URIs. 436 * Algorithm: Opaque 437 * Output: TRUE or FALSE 438 * Errors: 439 o Malformed URIs 440 o URIs are syntactically valid but do not exist in any form. 441 o URIs exist but there is no available output from this 442 operation. 443 o URIs existed in the past but nothing is currently known 444 about them. 445 o Access denied 446 * Security Considerations: 447 o Malicious Redirection (see I2L) 448 o Denial of Service (see I2L) 450 This operation is used to determine whether two given URIs are 451 considered to be equal by the server being asked the question. The 452 algorithm used to determine equality is opaque. No assertions are made 453 about whether or not the URIs exhibits characteristics of URNs or URLs. 455 5. The text/uri-list Internet Media Type 457 [This section will be augmented or replaced by the registration of 458 the text/uri-list IMT once that registration has been performed]. 460 Several of the resolution service requests, such as I2Ls, I2Ns, 461 result in a list of URIs being returned to the client. The 462 text/uri-list Internet Media Type is defined to provide a simple format 463 for the automatic processing of such lists of URIs. 465 The format of text/uri-list resources is as follows. 467 1. Any lines beginning with the '#' character are comment lines and 468 are ignored during processing. (Note that '#' is a character that 469 may appear in URIs, so it only denotes a comment when it is the 470 first character on a line.) 471 2. The remaining non-comment lines MUST be URIs (URNs or URLs), 472 encoded according to the URN [3] or URL [7] specification RFCs. 473 Each URI shall appear on one and only one line. 474 3. As for all text/* formats, lines are terminated with a CR LF pair, 475 although clients should be liberal in accepting lines with only 476 one of those characters. 477 4. The order of the URIs given MUST be preserved upon retransmission. 478 The client should not make any inferences about what the order of 479 the returned list means. 481 In applications where one URI has been mapped to a list of URIs, 482 such as in response to the I2Ls request, the first line of the 483 text/uri-list response SHOULD be a comment giving the original URI. An 484 example of such a result for the I2L request is shown below in Figure 1. 486 ------------------------------------------ 488 # urn:cid:foo@huh.org 489 http://www.huh.org/cid/foo.html 490 http://www.huh.org/cid/foo.pdf 491 ftp://ftp.foo.org/cid/foo.txt 493 Figure 1: Example of the text/uri-list format 494 ------------------------------------------ 496 6. Security Considerations 498 Communications with a server may be of a sensitive nature. Some 499 servers will hold information that should only be released to 500 authorized users. The results from servers may be the target of 501 spoofing, especially once electronic commerce transactions are common 502 and there is money to be made by directing users to pirate repositories 503 rather than repositories that pay royalties to rights-holders. Server 504 requests may be of interest to traffic analysts. The requests may also 505 be subject to spoofing. 507 The "Access denied" error message assumes a system within which the 508 operation is being performed that can convey an authenticated concept 509 of access control. Thus, the "Access denied" message should only be 510 returned by systems that have an appropriate method of determining 511 access control. 513 7. References 515 [1] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying 516 Syntax for the Expression of Names and Addresses of Objects on the 517 Network as Used in the World-Wide Web", RFC 1630, June, 1994. 519 [2] Daniel, R., and Mealling, M., "Resolution of Uniform Resource 520 Identifiers using the Domain Name System", RFC2168, February, 1997. 522 [3] R. Moats, "URN Syntax", RFC2141, January, 1997. 524 [4] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail 525 Extensions) Part One: Mechanisms for Specifying and Describing the 526 Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, 527 September, 1993. 529 [5] Sollins, K., draft-ietf-urn-req-frame-02, "Guidelines and a 530 Framework for URN Resolution Systems", MIT/LCS, June, 1997. 531 [Note to RFC Editor: Please change this reference to point to the 532 correct RFC number for the draft] 534 [6] Kunze, J., "Functional Recommendations for Internet Resource 535 Locators", RFC1736, IS&T, UC Berkeley, February, 1995. 537 [7] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform 538 Resource Locators (URL)", RFC1738, December, 1994. 540 8. Author Contact Information 542 Michael Mealling Ron Daniel 543 Network Solutions Advanced Computing Lab, MS B287 544 505 Huntmar Park Drive Los Alamos National Laboratory 545 Herndon, VA 22070 Los Alamos, NM, USA, 87545 546 voice: (703) 742-0400 voice: (505) 665-0597 547 fax: (703) 742-9552 fax: (505) 665-4939 548 email: michaelm@rwhois.net email: rdaniel@lanl.gov 550 This document expires 6 months from March, 1998