idnits 2.17.1 draft-ietf-urlreg-procedures-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. == 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 390 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 26, 1999) is 8979 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) -- Looks like a reference, but probably isn't: 'URL-GUIDELINES' on line 364 -- Looks like a reference, but probably isn't: 'RFC-GUIDELINES' on line 128 ** Obsolete normative reference: RFC 2396 (ref. '1') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2223 (ref. '3') (Obsoleted by RFC 7322) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Petke 2 UUNET Technologies 3 I. King 4 Microsoft Corporation 5 September 26, 1999 7 Registration Procedures for URL Scheme Names 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. Internet-Drafts 16 are draft documents valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It 18 is inappropriate to use Internet-Drafts as reference material or to 19 cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt. 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Distribution of this Internet-Draft is unlimited. 29 This Internet-Draft expires April 26, 2000. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 Abstract 37 This document defines the process by which new URL scheme names are 38 registered. 40 1.0 Introduction 42 A Uniform Resource Locator (URL) is a compact string representation 43 of the location for a resource that is available via the Internet. 44 RFC 2396 [1] defines the general syntax and semantics of URIs, and, 45 by inclusion, URLs. URLs are designated by including a ":" 46 and then a "". Many URL schemes are already 47 defined, however, new schemes may need to be defined in the future 48 in order to accommodate new Internet protocols and/or procedures. 50 A registration process is needed to ensure that the names of all 51 such new schemes are guaranteed not to collide. Further, the 52 registration process ensures that URL schemes intended for wide 53 spread, public use are developed in an orderly, well-specified, and 54 public manner. 56 This document defines the registration procedures to be followed 57 when new URL schemes are created. A separate document, RFC 58 [URL-GUIDELINES], Guidelines for URL Schemes [2], provides 59 guidelines for the creation of new URL schemes. The primary focus 60 of this document is on the portion of new URL schemes, 61 referred to as the "scheme name" throughout this document. 63 1.1 Notation 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119. 69 2.0 URL Scheme Name Registration Trees 71 2.1 General 73 In order to increase the efficiency and flexibility of the URL 74 scheme name registration process, the need is recognized for 75 multiple registration "trees". The registration requirements and 76 specific registration procedures for each tree differ, allowing the 77 overall registration procedure to accommodate the different natural 78 requirements for URL schemes. For example, a scheme that will be 79 recommended for wide support and implementation by the Internet 80 community requires a more complete review than a scheme intended to 81 be used for resources associated with proprietary software. 83 The first step in registering a new URL scheme name is to determine 84 which registration tree the scheme should be registered in. 85 Determination of the proper registration tree is based on the 86 intended use for the new scheme and the desired syntax for the 87 scheme name. 89 This document will discuss in detail the tree that reflects current 90 practice, under IETF ownership and control. It will also set forth 91 an outline to assist authors in creating new trees to address 92 differing needs for wide acceptance and interoperability, ease of 93 creation and use, and type and "strength" of ownership. 95 2.2 The IETF Tree 97 The IETF tree is intended for URL schemes of general interest to the 98 Internet community. The tree exists for URL schemes that require a 99 substantive review and approval process. It is expected that 100 applicability statements for particular applications will be 101 published from time to time that recommend implementation of, and 102 support for, URL schemes that have proven particularly useful in 103 those contexts. 105 2.3 Additional Registration Trees 107 From time to time and as required by the community, the IESG may 108 create new top-level registration trees. These trees may require 109 significant, little or no registration, and may allow change control 110 to rest in the hands of individuals or groups other than IETF. A 111 new tree should only be created if no existing tree can be shown to 112 address the set of needs of some sector of the community. 114 3.0 Requirements for Scheme Name Registration 116 3.1 General Requirements 118 All new URL schemes, regardless of registration tree, MUST conform 119 to the generic syntax for URLs as specified in RFC 2396. 121 3.2 The IETF Tree 123 Registration in the IETF tree requires publication of the URL scheme 124 syntax and semantics in either an Informational or Standards Track 125 RFC. In general, the creation of a new URL scheme requires a 126 Standards Track RFC. An Informational RFC may be employed for 127 registration only in the case of a URL scheme which is already in 128 wide usage and meets other standards set forth in [RFC-GUIDELINES], 129 such as "demonstrated utility" within the Internet Architecture; the 130 IESG shall have broad discretion in determining whether an 131 Informational RFC is suitable in any given case, and may either 132 recommend changes to such document prior to publication, or reject 133 it for publication. An Informational RFC purporting to describe a 134 URL scheme shall not be published without IESG approval. This is a 135 departure from practice for Informational RFCs as set forth in RFC 136 2026, for the purpose of ensuring that the registration of URL 137 schemes shall serve the best interests of the Internet community. 139 The NAMES of schemes registered in the IETF tree MUST NOT contain 140 the dash (also known as the hyphen and minus sign) character ('-') 141 USASCII value 2Dh. Use of this character can cause confusion with 142 schemes registered in alternative trees (see section 3.3). 144 An analysis of the security issues inherent in the new URL scheme 145 is REQUIRED. (This is in accordance with the basic requirements for 146 all IETF protocols.) URL schemes registered in the IETF tree should 147 not introduce additional security risks into the Internet Architec- 148 ture. For example, URLs should not embed information which should 149 remain confidential, such as passwords, nor should new schemes 150 subvert the security of existing schemes or protocols (i.e. by 151 layering or tunneling). 153 The "owner" of a URL scheme name registered in the IETF tree is 154 assumed to be the IETF itself. Modification or alteration of the 155 specification requires the same level of processing (e.g. 156 Informational or Standards Track RFC) as used for the initial 157 registration. Schemes originally defined via an Informational RFC 158 may, however, be replaced with Standards Track documents. 160 3.3 Alternative Trees 162 While public exposure and review of a URL scheme created in an 163 alternative tree is not required, using the IETF Internet-Draft 164 mechanism for peer review is strongly encouraged to improve the 165 quality of the specification. RFC publication of alternative tree 166 URL schemes is encouraged but not required. Material may be 167 published as an Informational RFC by sending it to the RFC Editor 168 (please follow the instructions to RFC authors, RFC 2223 [3]). 170 The defining document for an alternative tree may require public 171 exposure and/or review for schemes defined in that tree via a 172 mechanism other than the IETF Internet-Draft mechanism. 174 URL schemes created in an alternative tree must conform to the 175 generic URL syntax, RFC 2396. The tree's defining document may set 176 forth additional syntax and semantics requirements above and 177 beyond those specified in RFC 2396. 179 All new URL schemes SHOULD follow the Guidelines for URL Schemes, 180 set forth in RFC [URL-GUIDELINES] [2]. 182 An analysis of the security issues inherent in the new URL scheme is 183 encouraged. Regardless of what security analysis is or is not 184 performed, all descriptions of security issues must be as accurate 185 as possible. In particular, a statement that there are "no security 186 issues associated with this scheme" must not be confused with "the 187 security issues associates with this scheme have not been assessed" 188 or "the security issues associated with this scheme cannot be 189 predicted because of ". 191 There is absolutely no requirement that URL schemes created in an 192 alternative tree be secure or completely free from risks. 193 Nevertheless, the tree's defining document must set forth the 194 standard for security considerations, and in any event all known 195 security risks SHOULD be identified. 197 Change control must be defined for a new tree. Change control may 198 be vested in the IETF, or in an individual, group or other entity. 199 The change control standard for the tree must be approved by the 200 IESG. 202 The syntax for alternative trees shall be as follows: each tree will 203 be identified by a unique prefix, which must be established in the 204 same fashion as a URL scheme name in the IETF tree, except that the 205 prefix must be defined by a Standards Track document. Scheme names 206 in the new tree are then constructed by prepending the prefix to an 207 identifier unique to each scheme in that tree, as prescribed by that 208 tree's identifying document: 210 '-' 212 For instance, the "foo" tree would allow creation of scheme names of 213 the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes 214 an arbitrary USASCII string following the tree's unique prefix. 216 4.0 Registration Procedures 218 4.1 The IETF Tree 220 The first step in registering a new URL scheme in the IETF tree is 221 to publish an IETF Internet-Draft detailing the syntax and 222 semantics of the proposed scheme. The draft must, minimally, 223 address all of the items covered by the template provided in section 224 6 of this document. 226 After all issues raised during a review period of no less than 4 227 weeks have been addressed, submit the draft to the IESG for review. 229 The IESG will review the proposed new scheme and either refer the 230 scheme to a working group (existing or new) or directly present the 231 scheme to the IESG for a last call. In the former case, the working 232 group is responsible for submitting a final version of the draft to 233 the IESG for approval at such time as it has received adequate 234 review and deliberation. 236 4.2 Alternative Trees 238 Registration of URL schemes created in an alternative tree may be 239 formal, through IETF documents, IANA registration, or other 240 acknowledged organization; informal, through a mailing list or 241 other publication mechanism; or nonexistent. The registration 242 mechanism must be documented for each alternative tree, and must be 243 consistent for all URL scheme names created in that tree. 245 It is the responsibility of the creator of the tree's registration 246 requirements to establish that the registration mechanism is 247 workable as described; it is within the discretion of the IESG to 248 reject the document describing a tree if it determines the 249 registration mechanism is impractical or creates an undue burden on 250 a party who will not accept it. (For instance, if an IANA 251 registration mechanism is proposed, IESG might reject the tree if 252 its mechanism would create undue liability on the part of IANA.) 254 While the template in section 6 of this document is intended to 255 apply to URL scheme names in the IETF tree, it is also offered as a 256 guideline for those documenting alternative trees. 258 5.0 Change Control 260 5.1 Schemes in the IETF Tree 262 URL schemes created in the IETF tree are "owned" by the IETF itself 263 and may be changed, as needed, by updating the RFC that describes 264 them. Schemes described by Standards Track RFC but be replaced with 265 new Standards Track RFCs. Informational RFCs may be replaced by new 266 Informational RFCs or Standards Track RFCs. 268 5.2 Schemes in Alternative Trees 270 URL schemes in an alternative tree that are undocumented (as allowed 271 by that tree's rules) may be changed by their owner at any time 272 without notifying the IETF. 274 URL schemes created in an alternative tree that have been documented 275 by an Informational RFC, may be changed at any time by the owner, 276 however, an updated Informational RFC which details the changes 277 made, must be submitted to the IESG. 279 The owner of a URL scheme registered in an alternative tree and 280 documented by an Informational RFC may pass responsibility for the 281 registration to another person or agency by informing the IESG. 283 The IESG may reassign responsibility for a URL scheme registered in 284 an alternative tree and documented by an Informational RFC. The 285 most common case of this will be to enable changes to be made to 286 schemes where the scheme name is privately owned by the rules of its 287 tree, and the owner of the scheme name has died, moved out of 288 contact or is otherwise unable to make changes that are important to 289 the community. 291 The IESG may reclassify a URL scheme created in an alternative tree 292 and documented via an Informational RFC as "historic" if it 293 determines that the scheme is no longer in use. 295 6.0 Registration Template 297 The following issues should be addressed when documenting a new URL 298 scheme: 300 URL scheme name. 302 URL scheme syntax. This should be expressed in a clear and 303 concise manner. The use of ABNF is encouraged. Please refer to 304 RFC [URL-GUIDELINES] for guidance on designing and explaining 305 your scheme's syntax. 307 Character encoding considerations. It is important to identify 308 what your scheme supports in this regard. It is obvious that for 309 interoperability, it is best if there is a means to support 310 character sets beyond USASCII, but especially for private 311 schemes, this may not be the case. 313 Intended usage. What sort of resource is being identified? If 314 this is not a 'resource' type of URL (e.g. mailto:), explain the 315 action that should be initiated by the consumer of the URL. If 316 there is a MIME type associated with this resource, please 317 identify it. 319 Applications and/or protocols which use this URL scheme name. 320 Including references to documentation which defines the 321 applications and/or protocols cited is especially useful. 323 Interoperability considerations. If you are aware of any details 324 regarding your scheme which might impact interoperability, please 325 identify them here. For example: proprietary or uncommon 326 encoding method; inability to support multibyte character sets; 327 incompatibility with types or versions of underlying protocol 328 (if scheme is tunneled over another protocol). 330 Security considerations. 332 Relevant publications. 334 Person & email address to contact for further information. 336 Author/Change controller. 338 Applications and/or protocols which use this URL scheme name. 340 7.0 Security Considerations 342 Information that creates or updates a registration needs to be 343 authenticated. 345 Information concerning possible security vulnerabilities of a 346 protocol may change over time. Consequently, claims as to the 347 security properties of a registered URL scheme may change as well. 348 As new vulnerabilities are discovered, information about such 349 vulnerabilities may need to be attached to existing documentation, 350 so that users are not misled as to the true security properties of a 351 registered URL scheme. 353 If the IESG agrees to delegate the registration and change control 354 functions of an alternative tree to a group or individual outside of 355 the IETF, that group or individual should have sufficient security 356 procedures in place to authenticate registration changes. 358 8.0 References 360 [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 361 Identifiers (URI): Generic Syntax", RFC 2396, August 1998 363 [2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 364 "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 365 1998 367 [3] Postel, J., Reynolds, J., "Instructions to RFC Authors", 368 RFC 2223, October 1997. 370 9.0 Authors' Address 372 Rich Petke 373 UUNET Technologies 374 5000 Britton Road 375 P. O. Box 5000 376 Hilliard, OH 43026-5000 377 USA 378 Phone: +1 614 723 4157 379 Fax: +1 614 723 8407 380 Email: rpetke@wcom.net 382 Ian King 383 Microsoft Corporation 384 One Microsoft Way 385 Redmond, WA 98052-6399 386 USA 387 Phone: +1 425-703-2293 388 FAX: +1 425-936-7329 389 Email: iking@microsoft.com