idnits 2.17.1 draft-ietf-urlreg-procedures-04.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 31 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 381 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 120: '... regardless of registration tree, MUST...' RFC 2119 keyword, line 130: '... in the IETF tree, MUST conform to the...' RFC 2119 keyword, line 134: '... REQUIRED. (This is in accordance w...' RFC 2119 keyword, line 160: '... new URL schemes SHOULD follow the Gui...' RFC 2119 keyword, line 173: '...n 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 (November 1, 1998) is 9307 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 324 ** 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 MCIWORLDCOM Advanced Networks 3 November 1, 1998 5 Registration Procedures for URL Scheme Names 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other documents 16 at any time. It is inappropriate to use Internet-Drafts as 17 reference material or to cite them other than as "work in progress." 19 To learn the current status of any Internet-Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 23 Rim). 25 Distribution of this memo is unlimited. 27 This Internet-Draft expires April 30, 1999. 29 Copyright Notice 31 Copyright (C) The Internet Society (1998). All Rights Reserved. 33 Abstract 35 This document defines the process by which new URL scheme names are 36 registered. 38 1.0 Introduction 40 A Uniform Resource Locator (URL) is a compact string representation 41 of the location for a resource that is available via the Internet. 42 RFC 2396 [1] defines the general syntax and semantics of URIs, and, 43 by inclusion, URLs. URLs are designated by including a ":" 44 and then a "". Many URL schemes are already 45 defined, however, new schemes may need to be defined in the future 46 in order to accommodate new Internet protocols and/or procedures. 48 A registration process is needed to ensure that the names of all 49 such new schemes are guaranteed not to collide. Further, the 50 registration process ensures that URL schemes intended for wide 51 spread, public use are developed in an orderly, well-specified, and 52 public manner. 54 This document defines the registration procedures to be followed 55 when new URL schemes are created. A separate document, RFC 56 [URL-GUIDELINES], Guidelines for URL Schemes [2], provides 57 guidelines for the creation of new URL schemes. The primary focus 58 of this document is on the portion of new URL schemes, 59 referred to as the "scheme name" throughout this document. 61 2.0 URL Scheme Name Registration Trees 63 2.1 General 65 In order to increase the efficiency and flexibility of the URL 66 scheme name registration process, two different registration "trees" 67 have been created. The registration requirements and specific 68 registration procedures for each tree differ, allowing the overall 69 registration procedure to accommodate the different natural 70 requirements for URL schemes. For example, a scheme that will be 71 recommended for wide support and implementation by the Internet 72 community requires a more complete review than a scheme intended to 73 be used for resources associated with proprietary software. 75 The first step in registering a new URL scheme name is to determine 76 which registration tree the scheme should be registered in. 77 Determination of the proper registration tree is based on the 78 intended use for the new scheme and the desired syntax for the 79 scheme name. 81 Note that some URL schemes defined prior to this document do not 82 conform to the naming conventions described below. See Appendix A 83 for a discussion of those schemes. 85 2.2 The IETF Tree 87 The IETF tree is intended for URL schemes of general interest to the 88 Internet community. The tree exists for URL schemes that require a 89 substantive review and approval process. It is expected that 90 applicability statements for particular applications will be 91 published from time to time that recommend implementation of, and 92 support for, URL schemes that have proven particularly useful in 93 those contexts. 95 2.3 The OID Tree 97 The OID tree is intended for URL schemes which will be used in a 98 proprietary manner. The trees exists to provide a mechanism for 99 ensuring that scheme names do not collide. The syntax and semantics 100 of URL schemes created in the OID tree do not have to be reviewed or 101 publicly disclosed. 103 Creating a URL scheme name in the OID tree does not imply 104 endorsement, approval, or recommendation by the IETF or even 105 certification that the specification is adequate, even if the scheme 106 was published as an IETF Internet-Draft and/or reviewed by IETF 107 participants. To become Internet Standards, protocols, data 108 objects, or whatever must go through the IETF standards process and 109 registration in the IETF tree. 111 2.4 Additional Registration Trees 113 From time to time and as required by the community, the IESG may 114 create new top-level registration trees. 116 3.0 Requirements for Scheme Name Registration 118 3.1 General Requirements 120 All new URL scheme NAMES, regardless of registration tree, MUST 121 conform to the syntax specified in RFC 2396 for scheme NAMES. 123 3.2 The IETF Tree 125 Registration in the IETF tree requires publication of the URL scheme 126 syntax and semantics in either an Informational or Standards Track 127 RFC. 129 In addition to having a conforming scheme NAME (see section 3.1), 130 all new URL schemes registered in the IETF tree, MUST conform to the 131 generic syntax for URLs as specified in RFC 2396. 133 An analysis of the security issues inherent in the new URL scheme is 134 REQUIRED. (This is in accordance with the basic requirements for 135 all IETF protocols.) There is absolutely no requirement that all 136 URL schemes registered in the IETF tree be secure or completely free 137 from risks. Nevertheless, all known security risks must be 138 identified. 140 The "owner" of a URL scheme name registered in the IETF tree is 141 assumed to be the IETF itself. Modification or alteration of the 142 specification requires the same level of processing (e.g. 143 Informational or Standards Track RFC) as used for the initial 144 registration. Schemes originally defined via an Informational RFC 145 may, however, be replaced with Standards Track documents. 147 3.3 The OID Tree 149 While public exposure and review of a URL scheme created in the OID 150 tree is not required, using the IETF Internet-Draft mechanism for 151 peer review is strongly encouraged to improve the quality of the 152 specification. RFC publication of OID tree URL schemes is 153 encouraged but not required. Material may be published as an 154 Informational RFC by sending it to the RFC Editor (please follow the 155 instructions to RFC authors, RFC 2223 [3]). 157 URL schemes created in the OID tree are encouraged to conform to the 158 generic URL syntax, RFC 2396, but are not required to do so. 160 All new URL schemes SHOULD follow the Guidelines for URL Schemes, 161 set forth in RFC [URL-GUIDELINES] [2]. 163 While not required, an analysis of the security issues inherent in 164 the new URL scheme is encouraged. Regardless of what security 165 analysis is or is not performed, all descriptions of security issues 166 must be as accurate as possible. In particular, a statement that 167 there are "no security issues associated with this scheme" must not 168 be confused with "the security issues associates with this scheme 169 have not been assessed". 171 There is absolutely no requirement that URL schemes created in the 172 OID tree be secure or completely free from risks. Nevertheless, all 173 known security risks SHOULD be identified. 175 The registration of a URL scheme created in the OID tree formally 176 belongs to the entity to which the OID is assigned. Changes to the 177 specification of an OID tree URL scheme which is documented by an 178 Informational RFC shall only be accepted from the owner of the OID 179 or with the permission of the owner of the OID. 181 The syntax of URL scheme names for schemes created in the OID tree 182 is simply the text string "OID-" followed by the numeric OID 183 including any embedded hyphens. URL scheme names are case 184 insensitive so the letters in the text string "OID-" need not be 185 capitalized. No variations on this formula are permitted. 187 Examples of valid URL scheme names in the OID tree: 189 OID-2-16-840-1-113779-2-1: 190 Oid-2-16-840-1-113779-2-1-100: 191 OiD-2-16-840-1-113779-3: 192 oid-2-16-840-1-113779-123: 194 4.0 Registration Procedures 196 4.1 The IETF Tree 198 The first step in registering a new URL scheme in the IETF tree is 199 to publish an IETF Internet-Draft detailing the syntax and 200 semantics of the proposed scheme. The draft must, minimally, 201 address all of the items covered by the template provided in section 202 6 of this document. 204 After all issues raised during a review period of no less than 4 205 weeks have been addressed, submit the draft to the IESG for review. 207 The IESG will review the proposed new scheme and either refer the 208 scheme to a working group (existing or new) or directly present the 209 scheme to the IESG for a last call. In the former case, the working 210 group is responsible for submitting a final version of the draft to 211 the IESG for approval at such time as it has received adequate 212 review and deliberation. 214 4.2 The OID Tree 216 Registration of URL schemes created in the OID tree is automatic 217 because the scheme name is based on a previously registered entity, 218 an OID. There is no requirement to publish any documentation for 219 the URL scheme, however, doing so may be advantageous and is 220 encouraged. 222 The recommended form for documenting a URL scheme created in the OID 223 tree is via an Informational RFC. The RFC should address all of the 224 items covered by the template provided in section 6 of this 225 document. 227 5.0 Change Control 229 5.1 Schemes in the IETF Tree 231 URL schemes created in the IETF tree are "owned" by the IETF itself 232 and may be changed, as needed, by updating the RFC that describes 233 them. Schemes described by Standards Track RFC but be replaced with 234 new Standards Track RFCs. Informational RFCs may be replaced by new 235 Informational RFCs or Standards Track RFCs. 237 5.2 Schemes in the OID Tree 239 Undocumented URL schemes created in the OID tree may be changed by 240 their owner at any time without notifying the IETF. 242 URL schemes created in the OID tree that have been documented by an 243 Informational RFC, may be changed at any time by the owner, however, 244 an updated Informational RFC which details the changes made, must be 245 submitted to the IESG. 247 The owner of a URL scheme registered in the OID tree and documented 248 by an Informational RFC may pass responsibility for the registration 249 to another person or agency by informing the IESG. 251 The IESG may reassign responsibility for a URL scheme registered in 252 the OID tree and documented by an Informational RFC. The most 253 common case of this will be to enable changes to be made to schemes 254 where the owner of the OID has died, moved out of contact or is 255 otherwise unable to make changes that are important to the 256 community. 258 The IESG may reclassify a URL scheme created in the OID tree and 259 documented via an Informational RFC as "historic" if it determines 260 that the scheme is no longer in use. 262 6.0 Registration Template 264 The following issues should be addressed when documenting a new URL 265 scheme: 267 URL scheme name. 269 URL scheme syntax. This should be expressed in a clear and 270 concise manner. The use of ABNF is encouraged. Please refer to 271 RFC [URL-GUIDELINES] for guidance on designing and explaining 272 your scheme's syntax. 274 Character encoding considerations. It is important to identify 275 what your scheme supports in this regard. It is obvious that for 276 interoperability, it is best if there is a means to support 277 character sets beyond USASCII, but especially for private 278 schemes, this may not be the case. 280 Intended usage. What sort of resource is being identified? If 281 this is not a 'resource' type of URL (e.g. mailto:), explain the 282 action that should be initiated by the consumer of the URL. If 283 there is a MIME type associated with this resource, please 284 identify it. 286 Applications and/or protocols which use this URL scheme name. 288 Interoperability considerations. If you are aware of any details 289 regarding your scheme which might impact interoperability, please 290 identify them here. For example: proprietary or uncommon 291 encoding method; inability to support multibyte character sets; 292 incompatibility with types or versions of underlying protocol 293 (if scheme is tunneled over another protocol). 295 Security considerations. 297 Relevant publications. 299 Person & email address to contact for further information. 301 Author/Change controller. 303 Applications and/or protocols which use this URL scheme name. 305 7.0 Security Considerations 307 Information that creates or updates a registration needs to be 308 authenticated. 310 Information concerning possible security vulnerabilities of a 311 protocol may change over time. Consequently, claims as to the 312 security properties of a registered URL scheme may change as well. 313 As new vulnerabilities are discovered, information about such 314 vulnerabilities may need to be attached to existing documentation, 315 so that users are not misled as to the true security properties of a 316 registered URL scheme. 318 8.0 References 320 [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 321 Identifiers (URI): Generic Syntax", RFC 2396, August 1998 323 [2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 324 "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 325 1998 327 [3] Postel, J., Reynolds, J., "Instructions to RFC Authors", 328 RFC 2223, October 1997. 330 9.0 Author's Address 332 Rich Petke 333 MCIWORLDCOM Advanced Networks 334 5000 Britton Road 335 P. O. Box 5000 336 Hilliard, OH 43026-5000 337 USA 339 Phone: +1 614 723 4157 340 Fax: +1 614 723 8407 341 EMail: rpetke@wcom.net 343 Appendix A -- Grandfathered URL Scheme Names 345 A number of URL scheme names, in use prior to 1998, would, if 346 registered under the procedures specified in this document, be 347 placed into the OID tree. Re-registration of those types to reflect 348 the appropriate tree or documentation of the schemes in an 349 Informational RFC is encouraged, but not required. Ownership and 350 change control principles outlined in this document apply to those 351 types as if they had been registered in the OID tree. 353 ABOUT: (No information available at this time.) 355 AOL: (No information available at this time.)