idnits 2.17.1 draft-ietf-uri-irl-fun-req-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-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. ** 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 399 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 a Security Considerations 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 56 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. 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. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF URI Working Group John A. Kunze 2 Internet-Draft IS&T, UC Berkeley 3 27 July 1994 Expires in six months 5 Functional Requirements for Internet Resource Locators 6 8 1. Status of this Document 10 This document is an Internet-Draft. Internet-Drafts are working documents 11 of the Internet Engineering Task Force (IETF), its Areas, and its Working 12 Groups. Note that other groups may also distribute working documents as 13 Internet-Drafts. 15 Internet-Drafts are working documents valid for a maximum of six months. 16 Internet-Drafts may be updated, replaced, or obsoleted by other documents 17 at any time. It is not appropriate to use Internet-Drafts as reference 18 material or to cite them other than as a ``working draft' or ``work in 19 progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 Distribution of this document is unlimited. Please send comments to the 27 author at jak@violet.berkeley.edu or to the discussion list uri@bunyip.com. 29 2. Introduction 31 This document specifies a minimum set of requirements for Internet 32 resource locators, which convey location and access information for 33 resources. Typical examples of resources include network accessible 34 documents, WAIS databases, FTP servers, and Telnet destinations. 36 Locators may apply to resources that are not always or not ever network 37 accessible. Examples of the latter include human beings and physical 38 objects that have no electronic instantiation (that is, objects without 39 an existence completely defined by digital objects such as disk files). 41 A resource locator is a kind of resource identifier. Other kinds of 42 resource identifiers allow names and descriptions to be associated with 43 resources. A resource name is intended to provide a stable handle 44 to refer to a resource long after the resource itself has moved or 45 perhaps gone out of existence. A resource description comprises a 46 body of meta-information to assist resource search and selection. 48 In this document, an Internet resource locator is a locator defined by 49 an Internet resource location standard. A resource location standard 50 in conjunction with resource description and resource naming standards 51 specifies a comprehensive infrastructure for network based information 52 dissemination. Mechanisms for mapping between locators, names, and 53 descriptive identifiers are beyond the scope of this document. 55 3. Overview of Problem 57 Network-based information resource providers require a method of describing 58 the location of and access to their resources. Information systems users 59 require a method whereby client software can interpret resource access and 60 location descriptions on their behalf in a relatively transparent way. 61 Without such a method, transparent and widely distributed, open information 62 access on the Internet would be difficult if not impossible. 64 3.1 Defining the General Resource Locator 66 The requirements listed in this document impose restrictions on the 67 general resource locator. To better understand what the Internet resource 68 locator is, the following general locator definition provides some contrast. 70 Definition: A general resource locator is an object 71 that describes the location of a resource. 73 This definition deliberately allows many degrees of freedom in order 74 to contain the furthest reaches of the wide-ranging debate on resource 75 location standards. Vast as it is, this problem space is a useful 76 backdrop for discussion of the requirements (later) that generate a 77 smaller, more manageable problem space. A resource location standard 78 shrinks the space again by applying additional requirements. 80 Consider the definition in four parts: (1) A general resource locator 81 is an object (2) that describes (3) the location of (4) a resource. 83 3.1.1. A general resource locator is an object... 85 The object could be a complex data structure. It could be a contiguous 86 sequence of bytes. It could be a pair of latitude-longitude coordinates, 87 or a three-color road map printed on paper. It could be a sequence of 88 characters that are capable of being printed on paper. 90 3.1.2. ...that describes 92 In the fully general case, there are many ways that a resource locator 93 could describe the location. It could employ a graphical or natural 94 language description. It could be heavily encoded or compressed. It 95 could be lightly encoded and readily understandable by human beings. 96 The description could be a multi-level hierarchy with common semantics 97 at each level. It could be a multi-level hierarchy with common semantics 98 at only the first two levels, where semantics below the second level 99 depend on the value given at the first level. These are just a few 100 possibilities. 102 3.1.3. ...the location of 104 A resource locator describes a location but never guarantees that access 105 may be established. While access is often desired when clients follow 106 location instructions given in a conformant resource locator, the resource 107 need not exist any longer or need not exist yet. Indeed it may never exist, 108 even though the locator continues to describe a location where a resource 109 might exist (e.g., it might be used as a placeholder with resource 110 availability contingent upon an event such as a payment). 112 Furthermore, the nature of certain potential resources, especially animate 113 beings or physical objects with no electronic instantiation, makes network 114 access meaningless in some cases; such resources have locators that would 115 imply non-networked access, but again, access is not guaranteed. 117 3.1.4. ...a resource. 119 A resource can be many things. Besides the non-networked or non-electronic 120 resources just mentioned, familiar examples are an electronic document, 121 an image, a server (e.g., FTP, Gopher, Telnet, HTTP), or a collection 122 of items (e.g., Gopher menu, FTP directory, HTML page). Other examples 123 accompany multi-function protocols such as Z39.50, which can perform 124 single round trip network access, session-oriented search refinement, 125 and index browsing. 127 3.2 Producers and Interpreters of Resource Locators 129 Central to the discussion of locator requirements is the issue of 130 parsability. This is the ability of an agent to recognize or understand 131 a locator in whole or in part. Discussion may be assisted by clearly 132 distinguishing the two main actions associated with locators. 134 Resource locators are both produced and interpreted. Producers are bound 135 by the resource location standards that are in turn bound by requirements 136 listed in this document. Interpreters of locators are not bound by the 137 requirements; they are beneficiaries of them. 139 3.2.1 Resource Locator Interpreters 141 A resource locator is interpreted by interpreting agents, which in this 142 document are simply called interpreters. Interpreters may be either 143 human beings or software. Along the way to establishing access based 144 on information in a locator, one or more interpreters may be employed. 145 Some examples of multiple interpreters processing a single locator 146 illustrate the concept that a resource locator may be understandable 147 only in part by each of several interpreters, but understandable in 148 its entirety by a combination of interpreters. 150 In the first example, a software interpreter recognizes enough of a 151 locator to understand to which external agent it needs to forward it. 152 Here, the external agent might be a user and the locator a library call 153 number; the software forwards the locator simply by displaying it. The 154 agent might be a network software layer specializing in a particular 155 communications protocol; once the service is recognized, the locator 156 is forwarded to it along with an access request. 158 In another example, a human interpreter might also recognize enough 159 of a locator to understand where to forward it. Here, the person might 160 be a user who recognizes a library call number as such but who does not 161 understand the location information encoded in it; the person forwards 162 it to a library employee (an external agent) who knows how to establish 163 access to the library resource. 165 A prerequisite to interpreting a locator is understanding when an object 166 in question actually is a locator, or contains one or more locators. Some 167 constrained environments make this question easy to answer, for example, 168 within HTML anchors or Gopher menu items. Less constrained environments, 169 such as within running text, make it more difficult to answer without 170 well-defined assumptions. A resource location standard needs to make any 171 such assumptions explicit. 173 3.2.2 Resource Locator Producers 175 Resource locators are produced in many ways, often by an agent that also 176 interprets them. The provider of a resource may produce a locator for it, 177 leaving the locator in places where it is intended to be discovered, such 178 as an HTML page, a Gopher menu, or an announcement to an e-mail list. 180 Non-providers of resources can be major producers of locators; for example, 181 WWW client software produces locators by translating foreign resource 182 locators (e.g., Gopher menu items) to its own format. Some locator 183 databases (e.g., Archie) have been maintained by automated processes that 184 produce locators for hundreds of thousands of FTP resources that they 185 "discover" on the Internet. 187 Users are major producers of resource locators. A user constructing one 188 to share with others is responsible for conformance with locator standards. 189 Sometimes a user composes a resource locator based on an educated guess 190 and submits it to client software with the intent of establishing access. 191 Such a user is a producer in a sense, but if the locator is purely for 192 personal consumption the user is not bound by the requirements. In fact, 193 some client software may offer as a service to translate abbreviated, 194 non-conformant locators entered by users into successful access 195 instructions or into conformant locators (e.g., by adding a domain name 196 to an unqualified hostname) 198 3.3 Uniqueness of Resource Locators 200 The topic of a "uniqueness" requirement for resource locators has been 201 discussed a great deal. This document recognizes several aspects of 202 uniqueness, but deliberately makes few requirements regarding them. 203 It is incumbent upon a resource location standard that takes on this 204 topic to be clear about which aspects it addresses. Some of them follow. 206 3.3.1. Uniqueness and Multiple Copies of a Resource 207 A uniqueness requirement might dictate that no identical copies of a 208 resource may exist. This document makes no such requirement. 210 3.3.2. Uniqueness and Deterministic Access 211 A uniqueness requirement might dictate that the same resource accessed 212 in one attempt will also be the result of any other successful attempt. 213 This document makes no such requirement, nor does it define "sameness". 214 It is inappropriate for a resource location standard to define "sameness" 215 among resources. 217 3.3.3. Uniqueness and Multiple Locators 218 A uniqueness requirement might dictate that a resource have no more than 219 one locator unless all such locators be the same. This document makes 220 no such requirement, nor does it define "sameness" among locators 221 (which a standard might do using, for example, canonicalization rules). 223 3.3.4. Uniqueness, Ambiguity, and Multiple Objects per Access 224 A uniqueness requirement might dictate that a resource locator identify 225 exactly one object as opposed to several objects. This document makes 226 no general definition of what constitutes one object, several objects, 227 or one object consisting of several objects. 229 4. Resource Access and Availability 231 A locator never guarantees access, but establishing access is by far the 232 most important intended application of a resource locator. While it is 233 considered ungracious to advertize a locator for a resource that will 234 never be accessible (whether a "networkable" resource or not), it is 235 normal for resource access to fail at a rate that increases with the 236 age of the locator used. 238 Resource access can fail for many reasons. Providers fundamentally affect 239 accessibility by moving, replacing, or deleting resources over time. The 240 frequency of such changes depends on the nature of the resource and provider 241 service practices, among other things. A locator that conforms to a 242 location standard but fails for one of these reasons is called "invalid" 243 for the purposes of this document; the term invalid locator does not apply 244 to malformed or non-conformant locators. Resource naming standards 245 address the problem of invalid locators. 247 Ordinary provider support policies may cause resources to be inaccessible 248 during predictable time periods (e.g., certain hours of the day, or days 249 of the year), or during periods of heavy system loading. Rights clearance 250 restrictions impossible to express in a locator also affect accessibility 251 for certain user populations. Heavy network load can also prevent access. 252 In such situations, this document calls a resource "unavailable". 253 A locator can both be valid and identify a resource that is unavailable. 254 Resource description standards address, among other things, some aspects 255 of resource availability. 257 In general, the probability with which a given resource locator leads 258 to successful access decreases over time, and depends on conditions such as 259 the nature of the resource, support policies of the provider, and loading 260 of the network. 262 5. Requirements List for Internet Resource Locators 264 This list of requirements is applied to the set of general locators 265 defined in section 3.1. The resulting subset, called Internet locators 266 in this document, is suitable for further refinement by an Internet 267 resource location standard. Some requirements concern locator encoding 268 while others concern locator function. 270 One requirement from the original draft list was dropped after extensive 271 discussion revealed it to be impractical to meet. It stated that with a 272 high degree of reliability, software can recognize Internet locators in 273 certain relatively unstructured environments, such as within running 274 ASCII text. 276 5.1 Locators are transient. 278 The probability with which a given Internet resource locator leads to 279 successful access decreases over time. More stable resource identifier 280 schemes are addressed in resource naming standards and are outside 281 the scope of a resource location standard. 283 5.2 Locators have global scope. 285 The name space of resource locators includes the entire world. 286 The probability of successful access using an Internet locator 287 depends in no way, modulo resource availability, on the geographical 288 or Internet location of the client. 290 5.3 Locators are parsable. 292 Internet locators can be broken down into complete constituent parts 293 sufficient for interpreters (software or human) to attempt access if 294 desired. While these requirements do not bind interpreters, three 295 points bear emphasizing: 297 5.3.1 A given kind of locator may still be parsable even if a given 298 interpreter cannot parse it. 299 5.3.2 Parsable by users does not imply readily parsable by untrained users. 300 5.3.3 A given locator need not be completely parsable by any one interpreter 301 as long as a combination of interpreters can parse it completely. 303 5.4 Locators can be readily distinguished from naming and descriptive 304 identifiers that may occupy the same name space. 306 During a transition period (of possibly indefinite length), other kinds 307 of resource identifier are expected to co-exist in data structures along 308 with Internet locators. 310 5.5 Locators are "transport-friendly". 312 Internet locators can be transmitted from user to user (e.g, via e-mail) 313 across Internet standard communications protocols without loss or 314 corruption of information. 316 5.6 Locators are human transcribable. 318 Users can copy Internet locators from one medium to another (such as 319 voice to paper, or paper to keyboard) without loss or corruption of 320 information. This process is not required to be comfortable. 322 5.7 An Internet locator consists of a service and an opaque parameter package. 324 The parameter package has meaning only to the service with which it is 325 paired, where a service is an abstract access method. An abstract access 326 method might be a software tool, an institution, or a network protocol. 327 The parameter package might be service-specific access instructions. 328 In order to protect creative development of new services, there is an 329 extensible class of services for which no parameter package semantics 330 common across services may be assumed. 332 5.8 The set of services is extensible. 334 New services can be added over time. 336 5.9 Locators contain no information about the resource other than that 337 required by the access mechanism. 339 The purpose of an Internet locator is only to describe the location of 340 a resource, not other properties such as its type, size, modification 341 date, etc. These and other properties belong in a resource description 342 standard. 344 6. Conclusion 346 Resource location standards, which define Internet resource locators, 347 give providers the means to describe access information for their 348 resources. They give client developers the ability to access disparate 349 resources while hiding access details from users. 351 Several minimum requirements distinguish an Internet locator from a general 352 locator. Internet resource locators are impermanent handles sufficiently 353 qualified for resource access not to depend in general on client location. 354 Locators can be recognized and parsed, and can be transmitted unscathed 355 through a variety of human and Internet communication mechanisms. 357 An Internet resource locator consists of a service and access parameters 358 meaningful to that service. The form of the locator does not discourage 359 the addition of new services or the migration to other resource identifiers. 360 A clean distinction between resource location, resource naming, and resource 361 description standards is preserved by limiting Internet locators to no more 362 information than what is required by an access mechanism. 364 7. Acknowledgements 366 The core requirements of this document arose from a collaboration of the 367 following people at the November 1993 IETF meeting in Houston, Texas. 369 Farhad Ankelesaria, University of Minnesota 370 John Curran, NEARNET 371 Peter Deutsch, Bunyip 372 Alan Emtage, Bunyip 373 Jim Fullton, CNIDR 374 Kevin Gamiel, CNIDR 375 Joan Gargano, University of California at Davis 376 John Kunze, University of California at Berkeley 377 Clifford Lynch, University of California 378 Lars-Gunnar Olson, Swedish University of Agriculture 379 Mark McCahill, University of Minnesota 380 Michael Mealing, Georgia Tech 381 Mitra, Pandora Systems 382 Pete Percival, Indiana University 383 Margaret St. Pierre, WAIS, Inc. 384 Rickard Schoultz, KTH 385 Janet Vratny, Apple Computer Library 386 Chris Weider, Merit Network