idnits 2.17.1 draft-ietf-urlreg-procedures-05.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. Found some kind of copyright notice around line 33 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) 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. == 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 391 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. ** 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 113: '... regardless of registration tree, MUST...' RFC 2119 keyword, line 123: '... in the IETF tree, MUST conform to the...' RFC 2119 keyword, line 127: '... REQUIRED. (This is in accordance w...' RFC 2119 keyword, line 159: '... new URL schemes SHOULD follow the Gui...' RFC 2119 keyword, line 175: '... security risks SHOULD be identified....' 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 (January 25, 1999) is 9222 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 341 ** 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: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Petke 2 MCI WorldCom Advanced Networks 3 I. King 4 Microsoft Corporation 5 January 25, 1999 7 Registration Procedures for URL Scheme Names 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as 19 reference material or to cite them other than as "work in 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 ftp.ietf.org (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Distribution of this memo is unlimited. 29 This Internet-Draft expires July 25, 1999. 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 2.0 URL Scheme Name Registration Trees 65 2.1 General 67 In order to increase the efficiency and flexibility of the URL 68 scheme name registration process, the need is recognized for 69 multiple registration "trees". The registration requirements and 70 specific registration procedures for each tree differ, allowing the 71 overall registration procedure to accommodate the different natural 72 requirements for URL schemes. For example, a scheme that will be 73 recommended for wide support and implementation by the Internet 74 community requires a more complete review than a scheme intended to 75 be used for resources associated with proprietary software. 77 The first step in registering a new URL scheme name is to determine 78 which registration tree the scheme should be registered in. 79 Determination of the proper registration tree is based on the 80 intended use for the new scheme and the desired syntax for the 81 scheme name. 83 This document will discuss in detail the tree that reflects current 84 practice, under IETF ownership and control. It will also set forth 85 an outline to assist authors in creating new trees to address 86 differing needs for wide acceptance and interoperability, ease of 87 creation and use, and type and "strength" of ownership. 89 2.2 The IETF Tree 91 The IETF tree is intended for URL schemes of general interest to the 92 Internet community. The tree exists for URL schemes that require a 93 substantive review and approval process. It is expected that 94 applicability statements for particular applications will be 95 published from time to time that recommend implementation of, and 96 support for, URL schemes that have proven particularly useful in 97 those contexts. 99 2.3 Additional Registration Trees 101 From time to time and as required by the community, the IESG may 102 create new top-level registration trees. These trees may require 103 significant, little or no registration, and may allow change control 104 to rest in the hands of individuals or groups other than IETF. A 105 new tree should only be created if an existing tree can be shown to 106 fail in providing for a clear and specific need of some sector of 107 the community. 109 3.0 Requirements for Scheme Name Registration 111 3.1 General Requirements 113 All new URL scheme NAMES, regardless of registration tree, MUST 114 conform to the syntax specified in RFC 2396 for scheme NAMES. 116 3.2 The IETF Tree 118 Registration in the IETF tree requires publication of the URL scheme 119 syntax and semantics in either an Informational or Standards Track 120 RFC. 122 In addition to having a conforming scheme NAME (see section 3.1), 123 all new URL schemes registered in the IETF tree, MUST conform to the 124 generic syntax for URLs as specified in RFC 2396. 126 An analysis of the security issues inherent in the new URL scheme is 127 REQUIRED. (This is in accordance with the basic requirements for 128 all IETF protocols.) There is absolutely no requirement that all 129 URL schemes registered in the IETF tree be secure or completely free 130 from risks. Nevertheless, all known security risks must be 131 identified. 133 The "owner" of a URL scheme name registered in the IETF tree is 134 assumed to be the IETF itself. Modification or alteration of the 135 specification requires the same level of processing (e.g. 136 Informational or Standards Track RFC) as used for the initial 137 registration. Schemes originally defined via an Informational RFC 138 may, however, be replaced with Standards Track documents. 140 3.3 Alternative Trees 142 While public exposure and review of a URL scheme created in an 143 alternative tree is not required, using the IETF Internet-Draft 144 mechanism for peer review is strongly encouraged to improve the 145 quality of the specification. RFC publication of alternative tree 146 URL schemes is encouraged but not required. Material may be 147 published as an Informational RFC by sending it to the RFC Editor 148 (please follow the instructions to RFC authors, RFC 2223 [3]). 150 The defining document for an alternative tree may require public 151 exposure and/or review for schemes defined in that tree via a 152 mechanism other than the IETF Internet-Draft mechanism. 154 URL schemes created in an alternative tree are encouraged to conform 155 to the generic URL syntax, RFC 2396, but are not required to do so. 156 However, the tree's defining document must set forth the strength of 157 this requirement. 159 All new URL schemes SHOULD follow the Guidelines for URL Schemes, 160 set forth in RFC [URL-GUIDELINES] [2]. 162 While not required, an analysis of the security issues inherent in 163 the new URL scheme is encouraged. Regardless of what security 164 analysis is or is not performed, all descriptions of security issues 165 must be as accurate as possible. In particular, a statement that 166 there are "no security issues associated with this scheme" must not 167 be confused with "the security issues associates with this scheme 168 have not been assessed" or "the security issues associated with this 169 scheme cannot be predicted because of ". 171 There is absolutely no requirement that URL schemes created in an 172 alternative tree be secure or completely free from risks. 173 Nevertheless, the tree's defining document must set forth the 174 standard for security considerations, and in any event all known 175 security risks SHOULD be identified. 177 Change control must be defined for a new tree. Change control may 178 be vested in the IETF, or in an individual, group or other entity. 179 The change control standard for the tree must be approved by the 180 IESG. 182 The syntax for alternative trees shall be as follows: each tree will 183 be identified by a unique prefix, which must be established in the 184 same fashion as a URL scheme name in the IETF tree, except that the 185 prefix must be defined by a Standards Track document. Scheme names 186 in the new tree are then constructed by prepending the prefix to an 187 identifier unique to each scheme in that tree, as prescribed by that 188 tree's identifying document: 190 '-' 192 For instance, the "foo" tree would allow creation of scheme names of 193 the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes 194 an arbitrary USASCII string following the tree's unique prefix. 196 4.0 Registration Procedures 198 4.1 The IETF Tree 200 The first step in registering a new URL scheme in the IETF tree is 201 to publish an IETF Internet-Draft detailing the syntax and 202 semantics of the proposed scheme. The draft must, minimally, 203 address all of the items covered by the template provided in section 204 6 of this document. 206 After all issues raised during a review period of no less than 4 207 weeks have been addressed, submit the draft to the IESG for review. 209 The IESG will review the proposed new scheme and either refer the 210 scheme to a working group (existing or new) or directly present the 211 scheme to the IESG for a last call. In the former case, the working 212 group is responsible for submitting a final version of the draft to 213 the IESG for approval at such time as it has received adequate 214 review and deliberation. 216 4.2 Alternative Trees 218 Registration of URL schemes created in an alternative tree may be 219 formal, through IETF documents, IANA registration, or other 220 acknowledged organization; informal, through a mailing list or 221 other publication mechanism; or nonexistent. The registration 222 mechanism must be documented for each alternative tree, and must be 223 consistent for all URL scheme names created in that tree. 225 It is the responsibility of the creator of the tree's registration 226 requirements to establish that the registration mechanism is 227 workable as described; it is within the discretion of the IESG to 228 reject the document describing a tree if it determines the 229 registration mechanism is impractical or creates an undue burden on 230 a party who will not accept it. (For instance, if an IANA 231 registration mechanism is proposed, IESG might reject the tree if 232 its mechanism would create undue liability on the part of IANA.) 234 While the template in section 6 of this document is intended to 235 apply to URL scheme names in the IETF tree, it is also offered as a 236 guideline for those documenting alternative trees. 238 5.0 Change Control 240 5.1 Schemes in the IETF Tree 242 URL schemes created in the IETF tree are "owned" by the IETF itself 243 and may be changed, as needed, by updating the RFC that describes 244 them. Schemes described by Standards Track RFC but be replaced with 245 new Standards Track RFCs. Informational RFCs may be replaced by new 246 Informational RFCs or Standards Track RFCs. 248 5.2 Schemes in Alternative Trees 250 Undocumented URL schemes created in an alternative tree may be 251 changed by their owner at any time without notifying the IETF. 253 URL schemes created in an alternative tree that have been documented 254 by an Informational RFC, may be changed at any time by the owner, 255 however, an updated Informational RFC which details the changes 256 made, must be submitted to the IESG. 258 The owner of a URL scheme registered in an alternative tree and 259 documented by an Informational RFC may pass responsibility for the 260 registration to another person or agency by informing the IESG. 262 The IESG may reassign responsibility for a URL scheme registered in 263 an alternative tree and documented by an Informational RFC. The 264 most common case of this will be to enable changes to be made to 265 schemes where the scheme name is privately owned by the rules of its 266 tree, and the owner of the scheme name has died, moved out of 267 contact or is otherwise unable to make changes that are important to 268 the community. 270 The IESG may reclassify a URL scheme created in an alternative tree 271 and documented via an Informational RFC as "historic" if it 272 determines that the scheme is no longer in use. 274 6.0 Registration Template 276 The following issues should be addressed when documenting a new URL 277 scheme: 279 URL scheme name. 281 URL scheme syntax. This should be expressed in a clear and 282 concise manner. The use of ABNF is encouraged. Please refer to 283 RFC [URL-GUIDELINES] for guidance on designing and explaining 284 your scheme's syntax. 286 Character encoding considerations. It is important to identify 287 what your scheme supports in this regard. It is obvious that for 288 interoperability, it is best if there is a means to support 289 character sets beyond USASCII, but especially for private 290 schemes, this may not be the case. 292 Intended usage. What sort of resource is being identified? If 293 this is not a 'resource' type of URL (e.g. mailto:), explain the 294 action that should be initiated by the consumer of the URL. If 295 there is a MIME type associated with this resource, please 296 identify it. 298 Applications and/or protocols which use this URL scheme name. 300 Interoperability considerations. If you are aware of any details 301 regarding your scheme which might impact interoperability, please 302 identify them here. For example: proprietary or uncommon 303 encoding method; inability to support multibyte character sets; 304 incompatibility with types or versions of underlying protocol 305 (if scheme is tunneled over another protocol). 307 Security considerations. 309 Relevant publications. 311 Person & email address to contact for further information. 313 Author/Change controller. 315 Applications and/or protocols which use this URL scheme name. 317 7.0 Security Considerations 319 Information that creates or updates a registration needs to be 320 authenticated. 322 Information concerning possible security vulnerabilities of a 323 protocol may change over time. Consequently, claims as to the 324 security properties of a registered URL scheme may change as well. 325 As new vulnerabilities are discovered, information about such 326 vulnerabilities may need to be attached to existing documentation, 327 so that users are not misled as to the true security properties of a 328 registered URL scheme. 330 If the IESG agrees to delegate the registration and change control 331 functions of an alternative tree to a group or individual outside of 332 the IETF, that group or individual should have sufficient security 333 procedures in place to authenticate registration changes. 335 8.0 References 337 [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 338 Identifiers (URI): Generic Syntax", RFC 2396, August 1998 340 [2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 341 "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 342 1998 344 [3] Postel, J., Reynolds, J., "Instructions to RFC Authors", 345 RFC 2223, October 1997. 347 9.0 Authors' Address 349 Rich Petke 350 MCI WorldCom Advanced Networks 351 5000 Britton Road 352 P. O. Box 5000 353 Hilliard, OH 43026-5000 354 USA 355 Phone: +1 614 723 4157 356 Fax: +1 614 723 8407 357 EMail: rpetke@wcom.net 359 Ian King 360 Microsoft Corporation 361 One Microsoft Way 362 Redmond, WA 98052-6399 363 USA 364 Phone: +1 425-703-2293 365 FAX: +1 425-936-7329 366 Email: iking@microsoft.com