idnits 2.17.1 draft-masinter-url-process-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-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 340 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([RFCURL-SYNTAX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- The document date (June 4, 1997) is 9823 days in the past. Is this intentional? 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: 'RFC URL-SYNTAX' is mentioned on line 34, but not defined == Missing Reference: 'RFC 2044' is mentioned on line 144, but not defined ** Obsolete undefined reference: RFC 2044 (Obsoleted by RFC 2279) == Unused Reference: 'RFC2022' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'URL-SYNTAX' is defined on line 309, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'URL-SYNTAX' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Larry Masinter 2 Dan Zigmond 3 March 26, 1997 Harald T. Alvestrand 4 expires June 4, 1997 6 Guidelines and Process for new URL Schemes 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 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as ``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 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Issues: 28 Registration process isn't really there. 30 Abstract 32 A Uniform Resource Locator (URL) is a compact string representation 33 of the location for a resource that is available via the Internet. 34 [RFC URL-SYNTAX] defines the general syntax and semantics of URLs. 35 This document provides guidelines for the definition of new URL 36 schemes and describes the process by which they are registered. 38 1. Introduction 40 In addition to specifying the general syntax for Uniform Resource 41 Locators, RFC 1738 defined a number of generally useful URL schemes 42 and promised that a mechanism for registering new schemes would be 43 established. Several new URLs have been proposed since that time, 44 but the procedure for standardizing these schemes has never been 45 fully defined. This document describes the current practice and 46 offers some guidance for authors of new schemes. 48 One process for defining URL schemes is via the Internet standards 49 process: new URL schemes should be described in standards-track 50 RFCs. The Internet Assigned Numbers Authority (IANA) maintains a 51 registry of all URL schemes defined in this way. 53 2. Guildelines for new URL schemes 55 Because new URL schemes potentially complicate client software, new 56 schemes must have demonstrable utility and operability, as well as 57 compatibility with existing URL schemes. This section elaborates 58 these criteria. 60 2.1 Syntactic compatibility 62 New URL schemes should follow the same syntactic conventions of 63 existing schemes when appropriate. 65 2.1.1 Use of initial "//" for Internet host addresses 67 Many proposed new URL schemes seem to use "://" as a kind of 68 indicator that what follows is a URL. However, the use of the top 69 level "//" is indicative of an Internet host address, and not a top 70 level marker. 72 2.1.2 Compatibility with relative URLs 74 URL schemes should use the generic-URL syntax if they are intended 75 to be used with relative URLs. A description of the allowed 76 relative forms should be included in the scheme's definition. 77 Many applications use relative URLs extensively. 79 o Can it be parsed according to RFC URL-SYNTAX - that is, if the 80 tokens "//", "/", ";", "?" and "#" are used, do they have the 81 meaning given in RFC URL-SYNTAX? 83 o Does it make sense to use it in relative URLs like those RFC 84 URL-SYNTAX specifies? 86 o If something is designed to be broken into pieces, does it 87 document what those pieces are, why it should be broken in this 88 way, and why the breaks aren't where URL-SYNTAX says that they 89 usually should be? 91 o If it has a hierarchy, does it go left-to-right and with slash 92 separators like RFC URL-SYNTAX? If not, why not? 94 2.1.3 Does it start with "ur"? 96 Any scheme starting with the letters "U" and "R", in particular if 97 it attaches any of the meanings "uniform", "universal" or 98 "unifying" to the first leter, is going to cause intense debate, 99 and generate much heat (but maybe little light). 101 2.2 Is the scheme well defined? 103 It is important that the semantics of the "resource" that a URL 104 "locates" be well defined. This might mean different things 105 depending on the nature of the URL scheme. 107 2.2.1 Clear mapping from other name spaces 109 In many cases, new URL schemes are defined as ways to translate 110 other protocols and name spaces into the general framework of 111 URLs. The "ftp" URL scheme translates from the FTP protocol, while 112 the "mid" URL scheme translates from the Message-ID field of 113 messages. 115 In either case, the description of the mapping must be complete, 116 must describe how character sets get encoded or not in URLs, must 117 describe exactly how all legal values of the base standard can be 118 represented using the URL scheme, and exactly which modifiers, 119 alternate forms and other artifacts from the base standards are 120 included or not included. These requirements are elaborated 121 below. 123 2.2.2 URL schemes associated with network protocols 125 Most new URL schemes are associated with network resources that 126 have one or several network protocols that can access them. The 127 'ftp', 'news', and 'http' schemes are of this nature. For such 128 schemes, the specification should completely describe how URLs are 129 translated into protocol actions in sufficient detail to make the 130 access of the network resource unambiguous. If an implementation 131 of of the URL scheme requires some configuration, the configuration 132 elements must be clearly identified. (For example, the 'news' 133 scheme, if implemented using NTTP, requires configuration of the 134 NTTP server.) 136 2.2.3 Character encoding 138 When describing URL schemes in which (some of) the elements of 139 the URL are actually representations of sequences of characters, 140 care should be taken not to introduce unnecessary variety in the 141 ways in which characters are encoded into octets and then into 142 URL characters. Unless there is some compelling reason for a 143 particular scheme to do otherwise, translating character sequences 144 into UTF-8 [RFC 2044] and then subsequently using the %HH encoding 145 for unsafe octets is recommended. 147 2.2.4 Definition of non-protocol URL schemes 149 In some cases, URL schemes do not have particular network protocols 150 associated with them, because their use is limited to contexts 151 where the access method is understood. This is the case, for 152 example, with the "cid" and "mid" URL schemes. For these URL 153 schemes, the specification should describe the notation of the 154 scheme and a complete mapping of the locator from its source. 156 2.2.5 Definition of URL schemes not associated with data resources 158 Most URL schemes locate Internet resources that correspond 159 to data objects that can be retrieved or modified. This is the 160 case with "ftp" and "http", for example. However, some URL schemes 161 do not; for example, the "mailto" URL scheme corresponds to an 162 Internet mail address. 164 If a new URL scheme does not locate resources that are data 165 objects, the properties of names in the new space must be clearly 166 defined. 168 2.2.6 Definition of operations 170 In some contexts (for example, HTML forms) it is possible to 171 specify any one of a list of operations to be performed on a 172 specifc URL. (Outside forms, it is generally assumed to be 173 something you GET.) 175 The URL scheme definition should describe all well-defined 176 operations on the URL identifier, and what they are supposed to 177 do. 179 Some URL schemes (for example, "telnet") provide location 180 information for hooking onto bidirectional data streams, and don't 181 fit the "infoaccess" paradigm of most URLs very well; this should 182 be documented. 184 NOTE: It is perfectly valid to say that "no operation apart from 185 GET is defined for this URL". It is also valid to say that "there's 186 only one operation defined for this URL, and it's not very 187 GET-like". The important point is that what is defined on this type 188 is described. 190 2.3 Demonstrated utility 192 URL schemes should have demonstrated utility. New URL schemes are 193 expensive things to support. Often they require special code in 194 browsers, proxies, and/or servers. Having a lot of ways to say the 195 same thing needless complicates these programs without adding value 196 to the Internet. 198 The kinds of things that are useful include: 200 o Things that cannot be referred to in any other way. 202 o Things where it is much easier to get at them using this 203 scheme than (for instance) a proxy gateway. 205 2.3.1 Proxy into HTTP/HTML 207 One way to provide a demonstration of utility is via a gateway 208 which provides objects in the new scheme for clients using an 209 existing protocol. It is much easier to deploy gateways to a new 210 service than it is to deploy browsers that understand the new URL 211 object. 213 Things to look for when thinking about a proxy are: 215 o Is there a single global resolution mechanism whereby any proxy can 216 find the referenced object? 217 o If not, is there a way in which the user can find any object of 218 this type, and "run his own proxy"? 219 o Are the operations mappable one-to-one (or possibly using 220 modifiers) to HTTP operations? 221 o Is the type of returned objects well defined? 222 * as MIME content-types? 223 * as something that can be translated to HTML? 224 o Is there running code for a proxy? 226 2.4 Are there security considerations? 228 Above and beyond the security considerations of the base mechanism 229 a scheme builds upon, one must think of things that can happen in 230 the normal course of URL usage. 232 In particular: 234 o Does the user need to be warned that such a thing is happening 235 without an explicit request (GET for the source of an IMG tag, 236 for instance)? This has implications for the design of a proxy 237 gateway, of course. 239 o Is it possible to fake URLs of this type that point to different 240 things in a dangerous way? 242 o Are there mechanisms for identifying the requester that can be 243 used or need to be used with this mechanism (the From: field in a 244 mailto: URL, or the Kerberos login required for AFS access in the 245 AFS: url, for instance)? 247 o Does the mechanism contain passwords or other security 248 information that are passed inside the referring document in the 249 clear (as in the "ftp" URL, for instance)? 251 2.5 Does it start with UR? 253 Any scheme starting with the letters "U" and "R", in particular if 254 it attaches any of the meanings "uniform", "universal" or 255 "unifying" to the first letter, is going to cause intense debate, 256 and generate much heat (but maybe little light). 258 Any such proposal should either make sure that there is a large 259 consensus behind it that it will be the only scheme of its type, or 260 pick another name. 262 2.6 Non-considerations 264 Some issues that are often raised but are not relevent to new URL 265 schemes include the following. 267 2.6.1 Is it an URL, an URN or something else? 269 This classification has proved interesting in theory, but not 270 terribly useful when evaluating schemes. 272 2.6.2 Are all objects acessible? 274 Can all objects in the world that are validly identified by a 275 scheme be accessed by any UA implementing it? 277 Sometimes the answer will be yes and sometimes no; often it will 278 depend on factors (like firewalls or client configuration) not 279 directly related to the scheme itself. 281 3. Revision process 283 NOTE: THIS SECTION IS ENTIRELY TBD. REVIEW COMMITTEE? PRIVATE URLS? 285 URL schemes will have either a standards track RFC, or else they 286 will be a registration at IANA. where include the whole draft. URL 287 schemes will have a review panel, appointed by IETF AD, who may not 288 reject a URL scheme but who may provide a 2 sentence recommendation 289 about the use of the URL scheme. Conflicting registrations are 290 possible for non-standard URL schemes, and the order in the IANA 291 list of conflicting registrations will be determined by a random 292 number generator. 294 4. Security considerations 296 New URL schemes are required to address all security considerations 297 in their definitions. 299 5. IANA considerations 301 This document requires IANA to register URL schemes according to 302 the process outlined in section 3. 304 6. References 306 [RFC2022] F. Yergeau, "UTF-8, A Transformation Format of Unicode 307 and ISO 10646", Alis Technologies, October 1996. 309 [URL-SYNTAX] 310 Berners-Lee, Fielding, Masinter, "Uniform Resource Locators: 311 Generic Syntax and Semantics", . 313 7. Author's Addresses 315 Larry Masinter 316 Xerox Corporation 317 Palo Alto Research Center 318 3333 Coyote Hill Road 319 Palo Alto, CA 94304 320 Fax: +1-415-812-4333 321 EMail: masinter@parc.xerox.com 323 Dan Zigmond 324 Wink Communications 325 1001 Marina Village Parkway 326 Alameda CA 94610 327 Fax: +1-510-337-2960 328 Phone: +1-510-337-6359 329 Email: dan.zigmond@wink.com 331 Harald T. Alvestrand 332 UNINETT A/S 333 Postboks 6683 Elgeseter 7002 334 Trondheim, Norway 335 Tel: +47 73 59 70 94 336 EMail: Harald.T.Alvestrand@uninett.no