idnits 2.17.1 draft-ietf-appsawg-uri-scheme-reg-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 8, 2015) is 3307 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2717 (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 2718 (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler, Ed. 3 Internet-Draft Microsoft 4 Obsoletes: 4395 (if approved) T. Hansen 5 Intended status: Best Current Practice AT&T Laboratories 6 Expires: October 10, 2015 T. Hardie 7 Google 8 L. Masinter 9 Adobe 10 April 8, 2015 12 Guidelines and Registration Procedures for URI Schemes 13 draft-ietf-appsawg-uri-scheme-reg-06 15 Abstract 17 This document updates the guidelines and recommendations, as well as 18 the IANA registration processes, for the definition of Uniform 19 Resource Identifier (URI) schemes. It obsoletes RFC 4395. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 10, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Requirements for Permanent Scheme Definitions . . . . . . . . 4 59 3.1. Demonstrable, New, Long-Lived Utility . . . . . . . . . . 4 60 3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5 61 3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Definition of Operations . . . . . . . . . . . . . . . . 6 63 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Internationalization and Character Encoding . . . . . . . 7 65 3.7. Clear Security and Privacy Considerations . . . . . . . . 7 66 3.8. Scheme Name Considerations . . . . . . . . . . . . . . . 8 67 3.9. Interoperability Considerations . . . . . . . . . . . . . 9 68 4. Guidelines for Provisional URI Scheme Registration . . . . . 9 69 5. Guidelines for Historical URI Scheme Registration . . . . . . 10 70 6. Guidelines for Private URI Scheme Use . . . . . . . . . . . . 10 71 7. URI Scheme Registration Procedure . . . . . . . . . . . . . . 10 72 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.2. Registration Procedures . . . . . . . . . . . . . . . . . 11 74 7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 13 75 7.4. URI Scheme Registration Template . . . . . . . . . . . . 13 76 8. The "example" URI Scheme . . . . . . . . . . . . . . . . . . 14 77 8.1. "Example" URI Scheme Registration Request . . . . . . . . 15 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 12.2. Informative References . . . . . . . . . . . . . . . . . 17 84 Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 The Uniform Resource Identifier (URI) protocol element and generic 90 syntax is defined by [RFC3986]. Each URI begins with a scheme name, 91 as defined by Section 3.1 of RFC 3986, that refers to a specification 92 for identifiers within that scheme. The URI syntax provides a 93 federated and extensible naming system, where each scheme's 94 specification can further restrict the syntax and define the 95 semantics of identifiers using that scheme. 97 This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] 98 and [RFC2718]. Recent documents have used the term "URI" for all 99 resource identifiers, avoiding the term "URL" and reserving the term 100 "URN" explicitly for those URIs using the "urn" scheme name 101 ([RFC2141]). URN "namespaces" ([RFC3406]) are specific to the "urn" 102 scheme and are not covered explicitly by this specification. 104 This document provides updated guidelines for the definition of new 105 schemes, for consideration by those who are defining, registering, or 106 evaluating those definitions, as well as a process and mechanism for 107 registering schemes within the IANA URI Schemes registry. There is a 108 single namespace for registered schemes. The intent of the registry 109 is to: 111 o provide a central point of discovery for established URI scheme 112 names, and easy location of defining documents for schemes; 114 o discourage multiple separate uses of the same scheme name; 116 o help those proposing new scheme names to discern established 117 trends and conventions, and avoid names that might be confused 118 with existing ones; 120 o encourage registration by setting a low barrier for registration. 122 1.1. URIs and IRIs 124 As originally defined, URIs only allowed a limited repertoire of 125 characters chosen from US-ASCII. An Internationalized Resource 126 Identifier (IRI), as defined by [RFC3987], extends the URI syntax to 127 allow characters from a much greater repertoire, to accommodate 128 resource identifiers from the world's languages. RFC 3987 [RFC3987] 129 also defined a mapping between URIs and IRIs. IRIs use the same 130 scheme names as URIs. Thus, there is no separate, independent 131 registry or registration process for IRI schemes: the URI Schemes 132 registry is used for both URIs and IRIs. Those who wish to describe 133 resource identifiers that are useful as IRIs should define the 134 corresponding URI syntax, and note that the IRI usage follows the 135 rules and transformations defined in [RFC3987]. 137 2. Terminology 139 Within this document, the key words MUST, MAY, SHOULD, REQUIRED, 140 RECOMMENDED, and so forth are used within the general meanings 141 established in [RFC2119], as requirements on future registrations. 143 This document distinguishes between a "scheme specification", being a 144 document defining the syntax and semantics of a scheme, vs. a "scheme 145 registration request" being the completed template submitted to IANA. 146 The term "scheme definition" refers generically to the syntax and 147 semantics of a scheme, typically documented in a scheme 148 specification. 150 3. Requirements for Permanent Scheme Definitions 152 This section gives considerations for new schemes. Meeting these 153 guidelines is REQUIRED for 'permanent' scheme registration. 154 'Permanent' status is appropriate for, but not limited to, use in 155 standards. For URI schemes defined or normatively referenced by IETF 156 Standards-Track documents, 'permanent' registration status is 157 REQUIRED. 159 [RFC3986] defines the overall syntax for URIs as: 161 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 163 A scheme definition cannot override the overall syntax for URIs. For 164 example, this means that fragment identifiers cannot be re-used 165 outside the generic syntax restrictions, and fragment identifiers are 166 not scheme-specific. A scheme definition must specify the scheme 167 name and the syntax of the scheme-specific part, which is clarified 168 as follows: 170 URI = scheme ":" scheme-specific-part [ "#" fragment ] 172 scheme-specific-part = hier-part [ "?" query ] 174 3.1. Demonstrable, New, Long-Lived Utility 176 In general, the use and deployment of new schemes in the Internet 177 infrastructure can be costly; some parts of URI processing are often 178 scheme-dependent. Introducing a new scheme might require additional 179 software, not only for client software and user agents but also in 180 additional parts of the network infrastructure (gateways, proxies, 181 caches) [W3CWebArch]. Since scheme names share a single, global 182 namespace, it is desirable to avoid contention over use of short, 183 mnemonic scheme names. New schemes ought to have utility to the 184 Internet community beyond that available with already registered 185 schemes. The scheme specification SHOULD discuss the utility of the 186 scheme being registered. 188 3.2. Syntactic Compatibility 190 [RFC3986] defines the generic syntax for all URI schemes, along with 191 the syntax of common URI components that are used by many URI schemes 192 to define hierarchical identifiers. [RFC3987] extended this generic 193 syntax to cover IRIs. All scheme specifications MUST define their 194 own URI syntax. Care must be taken to ensure 195 that all strings matching their scheme-specific syntax will also 196 match the grammar described in [RFC3986]. 198 New schemes SHOULD reuse the common URI components of [RFC3986] for 199 the definition of hierarchical naming schemes. If there is a strong 200 reason for a scheme not to use the hierarchical syntax, then the new 201 scheme definition SHOULD follow the syntax of similar previously 202 registered schemes. 204 Schemes that are not intended for use with relative URIs SHOULD avoid 205 use of the forward slash "/" character, in order to avoid unintended 206 processing such as resolution of "." and ".." (dot-segments). 208 Schemes SHOULD avoid improper use of "//". The use of double slashes 209 in the first part of a URI is not a stylistic indicator that what 210 follows is a URI: Double slashes are intended for use ONLY when the 211 syntax of the contains a hierarchical 212 structure. In URIs from such schemes, the use of double slashes 213 indicates that what follows is the top hierarchical element for a 214 naming authority. (Section 3.2 of RFC 3986 has more details.) 215 Schemes that do not contain a conformant hierarchical structure in 216 their SHOULD NOT use double slashes following 217 the ":" string. 219 New schemes SHOULD clearly define the role of reserved characters 220 (see [RFC3986], Section 2.2) in URIs of the scheme being defined. 221 The syntax of the new scheme should be clear about which of the 222 "reserved" set of characters are used as delimiters within the URIs 223 of the new scheme, and when those characters must be escaped, versus 224 when they can be used without escaping. 226 3.3. Well-Defined 228 While URIs might or might not be defined as locators in practice, a 229 scheme definition itself MUST be clear as to how it is expected to 230 function. Schemes that are not intended to be used as locators 231 SHOULD describe how the resource identified can be determined or 232 accessed by software that obtains a URI of that scheme. 234 For schemes that function as locators, it is important that the 235 mechanism of resource location be clearly defined. This might mean 236 different things depending on the nature of the scheme. 238 In many cases, new schemes are defined as ways to translate between 239 other namespaces or protocols and the general framework of URIs. For 240 example, the "ftp" scheme translates into the FTP protocol, while the 241 "mid" scheme translates into a Message-ID identifier of an email 242 message. For such schemes, the description of the mapping SHOULD be 243 complete, and in sufficient detail so that the mapping in both 244 directions is clear: how to map from a URI into an identifier or set 245 of protocol actions or name in the target namespace, and how legal 246 values in the base namespace, or legal protocol interactions, are 247 represented in a valid URI. See Section 3.6 for guidelines for 248 encoding strings or sequences of bytes within valid character 249 sequences in a URI. If not all legal values or protocol interactions 250 of the base standard can be represented using the scheme, the 251 definition SHOULD be clear about which subset is allowed, and why. 253 3.4. Definition of Operations 255 As part of the definition of how a URI identifies a resource, a 256 scheme definition SHOULD define the applicable set of operations that 257 can be performed on a resource using the URI as its identifier. A 258 model for this is HTTP methods; an HTTP resource can be operated on 259 by GET, POST, PUT, and a number of other methods available through 260 the HTTP protocol. The scheme definition SHOULD describe all well- 261 defined operations on the resource identifier, and what they are 262 supposed to do. 264 Some schemes don't fit into the "information access" paradigm of 265 URIs. For example, "telnet" provides location information for 266 initiating a bi-directional data stream to a remote host; the only 267 operation defined is to initiate the connection. In any case, the 268 operations appropriate for a scheme SHOULD be documented. 270 Note: It is perfectly valid to say that "no operation apart from GET 271 is defined for this URI". It is also valid to say that "there's only 272 one operation defined for this URI, and it's not very GET-like". The 273 important point is that what is defined on this scheme is described. 275 Scheme definitions SHOULD define a "default" operation for when a URI 276 is invoked (or "dereferenced") by an application. For example, a 277 common "default" operation today is to launch an application 278 associated with the scheme name, and let it use the other URI 279 components as inputs to do something. The default invocation, or 280 dereferencing, of a URI SHOULD be "safe" in the sense described by 281 section 3.4 of [W3CWebArch]; i.e., performing such an invocation 282 should not incur any additional obligations by doing so. 284 3.5. Context of Use 286 In general, URIs are used within a broad range of protocols and 287 applications. For example, URIs are commonly used within hypertext 288 documents as references to other resources. In some cases, a scheme 289 is intended for use within a different, specific set of protocols or 290 applications. If so, the scheme definition SHOULD describe the 291 intended use and include references to documentation that define the 292 applications and/or protocols cited. This does not obviate the need 293 for documentation on applications and/or protocols to discuss URI 294 schemes relevant to them. 296 3.6. Internationalization and Character Encoding 298 When describing schemes in which (some of) the elements of the URI 299 are actually representations of human-readable text, care should be 300 taken not to introduce unnecessary variety in the ways in which 301 characters are encoded into octets and then into URI characters; see 302 [RFC3987] and Section 2.5 (especially the last paragraph) of 303 [RFC3986] for guidelines. If URIs of a scheme contain any text 304 fields, the scheme definition MUST describe the ways in which 305 characters are encoded and any compatibility issues with IRIs of the 306 scheme. 308 The scheme specification SHOULD be as restrictive as possible 309 regarding what characters are allowed in the URI, because some 310 characters can create several different security issues (see, for 311 example [RFC4690]). 313 Percent-encoded character sequences are automatically included by 314 definition for characters given in IRI productions. This means that 315 if you want to restrict the URI percent-encoded forms in some way, 316 you must restrict the Unicode forms that would lead to them. In most 317 cases, it is advisable to define the actual characters allowed in an 318 IRI production, to allow the 'pct-encoded' definition from 319 Section 2.1 of [RFC3986] at the same places, and to add prose that 320 limits percent-escapes to those that can be created by converting 321 valid UTF-8 character sequences to percent-encoding. 323 3.7. Clear Security and Privacy Considerations 325 Definitions of schemes MUST be accompanied by a clear analysis of the 326 security and privacy implications for systems that use the scheme; 327 this follows the practice of Security Consideration sections within 328 IANA registrations [RFC5226]. 330 In particular, Section 7 of RFC 3986 [RFC3986] describes general 331 security considerations for URIs, while [RFC3987] gives those for 332 IRIs. The definition of an individual scheme should note which of 333 these apply to the specified scheme, in addition to any more scheme- 334 specific concerns. For example, if the scheme-specific part is 335 privacy sensitive then that should be documented. 337 3.8. Scheme Name Considerations 339 Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this 340 syntax remains the same for IRIs. New scheme registrations MUST 341 follow this syntax, which only allows a limited repertoire of 342 characters (taken from US-ASCII). Although the syntax for the scheme 343 name in URIs is case insensitive, the scheme name itself MUST be 344 registered using lowercase letters. 346 Scheme names SHOULD be short, but also sufficiently descriptive and 347 distinguished to avoid problems. 349 Schemes SHOULD NOT use names or other symbols that might cause 350 problems with rights to use the name in IETF specifications and 351 Internet protocols. For example, be careful with trademark and 352 service mark names. (See Section 7.4 of [RFC3978].) 354 Schemes SHOULD NOT use names that are either very general purpose or 355 associated in the community with some other application or protocol. 356 Schemes also SHOULD NOT use names that are overly general or 357 grandiose in scope (e.g., that allude to their "universal" or 358 "standard" nature.) 360 A scheme name is not a "protocol." However, like a service name as 361 defined in section 5 of [RFC6335], it often identifies a particular 362 protocol or application. If a scheme name has a one-to-one 363 correspondence with a service name, then the names SHOULD be the 364 same. 366 Some organizations desire their own namespace for URI scheme names 367 for private use (see Section 6). In doing so, it is important to 368 prevent collisions, and to make it possible to identify the owner of 369 a private use scheme. To accomplish these two goals, such 370 organizations SHOULD use a prefix based on their domain name, 371 expressed in reverse order. For example, a URI scheme name of 372 com.example.mything might be used by the organization that owns the 373 example.com domain name. Care must be taken, however, if the 374 organization later loses the domain name embedded in their scheme 375 names, since domain name registrations are not permanent. To 376 associate the private use scheme name with the original organization, 377 the private use scheme can be registered using the registration 378 procedure in Section 7. 380 Furthermore, to prevent collisions with private use scheme names, new 381 scheme names registered MUST NOT contain a "." unless actually 382 constructed from a reversed domain name. 384 3.9. Interoperability Considerations 386 If the person or group registering the scheme is aware of any details 387 regarding the scheme that might impact interoperability, identify 388 them. For example: proprietary or uncommon encoding methods; 389 incompatibility with types or versions of any underlying protocol. 391 4. Guidelines for Provisional URI Scheme Registration 393 'Provisional' registration can be used for schemes that are not part 394 of any standard, but that are intended for use (or observed to be in 395 use) that is not limited to a private environment within a single 396 organization. 'Provisional' registration can also be used as an 397 intermediate step on the way to 'permanent' registration, e.g., 398 before the scheme specification is finalized as a standard. 400 For a 'provisional' registration, the following apply: 402 o The scheme name must meet the syntactic requirements of 403 Section 3.8. 405 o There must not already be an entry with the same scheme name. In 406 the unfortunate case that there are multiple, different uses of 407 the same scheme name, the Designated Expert can approve a request 408 to modify an existing entry to note the separate use. 410 o Contact information identifying the person supplying the 411 registration must be included. Previously unregistered schemes 412 discovered in use can be registered by third parties (even if not 413 on behalf of those who created the scheme). In this case, both 414 the registering party and the scheme creator SHOULD be identified. 416 o If no permanent, citable specification for the scheme definition 417 is included, credible reasons for not providing it SHOULD be 418 given. 420 o The scheme definition SHOULD include clear security considerations 421 (Section 3.7) or explain why a full security analysis is not 422 available (e.g., in a third-party scheme registration). 424 o If the scheme definition does not meet the guidelines laid out in 425 Section 3, the differences and reasons SHOULD be noted. 427 5. Guidelines for Historical URI Scheme Registration 429 In some circumstances, it is appropriate to note a scheme that was 430 once in use or registered but for whatever reason is no longer in 431 common use or whose use is not recommended. In this case, it is 432 possible for an individual to request that the URI scheme be 433 registered (newly, or as an update to an existing registration) as 434 'historical'. Any scheme that is no longer in common use MAY be 435 designated as 'historical'; the registration SHOULD contain some 436 indication as to where the scheme was previously defined or 437 documented. 439 6. Guidelines for Private URI Scheme Use 441 Unregistered schemes can cause problems if use is not limited to a 442 private environment within a single organization, since the use could 443 leak out beyond the closed environment. Even within a closed 444 environment, other colliding uses of the same scheme name could 445 occur. As such, a unique namespace (see Section 3.8) MUST be used, 446 and it is strongly encouraged to do a 'provisional' registration 447 unless the scheme name is constructed from a domain name as discussed 448 in Section 3.8. 450 7. URI Scheme Registration Procedure 452 7.1. General 454 The IANA policy (using terms defined in [RFC5226]) for 'provisional' 455 registration was formerly Expert Review. The policy for 'permanent' 456 and 'historical' registration continues to be Expert Review, but this 457 document changes the policy for 'provisional' registration to First 458 Come First Served. 460 The registration procedure is intended to be very lightweight for 461 non-contentious registrations. For the most part, we expect the good 462 sense of submitters and reviewers, guided by these procedures, to 463 achieve an acceptable and useful consensus for the community. 465 In exceptional cases, where the negotiating parties cannot form a 466 consensus, the final arbiter of any contested registration shall be 467 the IESG. 469 If standardization is anticipated, the working group or individuals 470 concerned are advised to submit an early 'permanent' registration 471 request, rather than waiting until the standardization process has 472 run its course. IANA will pass this to the Designated Expert who may 473 recommend 'provisional' registration until the specification is 474 approved as a standard. This will provide opportunity for feedback 475 while specification development and review is still active, and the 476 submitter(s) are still in a position to respond to any issues that 477 might be raised. If and when the specification is approved as a 478 standard, the submitters should submit a request to change the 479 registration status to 'permanent'. 481 The role of the Designated Expert in the procedure for 'permanent' 482 registrations described here is to ensure that the normal open review 483 process has been properly followed, and to raise possible concerns 484 about wider implications of proposals for the use and deployment of 485 URIs. Nothing in the procedure empowers the Designated Expert to 486 override properly arrived-at IETF or working group consensus. 488 7.2. Registration Procedures 490 Someone wishing to register a new scheme MUST: 492 1. Check the IANA URI Schemes registry to see whether there is 493 already an entry for the desired name. If there is already an 494 entry under the name, choose a different scheme name, or update 495 the existing scheme specification. 497 2. Prepare a scheme registration request using the template 498 specified in Section 7.4. The scheme registration request can be 499 contained in an Internet Draft, submitted alone, or as part of 500 some other permanently available, stable, protocol specification. 501 The scheme registration request can also be submitted in some 502 other form (as part of another document or as a stand-alone 503 document), but the scheme registration request will be treated as 504 an "IETF Contribution" under the guidelines of [RFC3978]. 506 3. If the registration request is for a 'permanent' registration 507 (or, optionally, for any other registration if desired): 509 1. Review the requirements in Section 3. 511 2. Send a copy of the scheme registration request or a pointer 512 to the containing document (with specific reference to the 513 section with the scheme registration request) to the mailing 514 list uri-review@ietf.org , requesting review. In addition, 515 request review on other relevant mailing lists as 516 appropriate. For example, general discussion of URI 517 syntactical issues can be discussed on uri@w3.org; schemes 518 for a network protocol can be discussed on a mailing list for 519 that protocol. Allow a reasonable time for discussion and 520 comments. Four weeks is reasonable for a 'permanent' 521 registration request. 523 3. Respond to review comments and make revisions to the proposed 524 registration as needed to bring it into line with the 525 guidelines given in this document. 527 4. Submit the (possibly updated) scheme registration request (or 528 pointer to document containing it) to IANA at iana@iana.org. 530 Upon receipt of a scheme registration request, the following steps 531 MUST be followed: 533 1. IANA checks the submission for completeness; if required sections 534 of the scheme registration request are missing or any citations 535 are not correct, IANA will reject the registration request. A 536 registrant can resubmit a corrected request if desired. 538 2. If the request is for 'provisional' registration and no entry 539 already exists in the current registry for the same name, IANA 540 adds the registration to the registry, under the First Come First 541 Served policy. 543 3. Otherwise, IANA enters the registration request in the IANA 544 registry, with status marked as "Pending Review", and the 545 remainder of this section applies. 547 4. IANA requests Expert Review of the registration request against 548 the corresponding guidelines from this document. 550 5. The Designated Expert will evaluate the request against the 551 criteria of the requested status. 553 6. In the case of a 'permanent' registration request, the Designated 554 Expert may: 556 * Accept the specification of the scheme for 'permanent' 557 registration. 559 * Suggest 'provisional' registration instead. 561 * Request IETF review and IESG approval; in the meanwhile, 562 suggest 'provisional' registration. 564 * Request additional review or discussion, as necessary. 566 7. If an entry already exists for the same name, the Designated 567 Expert will determine whether the request should be rejected, or 568 whether the existing entry should be modified to note the 569 separate use. This conflict process applies regardless of the 570 requested status or the status of the existing entry. 572 8. Once Expert Review approves registration for a given status, IANA 573 updates the registration to indicate the approved status. If 574 Expert Review instead rejects the registration, the "Pending 575 Review" request is removed from the registry. 577 Either based on an explicit request or independently initiated, the 578 Designated Expert or the IESG can request the upgrade of a 579 'provisional' registration to a 'permanent' one. In such cases, IANA 580 will update the status of the corresponding entry. Typically this 581 would only occur if the use is considered a standard (not necessarily 582 an IETF standard). 584 7.3. Change Control 586 Registrations can be updated in the registry by the same mechanism as 587 required for an initial registration. In cases where the original 588 definition of the scheme is contained in an IESG-approved document, 589 update of the specification also requires IESG approval. 591 'Provisional' registrations can be updated by the original registrant 592 or anyone designated by the original registrant. In addition, the 593 IESG can reassign responsibility for a 'provisional' registration 594 scheme, or can request specific changes to a scheme registration. 595 This will enable changes to be made to schemes where the original 596 registrant is out of contact, or unwilling or unable to make changes. 598 Transition from 'provisional' to 'permanent' status can be requested 599 and approved in the same manner as a new 'permanent' registration. 600 Transition from 'permanent' to 'historical' status requires IESG 601 approval. Transition from 'provisional' to 'historical' can be 602 requested by anyone authorized to update the 'provisional' 603 registration. 605 7.4. URI Scheme Registration Template 607 This template describes the fields that MUST be supplied in a scheme 608 registration request, suitable for adding to the registry: 610 Scheme name: 611 See Section 3.8 for guidelines. 613 Status: 615 This reflects the status requested, and must be one of 'permanent', 616 'provisional', or 'historical'. 618 Applications/protocols that use this scheme name: 619 See Section 3.5. 621 Contact: 622 Person (including contact information) to contact for further 623 information. 625 Change controller: 626 Organization or person (often the author), including contact 627 information, authorized to change this. 629 References: 630 Include full citations for all referenced documents. Scheme 631 registration requests for 'provisional' registration can be 632 included in an Internet Draft; when the documents expire or are 633 approved for publication as an RFC, the registration will be 634 updated. A scheme specification is only required for 'permanent' 635 registration. 637 The previous version of this specification required the following 638 additional fields in a scheme registration request. These fields are 639 no longer part of the template. The answers instead belong in the 640 scheme specification. 642 Scheme syntax: 643 See Section 3.2 for guidelines. 645 Scheme semantics: 646 See Section 3.3 and Section 3.4 for guidelines. 648 Encoding considerations: 649 See Section 3.3 and Section 3.6 for guidelines. 651 Interoperability considerations: 652 See Section 3.9 for guidelines. 654 Security considerations: 655 See Section 3.7 for guidelines. 657 8. The "example" URI Scheme 659 There is a need for a scheme name that can be used for examples in 660 documentation without fear of conflicts with current or future actual 661 schemes. The scheme "example" is hereby registered as a 'permanent' 662 scheme for that purpose. 664 The "example" scheme is specified as follows: 666 Scheme syntax: The entire range of allowable syntax specified in 667 [RFC3986] is allowed for "example" URIs. Similarly, the entire 668 range of allowable syntax specified in [RFC3987] is allowed for 669 "example" IRIs. For example, , , and 670 are all valid. 672 Scheme semantics: URIs in the "example" scheme are to be used for 673 documentation purposes only. The use of "example" URIs must not be 674 used as locators, identify any resources, or specify any particular 675 set of operations. 677 Encoding considerations: See Section 2.5 of [RFC3986] for 678 guidelines. 680 Interoperability considerations: None. 682 Security considerations: None. 684 8.1. "Example" URI Scheme Registration Request 686 Scheme name: example 688 Status: permanent 690 Applications/protocols that use this scheme name: An "example" URI 691 is to be used for documentation purposes only. It MUST NOT be used 692 for any protocol. 694 Contact: N/A 696 Change controller: IETF 698 References: Section 8 of this RFC XXXX. 699 RFC Editor Note: Replace XXXX with this RFC's reference. 701 9. IANA Considerations 703 Previously, the former "URL Scheme" registry was replaced by the 704 "Uniform Resource Identifier (URI) Schemes" registry. The process 705 was based on [RFC5226] "Expert Review" with an initial (optional) 706 mailing list review. 708 The updated template has an additional field for the status of the 709 scheme, and the procedures for entering new name schemes have been 710 augmented. Section 7 establishes the process for new scheme 711 registration. 713 IANA is requested to do the following: 715 o Update the URI Schemes registry to point to this document. 717 o Combine the "Permanent URI Schemes", "Provisional URI Schemes", 718 and "Historical URI Schemes" sub-registries into a single common 719 registry with an additional "Status" column containing the status 720 (Permanent, Provisional, Historical, or Pending Review), and an 721 additional "Notes" column which is normally empty, but may contain 722 notes approved by the Designated Expert. 724 o Add the "example" URI scheme to the registry (see the template in 725 Section 8.1 for registration). 727 10. Security Considerations 729 All registered values are expected to contain clear security 730 considerations as discussed in Section 3.7. However, information 731 concerning possible security vulnerabilities of a protocol might 732 change over time. Consequently, claims as to the security properties 733 of a registered scheme might change as well. As new vulnerabilities 734 are discovered, information about such vulnerabilities might need to 735 be attached to existing documentation, so that users are not misled 736 as to the true security properties of a registered scheme. 738 11. Acknowledgements 740 Thanks to Mark Nottingham and Graham Klyne and other members of the 741 apps-discuss@ietf.org mailing list for their comments on this 742 document. 744 Many thanks to Patrik Faltstrom, Paul Hoffmann, Ira McDonald, Roy 745 Fielding, Stu Weibel, Tony Hammond, Charles Lindsey, Mark Baker, and 746 other members of the uri@w3.org mailing list for their comments on 747 earlier versions. 749 Parts of this document are based on [RFC2717], [RFC2718] and 750 [RFC3864]. Some of the ideas about use of URIs were taken from the 751 "Architecture of the World Wide Web" [W3CWebArch]. 753 12. References 755 12.1. Normative References 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, March 1997. 760 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 762 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 763 March 2005. 765 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 766 Resource Identifier (URI): Generic Syntax", STD 66, RFC 767 3986, January 2005. 769 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 770 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 771 May 2008. 773 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 774 Cheshire, "Internet Assigned Numbers Authority (IANA) 775 Procedures for the Management of the Service Name and 776 Transport Protocol Port Number Registry", BCP 165, RFC 777 6335, August 2011. 779 12.2. Informative References 781 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 782 Scheme Names", BCP 35, RFC 2717, November 1999. 784 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 785 "Guidelines for new URL Schemes", RFC 2718, November 1999. 787 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 788 "Uniform Resource Names (URN) Namespace Definition 789 Mechanisms", BCP 66, RFC 3406, October 2002. 791 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 792 Procedures for Message Header Fields", BCP 90, RFC 3864, 793 September 2004. 795 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 796 Identifiers (IRIs)", RFC 3987, January 2005. 798 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 799 Registration Procedures for New URI Schemes", BCP 35, RFC 800 4395, February 2006. 802 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 803 Recommendations for Internationalized Domain Names 804 (IDNs)", RFC 4690, September 2006. 806 [W3CWebArch] 807 W3C Technical Architecture Group, "Architecture of the 808 World Wide Web, Volume One", December 2004, 809 . 811 Appendix A. Changes Since RFC 4395 813 1. Combined the Historical, Permanent, and Provisional URI Schemes 814 registries into one registry with a status column. This is done 815 to make it easier to prevent duplicates and see existing 816 conventions. 818 2. Added a Notes column in the registry for notes approved by the 819 Designated Expert. 821 3. Moved the following fields out of the scheme registration 822 request template and into the requirements for a scheme 823 specification: Scheme syntax, Scheme semantics, Encoding 824 considerations, Interoperability considerations, and Security 825 considerations. 827 4. Simplified the process for 'provisional' registration 828 significantly: changed from Expert Review to First Come First 829 Served, and clarified that mailing list review is not required. 831 5. Updated process for handling of scheme name conflicts, so that 832 adding a note can be approved by the Designated Expert rather 833 than the IESG. 835 6. Clarified that a "URI scheme name" and an "IRI scheme name" are 836 the same thing and thus use the same IANA registry. 838 7. Clarified that a registration request falls under the "IETF 839 Contribution" rules, but the scheme's specification need not. 841 8. Added the "example:" URI scheme. 843 9. Added text about when to use 'provisional' registration. 845 10. Updated convention for Private use schemes to use "." (instead 846 of "-") between domain name labels, to reduce chance of 847 collision, and recommended use of a reverse domain name prefix 848 to allow identifying the owning organization. 850 11. Recommended that scheme definitions define a "default" operation 851 for when a URI is invoked. 853 12. Recommended that a scheme name be the same as the service name, 854 when there exists a 1:1 correspondence. 856 13. Elaborated on when a 'provisional' request should be upgraded to 857 Permanent. 859 14. Clarified that since, per RFC 3986, fragment identifiers are not 860 scheme-specific and hence are not part of the scheme definition. 862 15. Added text about getting early review and registration for 863 schemes intended to become standards. 865 16. Added text about privacy as an example of what should be covered 866 in security considerations in a scheme definition. 868 17. Clarified the role of a Designated Expert in reviewing 869 Standards-Track registrations. 871 Authors' Addresses 873 Dave Thaler (editor) 874 Microsoft 875 One Microsoft Way 876 Redmond, WA 98052 877 US 879 Phone: +1 425 703 8835 880 Email: dthaler@microsoft.com 882 Tony Hansen 883 AT&T Laboratories 884 200 Laurel Ave. 885 Middletown, NJ 07748 886 USA 888 Email: tony+urireg@maillennium.att.com 890 Ted Hardie 891 Google 893 Phone: +1 408 628 5864 894 Email: ted.ietf@gmail.com 895 Larry Masinter 896 Adobe 897 345 Park Ave. 898 San Jose, CA 95110 899 US 901 Phone: +1 408 536 3024 902 Email: masinter@adobe.com 903 URI: http://larry.masinter.net