idnits 2.17.1 draft-ietf-urlreg-procedures-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 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 445 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** 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 165: '... regardless of registration tree, MUST...' RFC 2119 keyword, line 171: '... in the IETF tree, MUST conform to the...' 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 (April 30, 1998) is 9493 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 section? 'URI-SYNTAX' on line 388 looks like a reference -- Missing reference section? 'URL-GUIDELINES' on line 390 looks like a reference -- Missing reference section? 'RFC-1543' on line 295 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Rich Petke 2 CompuServe Network Services 3 April 30, 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 view the entire list of current Internet-Drafts, please check 20 the "1id-abstracts.txt" listing contained in the Internet-Drafts 21 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 22 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 23 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 24 (US West Coast). 26 Distribution of this memo is unlimited. 28 This Internet Draft expires October 31, 1998. 30 Abstract 32 This document defines the process by which new URL schemes are 33 registered. 35 1.0 Introduction 37 A Uniform Resource Locator (URL) is a compact string representation 38 of the location for a resource that is available via the Internet. 39 RFC [URI-SYNTAX] defines the general syntax and semantics of URIs, 40 and, by inclusion, URLs. URLs are designated by including a 41 "scheme" and then a "scheme-specific part". Many URL schemes are 42 already defined, however, new schemes may need to be defined in the 43 future in order to accommodate new Internet protocols and/or 44 procedures. 46 A registration process is needed to ensure that the names of all 47 such new schemes are guaranteed not to collide. Further, the 48 registration process ensures that URL schemes intended for wide 49 spread, public use are developed in an orderly, well-specified, 50 and public manner. 52 This document defines registration procedures which use the Internet 53 Assigned Numbers Authority (IANA) as a central registry for such URL 54 scheme names and the IETF RFC mechanism for scheme review, where 55 appropriate. 57 2.0 URL Scheme Name Registration 59 Registration of a new URL scheme name starts with the construction 60 of a registration proposal. Registration may occur in several 61 different registration trees, which have different requirements as 62 discussed below. In general, the new registration proposal is 63 circulated and reviewed in a fashion appropriate to the tree 64 involved. The URL scheme name is then registered if the proposal is 65 acceptable. The following sections describe the requirements and 66 procedures used for each of the different registration trees. 68 2.1. Registration Trees and URL Schemes 70 In order to increase the efficiency and flexibility of the 71 registration process, three different formats of URL scheme names 72 may be registered. The registration requirements for each format 73 differ allowing the registration procedure to accommodate the 74 different natural requirements for URL schemes. For example, a 75 scheme that will be recommended for wide support and implementation 76 by the Internet Community requires a more complete review than a 77 scheme that is used with resources associated with proprietary 78 software. The following subsections define registration "trees" and 79 the associated URL scheme name formats available at this time. Note 80 that some URL schemes defined prior to this document do not conform 81 to the naming conventions described below. See Appendix A for a 82 discussion of those schemes. 84 2.1.1. IETF Tree 86 The IETF tree is intended for URL schemes of general interest to the 87 Internet Community. Registration in the IETF tree requires approval 88 by the IESG and publication of the URL scheme syntax and semantics 89 as some form of RFC, usually a standards track RFC. 91 URL scheme names in the IETF tree are normally denoted by names that 92 are not explicitly faceted, i.e., do not contain period (".") 93 characters. 95 The "owner" of a URL scheme name registration in the IETF tree is 96 assumed to be the IETF itself. Modification or alteration of the 97 specification requires the same level of processing (e.g. standards 98 track) as required for the initial registration. 100 2.1.2. Vendor Tree 102 The vendor tree is used for URL schemes associated with commercially 103 available products. "Vendor" or "producer" are construed as 104 equivalent and very broadly in this context. 106 A registration may be placed in the vendor tree by anyone who needs 107 to identify a scheme for (1) specifying the location of a resource 108 available via the Internet (2) which may be accessed using a 109 protocol for which there is not currently a URL scheme registered. 110 The registration formally belongs to the vendor or organization 111 registering the scheme name. Changes to the specification will be 112 made at their request, as discussed in subsequent sections. 114 Registrations in the vendor tree will be distinguished by the 115 leading facet "vnd.". That must be followed by an IANA-approved 116 designation of the producer's name, which is then followed by a URL 117 scheme name or product designation 118 (e.g., vnd.bigcompany.funnypictures). 120 While public exposure and review of URL scheme names to be 121 registered in the vendor tree is not required, using the ietf-types 122 list for review is strongly encouraged to improve the quality of 123 those specifications. Registrations in the vendor tree may be 124 submitted directly to the IANA. 126 2.1.3. Personal or Vanity Tree 128 Registrations for URL schemes created experimentally or as part of 129 products that are not distributed commercially may be registered in 130 the personal or vanity tree. The registrations are distinguished by 131 the leading facet "prs.". 133 The owner of "personal" registrations and associated specifications 134 is the person or entity making the registration, or one to whom 135 responsibility has been transferred as described below. 137 While public exposure and review of URL scheme names to be 138 registered in the personal tree is not required, using the 139 ietf-types list for review is strongly encouraged to improve the 140 quality of those specifications. Registrations in the personal tree 141 may be submitted directly to the IANA. 143 2.1.4. Additional Registration Trees 145 From time to time and as required by the community, the IANA may, 146 with the advice and consent of the IESG, create new top-level 147 registration trees. It is explicitly assumed that these trees may 148 be created for external registration and management by well-known 149 permanent bodies, such as scientific societies, for URL schemes 150 specific to the sciences they cover. In general, the quality of 151 review of specifications for one of these additional registration 152 trees is expected to be equivalent to that which IETF would give to 153 registrations in its own tree. Establishment of these new trees will 154 be announced through RFC publication approved by the IESG. 156 2.2. Registration Requirements 158 URL scheme name registration proposals are all expected to conform 159 to various requirements laid out in the following sections. Note 160 that requirement specifics sometimes vary depending on the 161 registration tree, again as detailed in the following sections. 163 2.2.1. Scheme Names 165 All new URL scheme names, regardless of registration tree, MUST 166 conform to the syntax specified for scheme names in RFC 167 [URI-SYNTAX]. 169 2.2.2. URL Syntax 171 All new URL schemes registered in the IETF tree, MUST conform to the 172 generic syntax for URLs as specified in RFC [URI-SYNTAX]. URL 173 schemes registered in the vendor and personal trees are encouraged 174 to conform to the generic syntax but are not required to do so in 175 order to be registered. 177 All new URL schemes should follow the Guidelines for URL Schemes, 178 set forth in RFC [URL-GUIDELINES]. 180 2.2.3. Security Requirements 182 An analysis of the security issues inherent in the new URL scheme is 183 required for all registrations in the IETF tree. (This is in 184 accordance with the basic requirements for all IETF protocols.) A 185 similar analysis for schemes registered in the vendor or personal 186 trees is encouraged but not required. However, regardless of what 187 security analysis has or has not been done, all descriptions of 188 security issues must be as accurate as possible regardless of 189 registration tree. In particular, a statement that there are "no 190 security issues associated with this scheme" must not be confused 191 with "the security issues associates with this scheme have not been 192 assessed". 194 There is absolutely no requirement that URL schemes registered in 195 any tree be secure or completely free from risks. Nevertheless, all 196 known security risks must be identified in the registration of a URL 197 scheme name, again regardless of registration tree. 199 The security considerations section of all registrations is subject 200 to continuing evaluation and modification, and in particular may be 201 extended by use of the "comments on URL scheme name" mechanism 202 described in subsequent sections. 204 2.2.4. Publication Requirements 206 Proposals for URL schemes registered in the IETF tree must be 207 published as RFCs. RFC publication of vendor and personal URL 208 schemes is encouraged but not required. In all cases IANA will 209 retain copies of all URL scheme proposals and "publish" them as part 210 of the URL scheme names registration tree itself. 212 Other than in the IETF tree, the registration of a URL scheme name 213 does not imply endorsement, approval, or recommendation by IANA or 214 IETF or even certification that the specification is adequate. To 215 become Internet Standards, protocol, data objects, or whatever must 216 go through the IETF standards process. This is too difficult and 217 too lengthy a process for the convenient registration of URL scheme 218 names. 220 The IETF tree exists for URL schemes that do require a substantive 221 review and approval process with the vendor and personal trees exist 222 for those that do not. It is expected that applicability statements 223 for particular applications will be published from time to time that 224 recommend implementation of, and support for, URL schemes that have 225 proven particularly useful in those contexts. 227 As discussed above, registration of a top-level type requires 228 standards-track processing and, hence, RFC publication. 230 2.3. Registration Procedure 232 The following procedure has been implemented by the IANA for review 233 and approval of new URL scheme names. This is not a formal 234 standards process, but rather an administrative procedure intended 235 to allow community comment and sanity checking without excessive 236 time delay. For registration in the IETF tree, the normal IETF 237 processes should be followed, treating posting of an internet-draft 238 and announcement on the ietf-types list (as described in the next 239 subsection) as a first step. For registrations in the vendor or 240 personal tree, the initial review step described below may be 241 omitted and the URL scheme name may be registered directly by 242 submitting the template and an explanation directly to IANA (at 243 iana@iana.org). However, authors of vendor or personal URL scheme 244 specifications are encouraged to seek community review and comment 245 whenever that is feasible. 247 2.3.1. Present the URL Scheme Name to the Community for Review 249 Send a proposed URL scheme name registration to the 250 "ietf-types@iana.org" mailing list for a two week review period. 251 This mailing list has been established for the purpose of reviewing 252 proposed URL schemes. URL scheme names proposed to this mailing 253 list are not formally registered and should not be used until the 254 registration procedure is complete. 256 The intent of the public posting is to solicit comments and feedback 257 on the choice of scheme name, the syntax and semantics of the 258 scheme, and a review of any interoperability or security 259 considerations. The submitter may submit a revised registration, or 260 withdraw the registration completely, at any time. 262 2.3.2. IESG Approval 264 URL scheme names registered in the IETF tree must be submitted to 265 the IESG for approval. 267 2.3.3. IANA Registration 269 Provided that the URL scheme name meets the requirements for URL 270 scheme names and has obtained approval that is necessary, the author 271 may submit the registration request to the IANA, which will register 272 the scheme name and make the URL scheme name registration available 273 to the community. 275 2.4. Comments on URL Scheme Name Registrations 277 Comments on registered URL scheme names may be submitted by members 278 of the community to IANA. These comments will be passed on to the 279 "owner" of the URL scheme name if possible. Submitters of comments 280 may request that their comment be attached to the URL scheme name 281 registration itself, and if IANA approves of this the comment will 282 be made accessible in conjunction with the scheme name registration 283 itself. 285 2.5. Location of Registered URL Scheme Name List 287 URL scheme name registrations will be posted in the anonymous FTP 288 directory 289 "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/" and 290 all registered URL scheme names will be listed in the periodically 291 issued "Assigned Numbers" RFC [currently STD 2, RFC 1700]. The 292 scheme syntax and semantics description and other supporting 293 material may also be published as an Informational RFC by sending it 294 to "rfc-editor@isi.edu" (please follow the instructions to RFC 295 authors [RFC-1543]). 297 2.6. IANA Procedures for Registering URL scheme names 299 The IANA will only register URL scheme names in the IETF tree in 300 response to a communication from the IESG stating that a given 301 registration has been approved. Vendor and personal types will be 302 registered by the IANA automatically and without any formal review 303 as long as the following minimal conditions are met: 305 o Security considerations 306 o TBD 308 2.7. Change Control 310 Once a URL scheme name has been published by IANA, the author may 311 request a change to its definition. The descriptions of the 312 different registration trees above designate the "owners" of each 313 type of registration. The change request follows the same procedure 314 as the registration request: 316 (1) Publish the revised template on the ietf-types list. 318 (2) Leave at least two weeks for comments. 320 (3) Publish using IANA after formal review if required. 322 Changes should be requested only when there are serious omission or 323 errors in the published specification. When review is required, a 324 change request may be denied if it renders entities that were valid 325 under the previous definition invalid under the new definition. 327 The owner of a URL scheme registration may pass responsibility for 328 the registration to another person or agency by informing IANA and 329 the ietf-types list; this can be done without discussion or review. 331 The IESG may reassign responsibility for a URL scheme name. The most 332 common case of this will be to enable changes to be made to schemes 333 where the author of the registration has died, moved out of contact 334 or is otherwise unable to make changes that are important to the 335 community. 337 URL scheme name registrations may not be deleted; URL scheme names 338 which are no longer believed appropriate for use can be declared 339 OBSOLETE by a change to their "intended use" field; such URL scheme 340 names will be clearly marked in the lists published by IANA. 342 2.8. Registration Template 344 To: ietf-types@iana.org 345 Subject: Registration of URL Scheme Name XXX 347 URL Scheme Name: 349 Security considerations: 351 Interoperability considerations: 353 Published specification: 355 Applications which use this URL scheme name: 357 Additional information: 359 Person & email address to contact for further information: 361 Intended usage: 363 (One of COMMON, LIMITED USE or OBSOLETE) 365 Author/Change controller: 367 (Any other information that the author deems interesting may be 368 added below this line.) 370 3.0 Security Considerations 372 Information that creates or updates a registration needs to be 373 authenticated. 375 Information concerning possible security vulnerabilities of a 376 protocol may change over time. Consequently, claims as to the 377 security properties of a registered URL scheme may change as well. 378 As new vulnerabilities are discovered, information about such 379 vulnerabilities may need to be attached to existing registrations, 380 so that users are not misled as to the true security properties of a 381 registered URL scheme. 383 Delegations of a name space should only be assigned to someone with 384 adequate security. 386 4.0 References 388 RFC [URI-SYNTAX] 390 RFC [URL-GUIDELINES] 392 5.0 Author's Address 394 Rich Petke 395 CNS/WorldCom 396 5000 Britton Road 397 P. O. Box 5000 398 Hilliard, OH 430 399 USA 401 Phone: +1 614 723 4157 402 Fax: +1 614 723 1333 403 EMail: rpetke@compuserve.net 405 Appendix A -- Grandfathered URL Scheme Names 407 A number of URL scheme names, in use prior to 1998, would, if 408 registered under the guidelines in this document, be placed into 409 either the vendor or personal trees. Re-registration of those 410 types to reflect the appropriate trees is encouraged, but not 411 required. Ownership and change control principles outlined in this 412 document apply to those types as if they had been registered in the 413 trees described above.