idnits 2.17.1 draft-ietf-urlreg-procedures-03.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-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 604 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 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 98: '... regardless of registration tree, MUST...' RFC 2119 keyword, line 121: '... in the IETF tree, MUST conform to the...' RFC 2119 keyword, line 125: '... REQUIRED. (This is in accordance w...' RFC 2119 keyword, line 186: '... new URL schemes SHOULD follow the Gui...' RFC 2119 keyword, line 199: '...n security risks SHOULD be identified ...' (7 more instances...) 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 (August 7, 1998) is 9394 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 549 -- Looks like a reference, but probably isn't: 'URL-GUIDELINES' on line 552 -- 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: 9 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 August 7, 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 February 7, 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 ":" and then a "". Many URL schemes 46 are already defined, however, new schemes may need to be defined in 47 the 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 In order to increase the efficiency and flexibility of the URL 64 scheme name registration process, several different registration 65 "trees" have been created. The registration requirements and 66 specific registration procedures for each tree differ, allowing the 67 overall registration procedure to accommodate the different natural 68 requirements for URL schemes. For example, a scheme that will be 69 recommended for wide support and implementation by the Internet 70 Community requires a more complete review, prior to registration, 71 than a scheme intended to be used for resources associated with 72 proprietary software. 74 Each of the URL scheme name registration trees also imparts a 75 specific syntax to the scheme name being registered. 77 Registration of a new URL scheme name may occur in any ONE of the 78 established registration trees. 80 The first step in registering a new URL scheme name is to determine 81 which registration tree the scheme should be registered in. 82 Determination of the proper registration tree is based on the 83 intended use for the new scheme, the desired syntax for the scheme 84 name, and the ability to meet the registration requirements for the 85 desired tree. 87 Note that some URL schemes defined prior to this document do not 88 conform to the naming conventions described below. See Appendix A 89 for a discussion of those schemes. 91 The following subsections define the registration trees available at 92 this time, the purpose of each tree, the requirements for 93 registration in each tree, and the associated URL scheme name 94 formats that are applied to names registered in each tree. 96 2.1 General Requirements 98 All new URL scheme NAMES, regardless of registration tree, MUST 99 conform to the syntax specified in RFC [URI-SYNTAX] for scheme 100 names. 102 2.2 The IETF Tree 104 2.2.1 Purpose 106 The IETF tree is intended for URL schemes of general interest to the 107 Internet Community. The tree exists for URL schemes that require a 108 substantive review and approval process; the vendor and personal 109 trees exist for those that do not. It is expected that 110 applicability statements for particular applications will be 111 published from time to time that recommend implementation of, and 112 support for, URL schemes that have proven particularly useful in 113 those contexts. 115 2.2.2 Registration Requirements 117 Registration in the IETF tree requires approval by the IESG and 118 publication of the URL scheme syntax and semantics as some form of 119 RFC, usually a standards track RFC. 121 All new URL schemes registered in the IETF tree, MUST conform to the 122 generic syntax for URLs as specified in RFC [URI-SYNTAX]. 124 An analysis of the security issues inherent in the new URL scheme is 125 REQUIRED. (This is in accordance with the basic requirements for 126 all IETF protocols.) There is absolutely no requirement that all 127 URL schemes registered in the IETF tree be secure or completely free 128 from risks. Nevertheless, all known security risks must be 129 identified. 131 The security considerations section of all registrations is subject 132 to continuing evaluation and modification, and in particular may be 133 extended by use of the "comments on URL scheme names" mechanism 134 described in section 4.0. 136 2.2.3 Ownership 138 The "owner" of a URL scheme name registration in the IETF tree is 139 assumed to be the IETF itself. Modification or alteration of the 140 specification requires the same level of processing (e.g. standards 141 track) as required for the initial registration. 143 2.2.4 Syntax of URL Scheme Names 145 URL scheme names in the IETF tree are normally denoted by names that 146 are not explicitly faceted, i.e., do not contain period (".") 147 characters. For example, "http", "ftp", "mailto", etc. 149 2.3 The Vendor Tree 151 2.3.1 Purpose 153 The vendor tree is used for URL schemes associated with commercially 154 available products. "Vendor" or "producer" are construed as 155 equivalent and very broadly in this context. 157 A registration may be placed in the vendor tree by anyone who needs 158 to identify a scheme for (1) specifying the location of a resource 159 available via the Internet (2) which may be accessed using a 160 protocol (or mechanism) for which there is not currently a URL 161 scheme registered in the IETF tree. 163 The registration of a URL scheme name in the vendor tree does not 164 imply endorsement, approval, or recommendation by IANA or IETF or 165 even certification that the specification is adequate. To become 166 Internet Standards, protocol, data objects, or whatever must go 167 through the IETF standards process and the registration in the IETF 168 tree. 170 2.3.2 Registration Requirements 172 RFC publication of vendor URL schemes is encouraged but not 173 required. Material may be published as an Informational RFC by 174 sending it to the RFC Editor (please follow the instructions to RFC 175 authors, RFC-2223 [3]). 177 While public exposure and review of URL scheme names to be 178 registered in the vendor tree is not required, using the 179 ietf-url-schemes list for review is strongly encouraged to improve 180 the quality of those specifications. 182 URL schemes registered in the vendor tree are encouraged to conform 183 to the generic URL syntax but are not required to do so in order to 184 be registered. 186 All new URL schemes SHOULD follow the Guidelines for URL Schemes, 187 set forth in RFC [URL-GUIDELINES] [2]. 189 While not required, an analysis of the security issues inherent in 190 the new URL scheme is encouraged. Regardless of what security 191 analysis is or is not performed, all descriptions of security issues 192 must be as accurate as possible. In particular, a statement that 193 there are "no security issues associated with this scheme" must not 194 be confused with "the security issues associates with this scheme 195 have not been assessed". 197 There is absolutely no requirement that URL schemes registered in 198 the vendor tree be secure or completely free from risks. 199 Nevertheless, all known security risks SHOULD be identified in the 200 registration. 202 The security considerations section of all registrations is subject 203 to continuing evaluation and modification, and in particular may be 204 extended by use of the "comments on URL scheme name" mechanism 205 described in section 4.0. 207 2.3.3 Ownership of Registration 209 The registration formally belongs to the vendor or organization 210 registering the scheme name. Changes to the specification will be 211 made at their request, as discussed in subsequent sections. 213 2.3.4 Syntax of URL Scheme Names 215 Registrations in the vendor tree will be distinguished by the 216 leading facet "vnd.". That must be followed by an IANA-approved 217 designation of the producer's name, which is then followed by a URL 218 scheme name or product designation (e.g. vnd.bigcompany.telepathic). 220 IANA will assign unique designations for producer names, 221 ("bigcompany" in the example above). Accordingly, once a producer 222 has successfully registered a scheme name, 223 (e.g. "vnd.bigcompany.telepathic"), only registrations for new 224 scheme names that originate from "bigcompany" will begin with 225 "vnd.bigcompany.". 227 2.4 The Personal or Private Tree 229 2.4.1 Purpose 231 Registrations for URL schemes created experimentally or as part of 232 products that are not distributed commercially may be registered in 233 the personal tree. Unlike the IETF and vendor trees which guarantee 234 the uniqueness of registered scheme names, registrations in the 235 personal tree are NOT guaranteed to be unique. Multiple sites may 236 register the same scheme name but use it in different (and 237 incompatible) ways. 239 The registration of a URL scheme name in the personal tree does not 240 imply endorsement, approval, or recommendation by IANA or IETF or 241 even certification that the specification is adequate. To become 242 Internet Standards, protocol, data objects, or whatever must go 243 through the IETF standards process and the registration in the IETF 244 tree. 246 2.4.2 Registration Requirements 248 RFC publication of personal URL schemes is encouraged but not 249 required. Materials may be published as an Informational RFC by 250 sending it to the RFC Editor (please follow the instructions to RFC 251 authors, RFC-2223 [3]). 253 While public exposure and review of URL scheme names to be 254 registered in the personal tree is not required, using the 255 ietf-url-schemes list for review is strongly encouraged to improve 256 the quality of those specifications. 258 URL schemes registered in the personal tree are encouraged to 259 conform to the generic URL syntax but are not required to do so in 260 order to be registered. 262 All new URL schemes SHOULD follow the Guidelines for URL Schemes, 263 set forth in RFC [URL-GUIDELINES] [2]. 265 While not required, an analysis of the security issues inherent in 266 the new URL scheme is encouraged. Regardless of what security 267 analysis is or is not performed, all descriptions of security issues 268 must be as accurate as possible. In particular, a statement that 269 there are "no security issues associated with this scheme" must not 270 be confused with "the security issues associates with this scheme 271 have not been assessed". 273 There is absolutely no requirement that URL schemes registered in 274 the personal tree be secure or completely free from risks. 275 Nevertheless, all known security risks SHOULD be identified in the 276 registration. 278 The security considerations section of all registrations is subject 279 to continuing evaluation and modification, and in particular may be 280 extended by use of the "comments on URL scheme name" mechanism 281 described in section 4.0. 283 2.4.3 Ownership of Registration 285 The owner of "personal" registrations and associated specifications 286 is the person or entity making the registration, or one to whom 287 responsibility has been transferred as described below. 289 2.4.4 Syntax of URL Scheme Names 291 Registrations in the personal tree are distinguished by the leading 292 facet "prs.". For example, "prs.fiberreflection". 294 2.5 Additional Registration Trees 296 From time to time and as required by the community, the IANA may, 297 with the advice and consent of the IESG, create new top-level 298 registration trees. It is explicitly assumed that these trees may 299 be created for external registration and management by well-known 300 permanent bodies, such as scientific societies, for URL schemes 301 specific to the sciences they cover. In general, the quality of 302 review of specifications for one of these additional registration 303 trees is expected to be equivalent to that which IETF would give to 304 registrations in its own tree. Establishment of these new trees 305 will be announced through RFC publication approved by the IESG. 307 3.0 Registration Procedures 309 The following sections detail the procedures to follow to register a 310 new URL scheme name in a specific registration tree. With the 311 exception of registration in the IETF tree, these procedures are not 312 a formal standards process, but rather an administrative procedure 313 intended to allow community comment and sanity checking without 314 excessive time delay. 316 3.1 The IETF Tree 318 Complete the registration template (section 7.0 of this document) 319 and submit it to the IESG for review. Generally the details of 320 the proposed new URL scheme should already be documented in an 321 Internet-Draft and the registration template should reference this 322 draft. 324 The IESG will review the proposed new scheme and either refer the 325 scheme to a working group (existing or new) or directly present the 326 registration and associated documentation to the IESG for a last 327 call. In the former case, the working group is responsible for 328 re-submitting it to the IESG for approval at such time as it has 329 received adequate review and deliberation. 331 After the IESG has approved the registration, it will forward the 332 registration paperwork and documentation to IANA for publication on 333 the ietf-url-schemes list and official registration in the IETF 334 tree. 336 Authors proposing new URL schemes for the IETF tree are encouraged 337 to present the proposed schemes to the IETF as a whole, via the 338 Internet-Drafts mechanism, well in advance of submission to the 339 IESG. 341 3.2 The Vendor Tree 343 Complete the registration template (section 7.0 of this document) as 344 completely as possible. 346 While not required, it is recommended and encouraged that vendors 347 submit a copy of the completed registration template (which includes 348 references to any additional documentation), to the ietf-url-schemes 349 list for peer review and comment. The quality of URL schemes can 350 usually be improved through such a process. The amount of feedback 351 received regarding the proposed scheme should serve as an indication 352 of how long to keep the proposal in peer review before proceeding 353 with the registration. 355 Forward the completed registration template to IANA (iana@iana.org). 357 IANA will review the registration template to ensure that it meets 358 the requirements necessary for registration. If it does not meet 359 the necessary requirements, the application will be rejected and 360 returned to the submitter and the registration process will be 361 terminated. Authors may choose to amend the information presented 362 in the registration template and re-submit it to IANA who will treat 363 the re-submission as a new registration request. 365 IANA will assign the unique designation for the producer's name at 366 this time if one has not already been assigned to the producer 367 making the registration request. 369 Regardless of whether or not the accepted registration template has 370 previously been posted to the ietf-url-schemes list for review, IANA 371 will post the template to the list along with an indication that the 372 template has been officially received by IANA for registration. 373 IANA will then wait for two (2) weeks for comments on and community 374 review of the registration request. 376 The intent of the public posting is to solicit comments and feedback 377 on the choice of scheme name, the syntax and semantics of the 378 scheme, and a review of any interoperability or security 379 considerations (if such information is disclosed in the application 380 or associated documentation). 382 IANA will forward all comments received during this review period to 383 the person designated as the contact person in the registration 384 template. 386 The submitter may submit a revised registration, or withdraw the 387 registration completely, at any time. 389 After the two week review period has expired, IANA shall register 390 the URL scheme name in the vendor tree. 392 URL scheme names proposed to this mailing list are not formally 393 registered and should not be used until the registration procedure 394 is completed by IANA. 396 3.3 The Personal Tree 398 The registration procedure for URL scheme names in the personal tree 399 is identical as that specified for the vendor tree with the 400 exception of IANA assigning the vendor a unique name. 402 4.0 Comments on URL Scheme Name Registrations 404 Comments on registered URL scheme names may be submitted by members 405 of the community to IANA. These comments will be passed on to the 406 "owner" of the URL scheme name if possible. Submitters of comments 407 may request that their comment be attached to the URL scheme name 408 registration itself, and if IANA approves of this the comment will 409 be made accessible in conjunction with the scheme name registration 410 itself. 412 5.0 Change Control 414 Once a URL scheme name has been published by IANA, the owner of the 415 scheme name may request a change to its definition. The descriptions 416 of the different registration trees above designate the owners of 417 each type of registration. The change request follows the same 418 procedure as the registration request: 420 (1) Complete the registration template. 422 (2) Publish the revised scheme syntax and semantics on the 423 ietf-url-schemes list if peer review is requested. 425 (3) Submit the revised registration to IANA. 427 Changes should be requested only when there are serious omission or 428 errors in the published specification. When review is required, a 429 change request may be denied if it renders entities that were valid 430 under the previous definition invalid under the new definition. 432 The owner of a URL scheme registration may pass responsibility for 433 the registration to another person or agency by informing IANA and 434 the ietf-url-schemes list; this can be done without discussion or 435 review. 437 The IESG may reassign responsibility for a URL scheme name. The 438 most common case of this will be to enable changes to be made to 439 schemes where the author of the registration has died, moved out of 440 contact or is otherwise unable to make changes that are important to 441 the community. 443 URL scheme name registrations may not be deleted; URL scheme names 444 which are no longer believed appropriate for use can be declared 445 OBSOLETE by a change to their "intended use" field; such URL scheme 446 names will be clearly marked in the lists published by IANA. 448 6.0 IANA Considerations 450 6.1 Discussion List 452 A discussion list named "ietf-url-schemes" needs to be created and 453 maintained at "iana.org". The list MUST be open and MUST NOT 454 require the submitter to be subscribed to the list in order to 455 process a post. 457 6.2 Location of Registered URL Scheme Name List 459 URL scheme name registrations need to be posted in the anonymous 460 FTP directory 461 "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/". 463 6.3 Procedures for Registering URL Scheme Names 465 Scheme names in the IETF tree will only be registered in response 466 to a communication from the IESG stating that a given registration 467 has been approved. 469 Scheme names in the vendor tree will be registered automatically 470 provided that the registration template contains at least the 471 information specified below. Assignment of unique scheme names 472 shall be on a first come, first served basis. 474 Scheme names in the personal tree will be registered automatically 475 provided that the registration template contains at least the 476 information specified below. No attempt shall be made to prevent 477 multiple applications from registering the same scheme name even if 478 the use of the schemes are different and incompatible. 480 The following minimal information must be specified for a 481 registration in the vendor or personal tree: 483 Scheme Name Syntax: The syntax of the requested scheme name 484 (including the assigned producer designation in the case of vendor 485 tree registrations), MUST conform to the syntax for such as 486 specified in RFC [URI-SYNTAX]. While encouraged to do so, the 487 syntax for the actual scheme does not have to conform to the 488 general syntax specified in RFC [URI-SYNTAX]. 490 Security Considerations: The application for registration of a 491 scheme name MUST include a discussion of the security considerations 492 inherent in the scheme. 494 Contact Person: The application MUST include accurate information 495 regarding a person to contact about the registration. 497 Author/Change Controller: The application MUST specify the author 498 and/or entity responsible for change control of the proposed scheme. 500 7.0 Registration Template 502 To: iana@iana.org 503 Subject: Registration of URL Scheme Name 505 URL Scheme Name: 507 Character encoding considerations: 509 Security considerations: 511 Interoperability considerations: 513 Published specification: 515 Applications which use this URL scheme name: 517 Additional information: 519 Person & email address to contact for further information: 521 Intended usage: 523 (One of COMMON, LIMITED USE or OBSOLETE) 525 Author/Change controller: 527 (Any other information that the author deems interesting may be 528 added below this line.) 530 8.0 Security Considerations 532 Information that creates or updates a registration needs to be 533 authenticated. 535 Information concerning possible security vulnerabilities of a 536 protocol may change over time. Consequently, claims as to the 537 security properties of a registered URL scheme may change as well. 538 As new vulnerabilities are discovered, information about such 539 vulnerabilities may need to be attached to existing registrations, 540 so that users are not misled as to the true security properties of a 541 registered URL scheme. 543 Delegations of a name space should only be assigned to someone with 544 adequate security. 546 9.0 References 548 [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 549 Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], August 1998 551 [2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 552 "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 1998 554 [3] Postel, J., Reynolds, J., "Instructions to RFC Authors", 555 RFC 2223, October 1997. 557 10.0 Author's Address 559 Rich Petke 560 WorldCom Advanced Networks 561 5000 Britton Road 562 P. O. Box 5000 563 Hilliard, OH 43026-5000 564 USA 566 Phone: +1 614 723 4157 567 Fax: +1 614 723 1333 568 EMail: rpetke@compuserve.net 570 Appendix A -- Grandfathered URL Scheme Names 572 A number of URL scheme names, in use prior to 1998, would, if 573 registered under the procedures specified in this document, be 574 placed into either the vendor or personal trees. Re-registration 575 of those types to reflect the appropriate trees is encouraged, but 576 not required. Ownership and change control principles outlined in 577 this document apply to those types as if they had been registered in 578 the trees described above. 580 ABOUT: 582 AOL: