idnits 2.17.1 draft-ietf-urn-resolution-services-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-27) 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. ** Expected the document's filename to be given on the first page, but didn't find any == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 419 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 91 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. ** 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 87: '...this set of operations MUST contain at...' RFC 2119 keyword, line 169: '...type, the result MUST be a list of the...' RFC 2119 keyword, line 205: '...ntified by the URN, it MAY be returned...' RFC 2119 keyword, line 348: '...on-comment lines MUST be URIs (URNs or...' RFC 2119 keyword, line 354: '...f the URIs given MUST be preserved upo...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- 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 349, 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') == Outdated reference: A later version (-05) exists of draft-ietf-urn-syntax-02 ** 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: 16 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 1997 Ron Daniel Jr. 4 Intended category: Standards Track Los Alamos National Laboratory 6 URN Resolution Services 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 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 documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as work in progress. 20 To learn the current status of any Internet-Draft, please check 21 the 1id-abstracts.txt listing contained in the Internet-Drafts 22 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 Abstract 27 Fetching the resource identified by a Uniform Resource Identifier (URI) [3] 28 is only one of the operations that can be performed on a URI. We might ask 29 for a list of other identifiers that are aliases for the original URI, a 30 bibliographic description of the resource the URI denotes, etc. Because of 31 the diverse nature of resources on the network, it may be difficult (or 32 impossible) to offer all those operations, therefore a means of indicating 33 what services are and are not supported by a given resolver must be 34 specified. This memo gives an initial set of those operations, and the 35 requirements that must be met when those operations are encoded in a 36 protocol. 38 1. Introduction 40 In the course of formulating current proposals [1] regarding Uniform 41 Resource Names [2] it became apparent that requiring servers to deal with 42 all desired functions or requiring clients to deal with complicated 43 information returned by a server was unrealistic and a barrier to adoption. 44 There needed to be some way for a client to be able to pick between a server 45 that specialized in the complex and another that specialized in the simple 46 (but fast). Also, in subsequent conversations it became obvious that, in 47 most cases, some of the operations were inappropriate or difficult for 48 certain identifiers. For example, ISSNs identify books or magazines that are 49 serial in nature. An operation to return the resource for an ISSN pointing 50 to "Time" magazine would result in dumping hundreds of thousands of pages of 51 "Time" onto a user's machine. This does not seem like a reasonable thing to 52 do in the normal case. 54 The Problem 56 The problem, stated simply, was one of a client needing to convey to a 57 service some idea of the desired operation on a URI that the client is 58 currently talking about. The problem was also that the server needed to 59 convey to a client which network entity could perform which of the 60 operations that were allowed for that particular URI. 62 This problem requires we specify some well understood set of identifiers 63 that could identify the operation that a particular network entity either 64 desired or could perform. But it was also realized that an exhaustive set 65 would both be impossible and not very necessary. Thus, while this document 66 will list several operations, it will also lay out the requirments for 67 specifying new operations. 69 Design Criteria 71 The design criteria used to meet these requirements were fairly simple. The 72 need to simply identify the operation with some token and know its operands 73 and algorithm was seen as sufficient to meet the requirements. Thus, as with 74 most things simple the simple set of design criteria ended up being: simple, 75 extensible, generic and short. 77 As with most design requirements there are several that are at cross 78 purposes. Thus for anyone adding to this list these design criteria should 79 be kept in mind and balanced against each other. 81 2. General Specification 83 In order to provide a framework both for the specifications in this document 84 and for new ones to be written by others the following requirments are 85 placed on any documents that seek to specify new operations. 87 Any specification of a member of this set of operations MUST contain at 88 least the following pieces of information with respect to its operands, its 89 algorithm and its output. 91 * 2.1 Operands 93 Must contain the following pieces of information: 94 o name of the operation 95 o mnemonic for the operation 96 o number of operands 97 o type of each operand 98 o format of each operand 100 * 2.2 Algorithm Must either specify the exact algorithm for the operation 101 or must specify that the algorithm is opaque and defined by the server. 103 * 2.3 Output Must either specify one of the following: 104 o there is no output 105 o the output is undefined 106 o the output itself and its content 107 o the fact that the output is an object and that objects type and 108 format. 110 3. Encoding The Operations 112 To be useful these operations have to be used within some system or 113 protocol. In many cases these systems and protocols will place restrictions 114 on which operations make sense and how those that do are syntactically 115 represented. 117 Also, a given system or protocol will have its own output formats that will 118 restrict the output formats of a given operation. Additionally, a given 119 protocol may have better solution for output than the ones given here. For 120 example, the N2L result may be encoded in a protocol specific manner that 121 causes the client to treat it as special. 123 Thus, the requirements on encoding these operations within a given system 124 are the following: 126 * which subset of the operations are allowed 127 * how the operator is encoded 128 * how the operands are encoded 129 * what the output format is 131 For those system that can use it, MIME [4] is the suggested output format. 132 The operations listed here use the text/uri-list Internet Media Type or IMT 133 [4] that is specified in Appendix A. Other system are strongly encouraged to 134 use this IMT. In the case where a system does not use an IMT a justification 135 should be given. 137 4. The Incomplete Set 139 4.1 N2L (URN to URL) 141 * name: URN to URL 142 * mnemonic: N2L 143 * number of operands: 1 144 * type of each operand: 1st operand is a URN 145 * format of each operand: 1st operand is encoded as a URI 146 * algorithm: opaque 147 * output: 1 and only one URL encoded in a text/uri-list 149 This operation is used to map a single URN to a single URL. It is used by 150 light weight clients that do not have the ability to select from a list of 151 URLs or understand a Uniform Resource Characteristic (URC). The algorithm 152 for this mapping is dependent on the URN namespace. 154 4.2 N2Ls (URN to URLs) 156 * name: URN to URLs 157 * mnemonic: N2LS 158 * number of operands: 1 159 * type of each operand: 1st operand is a URN 160 * format of each operand: 1st operand is encoded as a URI 161 * algorithm: opaque 162 * output: a list of 0 or more URLs encoded in a text/uri-list 164 This operation is used to map a single URN to 0 or more URLs. It is used by 165 a client that can pick from a list of URLs based on some criteria that is 166 important to the client. The client should not make any assumptions about 167 the order of the URLs returned. 169 No matter what the particular media type, the result MUST be a list of the 170 URLs that may be used to obtain an instance of the resource identified by 171 the URN. All URIs shall be encoded according to the URI specification [6]. 173 4.3 N2R (URN to Resource) 175 * name: URN to Resource 176 * mnemonic: N2R 177 * number of operands: 1 178 * type of each operand: 1st operand is a URN 179 * format of each operand: 1st operand is encoded as a URI 180 * algorithm: opaque 181 * output: an instance of the resource named by the URN. Encoding is not 182 specified. 184 This operation is used to return a single instance of the resource that is 185 named by the URN. The format of the output is dependent on the resource 186 itself. 188 4.4 N2Rs (URN to Resources) 190 * name: URN to Resources 191 * mnemonic: N2Rs 192 * number of operands: 1 193 * type of each operand: 1st operand is a URN 194 * format of each operand: 1st operand is encoded as a URI 195 * algorithm: opaque 196 * output: 0 or more instances of the resource named by the URN. Encoding 197 is not specified. 199 This operation is used to return multiple instances of a resource, for 200 example, GIF and JPEG versions of an image. The judgment about the resources 201 being "the same" resides with the naming authority that issued the URN. 203 The output shall be a MIME multipart/alternative [4] message with the 204 alternative versions of the resource in separate body parts. If there is 205 only one version of the resource identified by the URN, it MAY be returned 206 without the multipart/alternative wrapper. 208 4.5 N2C (URN to URC) 210 * name: URN to URC 211 * mnemonic: N2C 212 * number of operands: 1 213 * type of each operand: 1st operand is a URN 214 * format of each operand: 1st operand is encoded as a URI 215 * algorithm: opaque 216 * output: A Uniform Resource Characteristic. Encoding is not specified. 218 URCs (Uniform Resource Characteristics) are descriptions of other resources. 219 This request allows the client to obtain a description of the resource 220 identified by a URN, as opposed to the resource itself or simply the 221 resources URLs. The description might be a bibliographic citation, a digital 222 signature, a revision history, etc. This draft does not specify the content 223 of any response to a URC request. That content is expected to vary from one 224 server to another. 226 4.6 N2Ns (URN to URNs) 228 * name: URN to URNs 229 * mnemonic: N2Ns 230 * number of operands: 1 231 * type of each operand: 1st operand is a URN 232 * format of each operand: 1st operand is encoded as a URI 233 * algorithm: opaque 234 * output: A list of URNs encoded in a text/uri-list IMT. 236 While URNs are supposed to identify one and only one resource, that does not 237 mean that a resource may have one and only one URN. For example, consider a 238 resource that has something like "current-weather-map" for one URN and 239 "weather-map-for-datetime-x" for another URN. The N2Ns service request lets 240 the client obtain lists of URNs that are believed equivalent at the time of 241 the request. As the weathermap example shows, some of the equivalences will 242 be transitory, so the the server should convey the length of time for which 243 the mapping is valid. The result is a list of all the URNs, known to the 244 server, which identify the same resource as the input URN. The result shall 245 be encoded in a text/uri-list IMT. 247 4.7 L2Ns (URL to URNs) 249 * name: URN to URNs 250 * mnemonic: N2Ns 251 * number of operands: 1 252 * type of each operand: 1st operand is a URN 253 * format of each operand: 1st operand is encoded as a URI 254 * algorithm: opaque 255 * output: A list of URNs encoded in a text/uri-list IMT. 257 This operation is used to discover the URN associated with a particular URL. 258 As with all operations dealing with URNs how that URN is mapped is 259 completely dependent on the rules specified by the namespace. 261 4.8 L2Ls (URL to URLs) 263 * name: URL to URLs 264 * mnemonic: L2Ls 265 * number of operands: 1 266 * type of each operand: 1st operand is a URL 267 * format of each operand: 1st operand is encoded as a URI 268 * algorithm: opaque 269 * output: A list of URLs encoded in a text/uri-list IMT. 271 This operation is used to discover URLs that are considered equal to each 272 other. As with the N2N operation "equality" is defined by the server and is 273 opaque to the client. 275 4.9 L2C (URL to URC): 277 * name: URL to URC 278 * mnemonic: L2C 279 * number of operands: 1 280 * type of each operand: 1st operand is a URL 281 * format of each operand: 1st operand is encoded as a URI 282 * algorithm: opaque 283 * output: A URC. 285 This operation is used to retrieve the URC for a given URL. As with most 286 other URI mappings the mapping function is opaque. As with any other 287 operation that returns a URC, the output format is unspecified. 289 4.10 I2I (URI to URI): 291 * name: URI to URI 292 * mnemonic: I2I 293 * number of operands: 1 294 * type of each operand: 1st operand is a URL 295 * format of each operand: 1st operand is encoded as a URI 296 * algorithm: opaque 297 * output: A URI. 299 This operation is used to map any arbitrary URI to any other arbitrary URI. 300 No other assertions are made about whether or not the URI exhibits 301 characteristics of URNs or URLs. 303 4.11 N2I (URI to URI): 305 * name: URN to URI 306 * mnemonic: N2I 307 * number of operands: 1 308 * type of each operand: 1st operand is a URL 309 * format of each operand: 1st operand is encoded as a URI 310 * algorithm: opaque 311 * output: A URI. 313 This operation is used to map a URN to any other arbitary URI. No other 314 assertions are made about whether or not the URI exhibits characteristics of 315 URNs or URLs. 317 4.11 I=I (Is URI equal to URI): 319 * name: URI = URI 320 * mnemonic: I=I 321 * number of operands: 2 322 * type of each operand: Both operands are URIs 323 * format of each operand: both operands are encoded as a URIs 324 * algorithm: opaque 325 * output: TRUE or FALSE 327 This operation is used to determine whether two given URIs are considered to 328 be equal by the server being asked the question. The algorithm used to 329 determine equality is opaque. No assertions are made about whether or not 330 the URIs exhibits characteristics of URNs or URLs. 332 6. The text/uri-list Internet Media Type 334 [This section will be augmented or replaced by the registration of 335 the text/uri-list IMT once that registration has been performed]. 337 Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, L2Ls, 338 result in a list of URIs being returned to the client. The text/uri-list 339 Internet Media Type is defined to provide a simple format for the automatic 340 processing of such lists of URIs. 342 The format of text/uri-list resources is: 344 1. Any lines beginning with the '#' character are comment lines and are 345 ignored during processing. (Note that '#' is a character that may 346 appear in URIs, so it only denotes a comment when it is the first 347 character on a line). 348 2. The remaining non-comment lines MUST be URIs (URNs or URLs), encoded 349 according to the URI specification RFC[6]. Each URI shall appear on one 350 and only one line. 351 3. As for all text/* formats, lines are terminated with a CR LF pair, 352 although clients should be liberal in accepting lines with only one of 353 those characters. 354 4. The order of the URIs given MUST be preserved upon retransmission. The 355 client should not make any inferences about what the order of the 356 returned list means. 358 In applications where one URI has been mapped to a list of URIs, such as in 359 response to the N2Ls request, the first line of the text/uri-list response 360 SHOULD be a comment giving the original URI. 362 An example of such a result for the N2L request is shown below in figure 1. 363 -------------------------------------------------- 365 # urn:cid:foo@huh.org 366 http://www.huh.org/cid/foo.html 367 http://www.huh.org/cid/foo.pdf 368 ftp://ftp.foo.org/cid/foo.txt 370 Figure 1: Example of the text/uri-list format 371 -------------------------------------------------- 373 7. References 375 [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource 376 Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt, 377 February, 1997. 379 [2] R. Moats, "URN Syntax", draft-ietf-urn-syntax-02, Jan. 1997. 381 [3] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for 382 the Expression of Names and Addresses of Objects on the Network as 383 used in the World-Wide Web", T. Berners-Lee, June 1994. 385 [4] RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One: 386 Mechanisms for Specifying and Describing the Format of Internet Message 387 Bodies", Borenstein, N. and and N. Freed, Bellcore, Innosoft, 388 September 1993. 390 8. Security Considerations 392 Communications with a server may be of a sensitive nature. Some servers will 393 hold information that should only be released to authorized users. The 394 results from servers may be the target of spoofing, especially once 395 electronic commerce transactions are common and there is money to be made by 396 directing users to pirate repositories rather than repositories which pay 397 royalties to rights-holders. Server requests may be of interest to traffic 398 analysts. The requests may also be subject to spoofing. 400 9. Author Contact Information 402 Michael Mealling 403 Network Solutions 404 505 Huntmar Park Drive 405 Herndon, VA 22070 406 voice: (703)742-0400 407 fax: (703)742-9552 408 email: michaelm@rwhois.net 410 Ron Daniel 411 Advanced Computing Lab, MS B287 412 Los Alamos National Laboratory 413 Los Alamos, NM, USA, 87545 414 voice: +1 505 665 0597 415 fax: +1 505 665 4939 416 email: rdaniel@lanl.gov