idnits 2.17.1 draft-ietf-urn-resolution-services-01.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 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 1 longer page, the longest (page 1) being 504 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 104 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([3]), 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 95: '...this set of operations MUST contain at...' RFC 2119 keyword, line 221: '...type, the result MUST be a list of the...' RFC 2119 keyword, line 271: '...ntified by the URN, it MAY be returned...' RFC 2119 keyword, line 435: '...on-comment lines MUST be URIs (URNs or...' RFC 2119 keyword, line 441: '...f the URIs given MUST be preserved upo...' 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '6' is mentioned on line 436, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-urn-naptr-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-urn-naptr (ref. '1') ** Obsolete normative reference: RFC 2141 (ref. '2') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 1630 (ref. '3') ** Obsolete normative reference: RFC 1521 (ref. '4') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) Summary: 15 errors (**), 0 flaws (~~), 3 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 June 1997 Ron Daniel Jr. 4 Intended category: Standards Track Los Alamos National Laboratory 5 draft-ietf-urn-resolution-services-01.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 18 months and may be updated, replaced, or obsoleted by other documents 19 at 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 23 the 1id-abstracts.txt listing contained in the Internet-Drafts 24 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 Abstract 29 Fetching the resource identified by a Uniform Resource Identifier (URI) [3] 30 is only one of the operations that can be performed on a URI. We might ask 31 for a list of other identifiers that are aliases for the original URI, a 32 bibliographic description of the resource the URI denotes, etc. Because of 33 the diverse nature of resources on the network, it may be difficult (or 34 impossible) to offer all those operations, therefore a means of indicating 35 what services are and are not supported by a given resolver must be 36 specified. This memo gives an initial set of those operations, and the 37 requirements that must be met when those operations are encoded in a 38 protocol. 40 1. Introduction 42 In the course of formulating current proposals [1] regarding Uniform 43 Resource Names [2] it became apparent that requiring servers to deal with 44 all desired functions or requiring clients to deal with complicated 45 information returned by a server was unrealistic and a barrier to adoption. 46 There needed to be some way for a client to be able to pick between a server 47 that specialized in the complex and another that specialized in the simple 48 (but fast). Also, in subsequent conversations it became obvious that, in 49 most cases, some of the operations were inappropriate or difficult for 50 certain identifiers. For example, ISSNs identify books or magazines that are 51 serial in nature. An operation to return the resource for an ISSN pointing 52 to "Time" magazine would result in dumping hundreds of thousands of pages of 53 "Time" onto a user's machine. This does not seem like a reasonable thing to 54 do in the normal case. 56 The Problem 58 The problem, stated simply, is one of a client needing to convey to a 59 service the desired operation that the client wishes to have done on a given 60 URI. The converse of this problem was that the server needed some way to 61 convey to a client which services a network entity supported. 63 This problem requires some well understood set of identifiers that identify 64 those operations. But it was also realized that an exhaustive set would both 65 be impossible and not very necessary. Thus, this document will list several 66 operations as well as lay out requirments for specifying new operations. 68 Historical Note: Since these services originated with the discussions 69 surrounding URN resolution, there needs to be a clarification about at which 70 point in the resoulution process these services reside. The URN resolution 71 framework [] uses a two step process. The first step is called a Resolution 72 Discovery Services or RDS. The second part is called a local resolver. The 73 RDS uses hints to point a client toward a local resolver which actually 74 answers the questions about the URI. The services described here reside at 75 the level of the local resolver. The identifiers are used in the RDS to 76 specify which local resolvers handle which services. 78 Also, previous versions of this document referred to services where the 79 arguments were specific types of URIs such as URNs or URLs. These services 80 were called "N2L", "L2L", etc. Their use has been deprecated here in favor 81 of the more general URI form. 83 Design Criteria 85 The design criteria used to meet these requirements were fairly simple. The 86 need to simply identify the operation with some token and know its operands, 87 algorithm and errors was seen as sufficient to meet the requirements. 89 2. General Specification 91 In order to provide a framework both for the specifications in this document 92 and for new ones to be written by others, the following requirments are 93 placed on any documents that seek to specify new operations. 95 Any specification of a member of this set of operations MUST contain at 96 least the following pieces of information with respect to its operands, its 97 algorithm, output and errors. 99 2.1 Operands 101 Must contain the following pieces of information: 103 * name of the operation 104 * mnemonic for the operation 105 * number of operands 106 * type of each operand 107 * format of each operand 109 2.2 Algorithm 111 Must either specify the exact algorithm for the operation or that the 112 algorithm is opaque and defined by the server. 114 2.3 Output 116 Must specify one of the following: 118 * there is no output 119 * the output is undefined 120 * the output itself and its content 121 * the fact that the output is an object and the object's type and format. 123 2.4 Error Conditions 125 Must include all errors that are considered applicable across all 126 implementations and application environments. Errors that depend on the 127 system conveying the service are not included. Thus, many of the expected 128 errors such as syntax errors or service availability are not included in 129 this document since they are implementation dependent. 131 2.5 Security Considerations 133 Must specify any security considerations relating to the serivce provided. 134 This does NOT include considerations dealing with the protocol used to 135 convey the service or to those that normally accompany the results of the 136 service. For example, an I2L service would need to discuss the situation 137 where someone maliciously inserts an incorrect URL into the resolver but NOT 138 the case where someone sends personal information across the Internet to the 139 resource identified by the correct URL. 141 3. Encoding The Operations 143 To be useful these operations have to be used within some system or 144 protocol. In many cases these systems and protocols will place restrictions 145 on which operations make sense and how those that do are syntactically 146 represented. 148 Also, a given system or protocol will have its own output formats that will 149 restrict the output formats of a given operation. Additionally, a given 150 protocol may have better solution for output than the ones given here. For 151 example, the I2L result may be encoded in a protocol specific manner that 152 causes the client to treat it as special. 154 Thus, the requirements on encoding these operations within a given system 155 are the following: 157 * which subset of the operations are allowed 158 * how the operator is encoded 159 * how the operands are encoded 160 * how the error codes are returned 162 For those system that can use it, MIME [4] is the suggested output format. 163 The operations listed here use the text/uri-list Internet Media Type or IMT 164 [4] that is specified in Appendix A. Other system are strongly encouraged to 165 use this IMT. In the case where a system does not use an IMT a justification 166 should be given. 168 4. The Incomplete Set 170 4.1 I2L (URI to URL) 172 * name: URI to URL 173 * mnemonic: I2L 174 * number of operands: 1 175 * type of each operand: 1st operand is a URI 176 * format of each operand: 1st operand is encoded as a URI 177 * algorithm: opaque 178 * output: 1 and only one URL encoded in a text/uri-list 179 * Errors Conditions: 180 o No such URI 181 o No URL to return 182 * Security Considerations: 184 o Malicious Redirection 185 One of the fundamental dangers related to any service such as this 186 is that a malicious entry in a resolver's database will cause 187 clients to resolve the URI into the wrong URL. The intent may be 188 to cause the client to retrieve a resource possibly containing 189 fradulent or damaging material. 190 o Denial of Service 191 By removing the URL that the URI maps to, a malicious intruder may 192 remove the clients ability to retrieve the resource. 194 This operation is used to map a single URI to a single URL. It is used by 195 light weight clients that do not have the ability to select from a list of 196 URLs or understand a Uniform Resource Characteristic (URC). The algorithm 197 for this mapping is dependent on the URI scheme. 199 4.2 I2Ls (URI to URLs) 201 * name: URI to URLs 202 * mnemonic: I2LS 203 * number of operands: 1 204 * type of each operand: 1st operand is a URI 205 * format of each operand: 1st operand is encoded as a URI 206 * algorithm: opaque 207 * output: a list of 0 or more URLs encoded in a text/uri-list 208 * Errors: 209 o No such URI 210 o No URLs to return 211 * Security Considerations: 213 o Malicious Redirection (see I2L) 214 o Denial of Service (see I2L) 216 This operation is used to map a single URI to 0 or more URLs. It is used by 217 a client that can pick from a list of URLs based on some criteria that is 218 important to the client. The client should not make any assumptions about 219 the order of the URLs returned. 221 No matter what the particular media type, the result MUST be a list of the 222 URLs that may be used to obtain an instance of the resource identified by 223 the URI. All URIs shall be encoded according to the URI specification [6]. 225 4.3 I2R (URI to Resource) 227 * name: URI to Resource 228 * mnemonic: I2R 229 * number of operands: 1 230 * type of each operand: 1st operand is a URI 231 * format of each operand: 1st operand is encoded as a URI 232 * algorithm: opaque 233 * output: an instance of the resource named by the URI. Encoding is not 234 specified. 235 * Errors: 236 o No such URI. 237 o No resource available. 238 * Security Considerations: 240 o Malicious Redirection (see I2L) 241 o Denial of Service (see I2L) 243 This operation is used to return a single instance of the resource that is 244 named by the URI. The format of the output is dependent on the resource 245 itself. 247 4.4 I2Rs (URI to Resources) 249 * name: URI to Resources 250 * mnemonic: I2Rs 251 * number of operands: 1 252 * type of each operand: 1st operand is a URI 253 * format of each operand: 1st operand is encoded as a URI 254 * algorithm: opaque 255 * output: 0 or more instances of the resource named by the URI. Encoding 256 is not specified. 257 * Errors: 258 o No such URI. 259 o No resource available. 260 * Security Considerations: 262 o Malicious Redirection (see I2L) 263 o Denial of Service (see I2L) 265 This operation is used to return multiple instances of a resource, for 266 example, GIF and JPEG versions of an image. The judgment about the resources 267 being "the same" resides with the naming authority that issued the URI. 269 The output shall be a MIME multipart/alternative [4] message with the 270 alternative versions of the resource in separate body parts. If there is 271 only one version of the resource identified by the URN, it MAY be returned 272 without the multipart/alternative wrapper. 274 4.5 I2C (URI to URC) 276 * name: URI to URC 277 * mnemonic: I2C 278 * number of operands: 1 279 * type of each operand: 1st operand is a URI 280 * format of each operand: 1st operand is encoded as a URI 281 * algorithm: opaque 282 * output: A Uniform Resource Characteristic. Encoding is not specified. 283 * Errors: 284 o No such URI. 285 o URC not available. 286 * Security Considerations: 288 o Malicious Redirection (see I2L) 289 o Denial of Service (see I2L) 291 URCs (Uniform Resource Characteristics) are descriptions of other resources. 292 This request allows the client to obtain a description of the resource 293 identified by a URI, as opposed to the resource itself or simply the 294 resources URLs. The description might be a bibliographic citation, a digital 295 signature, a revision history, etc. This draft does not specify the content 296 of any response to a URC request. That content is expected to vary from one 297 server to another. 299 4.6 I2CS (URI to URCs) 301 * name: URI to URCs 302 * mnemonic: I2CS 303 * number of operands: 1 304 * type of each operand: 1st operand is a URI 305 * format of each operand: 1st operand is encoded as a URI 306 * algorithm: opaque 307 * output: 0 or more Uniform Resource Characteristic. Encoding is not 308 specified. 309 * Errors: 310 o No such URI. 311 o URCs not available. 312 * Security Considerations: 314 o Malicious Redirection (see I2L) 315 o Denial of Service (see I2L) 317 URCs can come in different formats and types. This operation returns 0 or 318 more URCs that are appropriate for the given URI. 320 4.7 I2N (URI to URN) 322 * name: URI to URN 323 * mnemonic: I2N 324 * number of operands: 1 325 * type of each operand: 1st operand is a URN 326 * format of each operand: 1st operand is encoded as a URI 327 * algorithm: opaque 328 * output: One URN encoded in a text/uri-list IMT. 329 * Errors: 330 o No such URI. 331 o No URN considered equivalent at this time. 332 * Security Considerations: 334 o Malicious Redirection (see I2L) 335 o Denial of Service (see I2L) 337 While URNs are supposed to identify one and only one resource, that does not 338 mean that a resource may have one and only one URN. For example, consider a 339 resource that one organization wishes to name 'foo'. Another organization, 340 in agreement with the first, wants to call the resource 'bar'. Both 341 organizations can agree that both names 'name' the same resource and that 342 the URNs 'foo' and 'bar' are equivalent. 344 The result a URN, known to the server, which identifies the same resource as 345 the input URN. The result shall be encoded in a text/uri-list IMT. 347 Extreme care should be taken with this service as it toys with the idea of 348 equality with respect to URNs. As mentioned in several URN documents the 349 idea of equality is very domain specific. For example, a URN pointing to a 350 weather map for a particular day and a URN pointing to the the map as it 351 changes from day to day would NOT by returned in this example because they 352 point to do different resources. Some other concept of equality is at work. 353 This service instead deals with resources that have two different names 354 where the binding between the names and resources is permanent. 356 4.8 I2Ns (URI to URNs) 358 * name: URI to URNs 359 * mnemonic: I2NS 360 * number of operands: 1 361 * type of each operand: 1st operand is a URI 362 * format of each operand: 1st operand is encoded as a URI 363 * algorithm: opaque 364 * output: A list of URNs encoded in a text/uri-list IMT. 365 * Errors: 366 o No such URI. 367 o No URNs considered equivalent at this time. 368 * Security Considerations: 370 o Malicious Redirection (see I2L) 371 o Denial of Service (see I2L) 373 This operation simply returns 0 or more URNs following the same criteria and 374 cautions as the I2N operation. 376 4.9 I2I (URI to URI): 378 * name: URI to URI 379 * mnemonic: I2I 380 * number of operands: 1 381 * type of each operand: 1st operand is a URL 382 * format of each operand: 1st operand is encoded as a URI 383 * algorithm: opaque 384 * output: A URI. 385 * Errors: 386 o No such URI. 387 o No URIs considered equivalent at this time. 388 * Security Considerations: 390 o Malicious Redirection (see I2L) 391 o Denial of Service (see I2L) 393 This operation is used to map any arbitrary URI to any other arbitrary URI. 394 No other assertions are made about whether or not the URI exhibits 395 characteristics of URNs or URLs. 397 4.10 I=I (Is URI equal to URI): 399 * name: URI = URI 400 * mnemonic: I=I 401 * number of operands: 2 402 * type of each operand: Both operands are URIs 403 * format of each operand: both operands are encoded as a URIs 404 * algorithm: opaque 405 * output: TRUE or FALSE 406 * Errors: 407 o No such URI. 408 o No URIs considered equivalent at this time. 409 * Security Considerations: 411 o Malicious Redirection (see I2L) 412 o Denial of Service (see I2L) 414 This operation is used to determine whether two given URIs are considered to 415 be equal by the server being asked the question. The algorithm used to 416 determine equality is opaque. No assertions are made about whether or not 417 the URIs exhibits characteristics of URNs or URLs. 419 6. The text/uri-list Internet Media Type 421 [This section will be augmented or replaced by the registration of 422 the text/uri-list IMT once that registration has been performed]. 424 Several of the resolution service requests, such as I2Ls, I2Ns, result in a 425 list of URIs being returned to the client. The text/uri-list Internet Media 426 Type is defined to provide a simple format for the automatic processing of 427 such lists of URIs. 429 The format of text/uri-list resources is: 431 1. Any lines beginning with the '#' character are comment lines and are 432 ignored during processing. (Note that '#' is a character that may 433 appear in URIs, so it only denotes a comment when it is the first 434 character on a line). 435 2. The remaining non-comment lines MUST be URIs (URNs or URLs), encoded 436 according to the URI specification RFC[6]. Each URI shall appear on one 437 and only one line. 438 3. As for all text/* formats, lines are terminated with a CR LF pair, 439 although clients should be liberal in accepting lines with only one of 440 those characters. 441 4. The order of the URIs given MUST be preserved upon retransmission. The 442 client should not make any inferences about what the order of the 443 returned list means. 445 In applications where one URI has been mapped to a list of URIs, such as in 446 response to the I2Ls request, the first line of the text/uri-list response 447 SHOULD be a comment giving the original URI. 449 An example of such a result for the I2L request is shown below in figure 1. 450 -------------------------------------------------- 452 # urn:cid:foo@huh.org 453 http://www.huh.org/cid/foo.html 454 http://www.huh.org/cid/foo.pdf 455 ftp://ftp.foo.org/cid/foo.txt 457 Figure 1: Example of the text/uri-list format 458 -------------------------------------------------- 460 7. References 462 [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource 463 Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt, 464 February, 1997. 466 [2] R. Moats, "URN Syntax", RFC2141, Jan. 1997. 468 [3] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for 469 the Expression of Names and Addresses of Objects on the Network as 470 used in the World-Wide Web", T. Berners-Lee, June 1994. 472 [4] RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One: 473 Mechanisms for Specifying and Describing the Format of Internet Message 474 Bodies", Borenstein, N. and and N. Freed, Bellcore, Innosoft, 475 September 1993. 477 8. Security Considerations 479 Communications with a server may be of a sensitive nature. Some servers will 480 hold information that should only be released to authorized users. The 481 results from servers may be the target of spoofing, especially once 482 electronic commerce transactions are common and there is money to be made by 483 directing users to pirate repositories rather than repositories which pay 484 royalties to rights-holders. Server requests may be of interest to traffic 485 analysts. The requests may also be subject to spoofing. 487 9. Author Contact Information 489 Michael Mealling 490 Network Solutions 491 505 Huntmar Park Drive 492 Herndon, VA 22070 493 voice: (703)742-0400 494 fax: (703)742-9552 495 email: michaelm@rwhois.net 497 Ron Daniel 498 Advanced Computing Lab, MS B287 499 Los Alamos National Laboratory 500 Los Alamos, NM, USA, 87545 501 voice: +1 505 665 0597 502 fax: +1 505 665 4939 503 email: rdaniel@lanl.gov