idnits 2.17.1 draft-ietf-urlreg-procedures-02.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 32 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-20) 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 479 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 176: '... regardless of registration tree, MUST...' RFC 2119 keyword, line 181: '... in the IETF tree, MUST conform to the...' RFC 2119 keyword, line 187: '... new URL schemes SHOULD follow the Gui...' RFC 2119 keyword, line 315: '... registrations), MUST conform to the s...' RFC 2119 keyword, line 321: '... scheme name MUST include a discussi...' (1 more instance...) 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 (July 17, 1998) is 9409 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: 'URI-SYNTAX' on line 415 -- Looks like a reference, but probably isn't: 'URL-GUIDELINES' on line 418 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2223 (ref. '3') (Obsoleted by RFC 7322) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Petke 2 WorldCom Advanced Networks 3 July 17, 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 January 15, 1999. 30 Copyright Notice 32 Copyright (C) The Internet Society (1998). All Rights Reserved. 34 Abstract 36 This document defines the process by which new URL schemes are 37 registered. 39 1.0 Introduction 41 A Uniform Resource Locator (URL) is a compact string representation 42 of the location for a resource that is available via the Internet. 43 RFC [URI-SYNTAX] [1] defines the general syntax and semantics of 44 URIs, and, by inclusion, URLs. URLs are designated by including a 45 "scheme" and then a "scheme-specific part". Many URL schemes are 46 already defined, however, new schemes may need to be defined in the 47 future in order to accommodate new Internet protocols and/or 48 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 registration procedures which use the Internet 57 Assigned Numbers Authority (IANA) as a central registry for such URL 58 scheme names and the IETF RFC mechanism for scheme review, where 59 appropriate. 61 2.0 URL Scheme Name Registration 63 Registration of a new URL scheme name starts with the construction 64 of a registration proposal. Registration may occur in several 65 different registration trees, which have different requirements as 66 discussed below. In general, the new registration proposal is 67 circulated and reviewed in a fashion appropriate to the tree 68 involved. The URL scheme name is then registered if the proposal is 69 acceptable. The following sections describe the requirements and 70 procedures used for each of the different registration trees. 72 2.1. Registration Trees and URL Schemes 74 In order to increase the efficiency and flexibility of the 75 registration process, three different formats of URL scheme names 76 may be registered. The registration requirements for each format 77 differ allowing the registration procedure to accommodate the 78 different natural requirements for URL schemes. For example, a 79 scheme that will be recommended for wide support and implementation 80 by the Internet Community requires a more complete review than a 81 scheme that is used with resources associated with proprietary 82 software. The following subsections define registration "trees" and 83 the associated URL scheme name formats available at this time. Note 84 that some URL schemes defined prior to this document do not conform 85 to the naming conventions described below. See Appendix A for a 86 discussion of those schemes. 88 2.1.1. IETF Tree 90 The IETF tree is intended for URL schemes of general interest to the 91 Internet Community. Registration in the IETF tree requires approval 92 by the IESG and publication of the URL scheme syntax and semantics 93 as some form of RFC, usually a standards track RFC. 95 URL scheme names in the IETF tree are normally denoted by names that 96 are not explicitly faceted, i.e., do not contain period (".") 97 characters. 99 The "owner" of a URL scheme name registration in the IETF tree is 100 assumed to be the IETF itself. Modification or alteration of the 101 specification requires the same level of processing (e.g. standards 102 track) as required for the initial registration. 104 2.1.2. Vendor Tree 106 The vendor tree is used for URL schemes associated with commercially 107 available products. "Vendor" or "producer" are construed as 108 equivalent and very broadly in this context. 110 A registration may be placed in the vendor tree by anyone who needs 111 to identify a scheme for (1) specifying the location of a resource 112 available via the Internet (2) which may be accessed using a 113 protocol (or mechanism) for which there is not currently a URL 114 scheme registered in the IETF tree. The registration formally 115 belongs to the vendor or organization registering the scheme name. 116 Changes to the specification will be made at their request, as 117 discussed in subsequent sections. 119 Registrations in the vendor tree will be distinguished by the 120 leading facet "vnd.". That must be followed by an IANA-approved 121 designation of the producer's name, which is then followed by a URL 122 scheme name or product designation (e.g. vnd.bigcompany.telepathic). 124 IANA will assign unique designations for producer names, 125 ("bigcompany" in the example above). Accordingly, once a producer 126 has successfully registered a scheme name, (e.g. 127 "vnd.bigcompany.telepathic"), only registrations for new scheme 128 names that originate from "bigcompany" will begin with 129 "vnd.bigcompany.". 131 While public exposure and review of URL scheme names to be 132 registered in the vendor tree is not required, using the ietf-types 133 list for review is strongly encouraged to improve the quality of 134 those specifications. Registrations in the vendor tree may be 135 submitted directly to the IANA. 137 2.1.3. Personal or Vanity Tree 139 Registrations for URL schemes created experimentally or as part of 140 products that are not distributed commercially may be registered in 141 the personal or vanity tree. The registrations are distinguished by 142 the leading facet "prs.". 144 The owner of "personal" registrations and associated specifications 145 is the person or entity making the registration, or one to whom 146 responsibility has been transferred as described below. 148 While public exposure and review of URL scheme names to be 149 registered in the personal tree is not required, using the 150 ietf-types list for review is strongly encouraged to improve the 151 quality of those specifications. Registrations in the personal tree 152 may be submitted directly to the IANA. 154 2.1.4. Additional Registration Trees 156 From time to time and as required by the community, the IANA may, 157 with the advice and consent of the IESG, create new top-level 158 registration trees. It is explicitly assumed that these trees may 159 be created for external registration and management by well-known 160 permanent bodies, such as scientific societies, for URL schemes 161 specific to the sciences they cover. In general, the quality of 162 review of specifications for one of these additional registration 163 trees is expected to be equivalent to that which IETF would give to 164 registrations in its own tree. Establishment of these new trees 165 will be announced through RFC publication approved by the IESG. 167 2.2. Registration Requirements 169 URL scheme name registration proposals are all expected to conform 170 to various requirements laid out in the following sections. Note 171 that requirement specifics sometimes vary depending on the 172 registration tree, again as detailed in the following sections. 174 2.2.1. Scheme Names 176 All new URL scheme names, regardless of registration tree, MUST 177 conform to the syntax specified for scheme names in RFC [URI-SYNTAX]. 179 2.2.2. URL Syntax 181 All new URL schemes registered in the IETF tree, MUST conform to the 182 generic syntax for URLs as specified in RFC [URI-SYNTAX]. URL 183 schemes registered in the vendor and personal trees are encouraged 184 to conform to the generic syntax but are not required to do so in 185 order to be registered. 187 All new URL schemes SHOULD follow the Guidelines for URL Schemes, 188 set forth in RFC [URL-GUIDELINES] [2]. 190 2.2.3. Security Requirements 192 An analysis of the security issues inherent in the new URL scheme is 193 required for all registrations in the IETF tree. (This is in 194 accordance with the basic requirements for all IETF protocols.) A 195 similar analysis for schemes registered in the vendor or personal 196 trees is encouraged but not required. However, regardless of what 197 security analysis has or has not been done, all descriptions of 198 security issues must be as accurate as possible regardless of 199 registration tree. In particular, a statement that there are "no 200 security issues associated with this scheme" must not be confused 201 with "the security issues associates with this scheme have not been 202 assessed". 204 There is absolutely no requirement that URL schemes registered in 205 any tree be secure or completely free from risks. Nevertheless, all 206 known security risks must be identified in the registration of a URL 207 scheme name, again regardless of registration tree. 209 The security considerations section of all registrations is subject 210 to continuing evaluation and modification, and in particular may be 211 extended by use of the "comments on URL scheme name" mechanism 212 described in subsequent sections. 214 2.2.4. Publication Requirements 216 Proposals for URL schemes registered in the IETF tree must be 217 published as RFCs. RFC publication of vendor and personal URL 218 schemes is encouraged but not required. In all cases IANA will 219 retain copies of all URL scheme proposals and "publish" them as part 220 of the URL scheme names registration tree itself. 222 Other than in the IETF tree, the registration of a URL scheme name 223 does not imply endorsement, approval, or recommendation by IANA or 224 IETF or even certification that the specification is adequate. To 225 become Internet Standards, protocol, data objects, or whatever must 226 go through the IETF standards process. This is too difficult and 227 too lengthy a process for the convenient registration of URL scheme 228 names. 230 The IETF tree exists for URL schemes that do require a substantive 231 review and approval process with the vendor and personal trees exist 232 for those that do not. It is expected that applicability statements 233 for particular applications will be published from time to time that 234 recommend implementation of, and support for, URL schemes that have 235 proven particularly useful in those contexts. 237 As discussed above, registration of a top-level type requires 238 standards-track processing and, hence, RFC publication. 240 2.3. Registration Procedure 242 The following procedure has been implemented by the IANA for review 243 and approval of new URL scheme names. This is not a formal 244 standards process, but rather an administrative procedure intended 245 to allow community comment and sanity checking without excessive 246 time delay. For registration in the IETF tree, the normal IETF 247 processes should be followed, treating posting of an internet-draft 248 and announcement on the ietf-types list (as described in the next 249 subsection) as a first step. For registrations in the vendor or 250 personal tree, the initial review step described below may be 251 omitted and the URL scheme name may be registered directly by 252 submitting the template and an explanation directly to IANA 253 (at iana@iana.org). However, authors of vendor or personal URL 254 scheme specifications are encouraged to seek community review and 255 comment whenever that is feasible. 257 2.3.1. Present the URL scheme name to the Community for Review 259 Send a proposed URL scheme name registration to the 260 "ietf-types@iana.org" mailing list for a two week review period. 261 This mailing list has been established for the purpose of reviewing 262 proposed URL schemes. URL scheme names proposed to this mailing 263 list are not formally registered and should not be used until the 264 registration procedure is complete. 266 The intent of the public posting is to solicit comments and feedback 267 on the choice of scheme name, the syntax and semantics of the 268 scheme, and a review of any interoperability or security 269 considerations. The submitter may submit a revised registration, or 270 withdraw the registration completely, at any time. 272 2.3.2. IESG Approval 274 URL scheme names registered in the IETF tree must be submitted to 275 the IESG for approval. 277 2.3.3. IANA Registration 279 Provided that the URL scheme name meets the requirements for URL 280 scheme names and has obtained approval that is necessary, the author 281 may submit the registration request to the IANA, which will register 282 the scheme name and make the URL scheme name registration available 283 to the community. 285 2.4. Comments on URL Scheme Name Registrations 287 Comments on registered URL scheme names may be submitted by members 288 of the community to IANA. These comments will be passed on to the 289 "owner" of the URL scheme name if possible. Submitters of comments 290 may request that their comment be attached to the URL scheme name 291 registration itself, and if IANA approves of this the comment will 292 be made accessible in conjunction with the scheme name registration 293 itself. 295 2.5. Location of Registered URL Scheme Name List 297 URL scheme name registrations will be posted in the anonymous FTP 298 directory 299 "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/". 300 The scheme syntax and semantics description and other supporting 301 material may also be published as an Informational RFC by sending it 302 to the RFC Editor (please follow the instructions to RFC authors, 303 RFC-2223 [3]). 305 2.6. IANA Procedures for Registering URL scheme names 307 The IANA will only register URL scheme names in the IETF tree in 308 response to a communication from the IESG stating that a given 309 registration has been approved. Vendor and personal types will be 310 registered by the IANA automatically and without any formal review 311 as long as the following minimal conditions are met: 313 Scheme Name Syntax: The syntax of the requested scheme name 314 (including the assigned producer designation in the case of vendor 315 tree registrations), MUST conform to the syntax for such as 316 specified in RFC [URI-SYNTAX]. While encouraged, the syntax for the 317 actual scheme does not have to conform to the general syntax 318 specified in RFC [URI-SYNTAX]. 320 Security Considerations: The application for registration of a 321 scheme name MUST include a discussion of the security 322 considerations inherent in the scheme. 324 Contact Person: The application MUST include accurate information 325 regarding a person to contact about the registration. 327 Author/Change Controller: The application must specify the author 328 and/or entity responsible for change control of the proposed scheme. 330 For vendor tree registrations, IANA will assign unique designations 331 to each producer registering one or more scheme names. 333 2.7. Change Control 335 Once a URL scheme name has been published by IANA, the author may 336 request a change to its definition. The descriptions of the 337 different registration trees above designate the "owners" of each 338 type of registration. The change request follows the same 339 procedure as the registration request: 341 (1) Publish the revised scheme syntax and semantics on the 342 ietf-types list. 344 (2) Leave at least two weeks for comments. 346 (3) Publish using IANA after formal review if required. 348 Changes should be requested only when there are serious omission or 349 errors in the published specification. When review is required, a 350 change request may be denied if it renders entities that were valid 351 under the previous definition invalid under the new definition. 353 The owner of a URL scheme registration may pass responsibility for 354 the registration to another person or agency by informing IANA and 355 the ietf-types list; this can be done without discussion or review. 357 The IESG may reassign responsibility for a URL scheme name. The 358 most common case of this will be to enable changes to be made to 359 schemes where the author of the registration has died, moved out of 360 contact or is otherwise unable to make changes that are important to 361 the community. 363 URL scheme name registrations may not be deleted; URL scheme names 364 which are no longer believed appropriate for use can be declared 365 OBSOLETE by a change to their "intended use" field; such URL scheme 366 names will be clearly marked in the lists published by IANA. 368 2.8. Registration Template 370 To: ietf-types@iana.org 371 Subject: Registration of URL Scheme Name 373 URL Scheme Name: 375 Security considerations: 377 Interoperability considerations: 379 Published specification: 381 Applications which use this URL scheme name: 383 Additional information: 385 Person & email address to contact for further information: 387 Intended usage: 389 (One of COMMON, LIMITED USE or OBSOLETE) 391 Author/Change controller: 393 (Any other information that the author deems interesting may be 394 added below this line.) 396 3.0 Security Considerations 398 Information that creates or updates a registration needs to be 399 authenticated. 401 Information concerning possible security vulnerabilities of a 402 protocol may change over time. Consequently, claims as to the 403 security properties of a registered URL scheme may change as well. 404 As new vulnerabilities are discovered, information about such 405 vulnerabilities may need to be attached to existing registrations, 406 so that users are not misled as to the true security properties of a 407 registered URL scheme. 409 Delegations of a name space should only be assigned to someone with 410 adequate security. 412 4.0 References 414 [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 415 Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], August 1998 417 [2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 418 "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 1998 420 [3] Postel, J., Reynolds, J., "Instructions to RFC Authors", 421 RFC 2223, October 1997. 423 5.0 Author's Address 425 Rich Petke 426 WorldCom Advanced Networks 427 5000 Britton Road 428 P. O. Box 5000 429 Hilliard, OH 43026-5000 430 USA 432 Phone: +1 614 723 4157 433 Fax: +1 614 723 1333 434 EMail: rpetke@compuserve.net 436 Appendix A -- Grandfathered URL Scheme Names 438 A number of URL scheme names, in use prior to 1998, would, if 439 registered under the guidelines in this document, be placed into 440 either the vendor or personal trees. Re-registration of those types 441 to reflect the appropriate trees is encouraged, but not required. 442 Ownership and change control principles outlined in this document 443 apply to those types as if they had been registered in the trees 444 described above. 446 ABOUT: 448 AOL: