idnits 2.17.1 draft-ietf-appsawg-uri-scheme-reg-01.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 (July 3, 2014) is 3578 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (==), 6 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: January 4, 2015 T. Hardie 7 Google 8 L. Masinter 9 Adobe 10 July 3, 2014 12 Guidelines and Registration Procedures for New URI Schemes 13 draft-ietf-appsawg-uri-scheme-reg-01 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 January 4, 2015. 38 Copyright Notice 40 Copyright (c) 2014 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Requirements for Permanent Scheme Definitions . . . . . . . . 4 58 3.1. Demonstrable, New, Long-Lived Utility . . . . . . . . . . 4 59 3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 4 60 3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Definition of Operations . . . . . . . . . . . . . . . . 6 62 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . 6 63 3.6. Internationalization and Character Encoding . . . . . . . 7 64 3.7. Clear Security Considerations . . . . . . . . . . . . . . 7 65 3.8. Scheme Name Considerations . . . . . . . . . . . . . . . 7 66 4. Guidelines for Provisional URI Scheme Registration . . . . . 8 67 5. Guidelines for Historical URI Scheme Registration . . . . . . 9 68 6. Guidelines for Private URI Scheme Use . . . . . . . . . . . . 9 69 7. URI Scheme Registration Procedure . . . . . . . . . . . . . . 10 70 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 7.2. Registration Procedures . . . . . . . . . . . . . . . . . 10 72 7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 12 73 7.4. URI Scheme Registration Template . . . . . . . . . . . . 13 74 8. The "example" Scheme . . . . . . . . . . . . . . . . . . . . 14 75 8.1. "Example" Scheme Registration Request . . . . . . . . . . 14 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 12.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 The Uniform Resource Identifier (URI) protocol element and generic 88 syntax is defined by [RFC3986]. Each URI begins with a scheme name, 89 as defined by Section 3.1 of RFC 3986, that refers to a specification 90 for identifiers within that scheme. The URI syntax provides a 91 federated and extensible naming system, where each scheme's 92 specification can further restrict the syntax and define the 93 semantics of identifiers using that scheme. 95 This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] 96 and [RFC2718]. Recent documents have used the term "URI" for all 97 resource identifiers, avoiding the term "URL" and reserving the term 98 "URN" explicitly for those URIs using the "urn" scheme name 99 ([RFC2141]). URN "namespaces" ([RFC3406]) are specific to the "urn" 100 scheme and are not covered explicitly by this specification. 102 This document provides updated guidelines for the definition of new 103 schemes, for consideration by those who are defining, registering, or 104 evaluating those definitions, as well as a process and mechanism for 105 registering schemes within the IANA URI Schemes registry. There is a 106 single namespace for registered schemes. The intent of the registry 107 is to: 109 o provide a central point of discovery for established URI scheme 110 names, and easy location of defining documents for standard 111 schemes; 113 o discourage use of the same scheme name for different mechanisms 114 (often, but not always, protocols); 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 As originally defined, URIs only allowed a limited repertoire of 123 characters chosen from US-ASCII. An Interationalized Resource 124 Identifier (IRI), as defined by [RFC3987], extends the URI syntax to 125 allow characters from a much greater repertoire, to accomodate 126 resource identifiers from the world's languages. RFC 3987 [RFC3987] 127 also defined a mapping between URIs and IRIs. A URI scheme name is 128 the same as the corresponding IRI scheme name. Thus, there is no 129 separate, independent registry or registration process for IRI 130 schemes: the URI Schemes registry is used for both URIs and IRIs. 131 Those who wish to describe resource identifiers that are useful as 132 IRIs should define the corresponding URI syntax, and note that the 133 IRI usage follows the rules and transformations defined in [RFC3987]. 135 [RFC3986] defines the overall syntax for URIs as: 137 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 139 A scheme definition cannot override the overall syntax for URIs. For 140 example, this means that fragment identifiers (#) cannot be re-used 141 outside the generic syntax restrictions. A scheme definition must 142 specify the scheme name and the syntax of the scheme-specific part, 143 which is clarified as follows: 145 URI = scheme ":" scheme-specific-part [ "#" fragment ] 147 scheme-specific-part = hier-part [ "?" query ] 149 2. Terminology 151 Within this document, the key words MUST, MAY, SHOULD, REQUIRED, 152 RECOMMENDED, and so forth are used within the general meanings 153 established in [RFC2119], within the context that they are 154 requirements on future registrations. 156 This document distinguishes between a "scheme specification", being a 157 document defining the syntax and semantics of a scheme, vs. a "scheme 158 registration request" being the request submitted to IANA. The term 159 "scheme definition" refers generically to the syntax and semantics of 160 a scheme, typically documented in a scheme specification. 162 3. Requirements for Permanent Scheme Definitions 164 This section gives considerations for new schemes. Meeting these 165 guidelines is REQUIRED for permanent scheme registration. Permanent 166 status is appropriate for, but not limited to, use in standards. For 167 IETF Standards-Track documents, Permanent registration status is 168 REQUIRED. 170 3.1. Demonstrable, New, Long-Lived Utility 172 In general, the use and deployment of new schemes in the Internet 173 infrastructure can be costly; some parts of URI processing are often 174 scheme-dependent. Introducing a new scheme might require additional 175 software, not only for client software and user agents but also in 176 additional parts of the network infrastructure (gateways, proxies, 177 caches) [W3CWebArch]. Since scheme names share a single, global 178 namespace, it is desirable to avoid contention over use of short, 179 mnemonic scheme names. New schemes ought to have utility to the 180 Internet community beyond that available with already registered 181 schemes. The scheme specification SHOULD discuss the utility of the 182 scheme being registered. 184 3.2. Syntactic Compatibility 186 [RFC3986] defines the generic syntax for all URI schemes, along with 187 the syntax of common URI components that are used by many URI schemes 188 to define hierarchical identifiers. [RFC3987] extended this generic 189 syntax to cover IRIs. All scheme specifications MUST define their 190 own URI syntax. Care must be taken to ensure 191 that all strings matching their scheme-specific syntax will also 192 match the grammar described in [RFC3986]. 194 New schemes SHOULD reuse the common URI components of [RFC3986] for 195 the definition of hierarchical naming schemes. If there is a strong 196 reason for a scheme not to use the hierarchical syntax, then the new 197 scheme definition SHOULD follow the syntax of previously registered 198 schemes. 200 Schemes that are not intended for use with relative URIs SHOULD avoid 201 use of the forward slash "/" character, which is used for 202 hierarchical delimiters, and the complete path segments "." and ".." 203 (dot-segments). [[CREF1: Ticket #26: odd that we SHOULD prohibit the 204 string ".." in a URI scheme where it can't be mistaken for a relative 205 reference because there are no "/". I.e., avoiding one of them, not 206 both, is sufficient to prevent being mistaken for a relative 207 reference, so why are we overly restrictive here. --MN]] 209 Schemes SHOULD avoid improper use of "//". The use of double slashes 210 in the first part of a URI is not an indicator that what follows is a 211 URI: Double slashes are intended for use ONLY when the syntax of the 212 contains a hierarchical structure. In URIs 213 from such schemes, the use of double slashes indicates that what 214 follows is the top hierarchical element for a naming authority. 215 (Section 3.2 of RFC 3986 has more details.) Schemes that do not 216 contain a conformant hierarchical structure in their SHOULD NOT use double slashes following the 218 ":" string. 220 New schemes SHOULD clearly define the role of [RFC3986] reserved 221 characters in URIs of the scheme being defined. The syntax of the 222 new scheme should be clear about which of the "reserved" set of 223 characters are used as delimiters within the URIs of the new scheme, 224 and when those characters must be escaped, versus when they can be 225 used without escaping. 227 3.3. Well-Defined 229 While URIs might or might not be defined as locators in practice, a 230 scheme definition itself MUST be clear as to how it is expected to 231 function. Schemes that are not intended to be used as locators 232 SHOULD describe how the resource identified can be determined or 233 accessed by software that obtains a URI of that scheme. 235 For schemes that function as locators, it is important that the 236 mechanism of resource location be clearly defined. This might mean 237 different things depending on the nature of the scheme. 239 In many cases, new schemes are defined as ways to translate between 240 other namespaces or protocols and the general framework of URIs. For 241 example, the "ftp" scheme translates into the FTP protocol, while the 242 "mid" scheme translates into a Message-ID identifier of an email 243 message. For such schemes, the description of the mapping MUST be 244 complete, and in sufficient detail so that the mapping in both 245 directions is clear: how to map from a URI into an identifier or set 246 of protocol actions or name in the target namespace, and how legal 247 values in the base namespace, or legal protocol interactions, might 248 be represented in a valid URI. See Section 3.6 for guidelines for 249 encoding binary or character strings within valid character sequences 250 in a URI . If not all legal values or protocol interactions of the 251 base standard can be represented using the scheme, the definition 252 SHOULD be clear about which subset are allowed, and why. 254 3.4. Definition of Operations 256 As part of the definition of how a URI identifies a resource, a 257 scheme definition SHOULD define the applicable set of operations that 258 can be performed on a resource using the URI as its identifier. A 259 model for this is HTTP methods; an HTTP resource can be operated on 260 by GET, POST, PUT, and a number of other methods available through 261 the HTTP protocol. The scheme definition SHOULD describe all well- 262 defined operations on the resource identifier, and what they are 263 supposed to do. 265 Some schemes don't fit into the "information access" paradigm of 266 URIs. For example, "telnet" provides location information for 267 initiating a bi-directional data stream to a remote host; the only 268 operation defined is to initiate the connection. In any case, the 269 operations appropriate for a scheme SHOULD be documented. 271 Note: It is perfectly valid to say that "no operation apart from GET 272 is defined for this URI". It is also valid to say that "there's only 273 one operation defined for this URI, and it's not very GET-like". The 274 important point is that what is defined on this scheme is described. 276 Scheme definitions SHOULD define a "default" operation for when a URI 277 is invoked (or "dereferenced") by an application. 279 3.5. Context of Use 281 In general, URIs are used within a broad range of protocols and 282 applications. Most commonly, URIs are used as references to 283 resources within directories or hypertext documents, as hyperlinks to 284 other resources. In some cases, a scheme is intended for use within 285 a different, specific set of protocols or applications. If so, the 286 scheme definition SHOULD describe the intended use and include 287 references to documentation that define the applications and/or 288 protocols cited. 290 3.6. Internationalization and Character Encoding 292 When describing schemes in which (some of) the elements of the URI 293 are actually representations of human-readable text, care should be 294 taken not to introduce unnecessary variety in the ways in which 295 characters are encoded into octets and then into URI characters; see 296 [RFC3987] and Section 2.5 of [RFC3986] for guidelines. If URIs of a 297 scheme contain any text fields, the scheme definition MUST describe 298 the ways in which characters are encoded and any compatibility issues 299 with IRIs of the scheme. 301 The scheme specification SHOULD be as restrictive as possible 302 regarding what characters are allowed in the URI, because some 303 characters can create several different security considerations (see, 304 for example [RFC4690]). 306 All percent-encoded variants are automatically included by definition 307 for any character given in an IRI production. This means that if you 308 want to restrict the URI percent-encoded forms in some way, you must 309 restrict the Unicode forms that would lead to them. 311 3.7. Clear Security Considerations 313 Definitions of schemes MUST be accompanied by a clear analysis of the 314 security implications for systems that use the scheme; this follows 315 the practice of Security Consideration sections within IANA 316 registrations [RFC5226]. 318 In particular, Section 7 of RFC 3986 [RFC3986] describes general 319 security considerations for URIs, while [RFC3987] gives those for 320 IRIs. The definition of an individual scheme should note which of 321 these apply to the specified scheme. 323 3.8. Scheme Name Considerations 325 Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this 326 syntax remains the same for IRIs. New registered schemes 327 registrations MUST follow this syntax, which only allows a limited 328 repertoire of characters (taken from US-ASCII). Although the syntax 329 for the scheme name in URIs is case insensitive, the scheme names 330 itself MUST be registered using lowercase letters. 332 Scheme names SHOULD be short, but also sufficiently descriptive and 333 distinguished to avoid problems. 335 Schemes SHOULD NOT use names or other symbols that might cause 336 problems with rights to use the name in IETF specifications and 337 Internet protocols. For example, be careful with trademark and 338 service mark names. (See Section 7.4 of [RFC3978].) 340 Schemes SHOULD NOT use names that are either very general purpose or 341 associated in the community with some other application or protocol. 342 Schemes also SHOULD NOT use names that are overly general or 343 grandiose in scope (e.g., that allude to their "universal" or 344 "standard" nature.) 346 If a scheme name has a one-to-one correspondence with a service name 347 (see section 5 of [RFC6335]), then the names SHOULD be the same. 349 Organizations that desire their own namespace for URI scheme names 350 for private use (see Section 6) MUST [[CREF2: Should this instead be 351 a SHOULD? The argument being that other things are common practice, 352 like using a well-known trademark as a prefix, and that this is just 353 as good as avoiding collisions, and is shorter. --DT]] use a prefix 354 based on their domain name, expressed in reverse order. For example, 355 a URI scheme name of com.example.info might be used by the 356 organization that owns the example.com domain name. This is 357 important to prevent collisions, and to make it possible to find the 358 owner of a private use scheme. Private use scheme names constructed 359 this way are unique enough to avoid collisions without requiring 360 registration. 362 Furthermore, to prevent collisions with private use scheme names, new 363 scheme names MUST NOT contain a "." unless actually constructed from 364 a reversed domain name. [[CREF3: Ticket #17: Are strings that look 365 like reversed FQDNs (other than grandfathered ones like "iris.beep") 366 reserved for use as such? Proposed answer is Yes, and text above has 367 been updated to reflect that proposal. --DT]] 369 4. Guidelines for Provisional URI Scheme Registration 371 Provisional registration can be used for schemes that are not part of 372 any standard, but that are intended for use (or observed to be in 373 use) that is not limited to a private environment within a single 374 organization. Provisional registration can also be used as an 375 intermediate step on the way to permanent registration, e.g., before 376 the scheme specification is finalized as a standard. 378 For a provisional registration, the following are REQUIRED: 380 o The scheme name meets the syntactic requirements of Section 3.8 381 and the encoding requirements of Section 3.6. 383 o There MUST NOT already be an entry with the same scheme name. (In 384 the unfortunate case that there are multiple, different uses of 385 the same scheme name, the IESG can approve a request to modify an 386 existing entry to note the separate use.) [[CREF4: Ticket #18: 387 Must the IESG do this? Why not the Designated Expert? Proposed 388 replacement text: In the unfortunate case that there are multiple, 389 different uses of the same scheme name, the existing entry can be 390 modified to note the separate use. For Permanent registrations, 391 this requires approval from the IESG. For other registrations, 392 this requires approval from the Designated Expert. --??]] 394 o Contact information identifying the person supplying the 395 registration is included. Previously unregistered schemes 396 discovered in use can be registered by third parties (even if not 397 on behalf of those who created the scheme). In this case, both 398 the registering party and the scheme creator SHOULD be identified. 400 o If no permanent, citable specification for the scheme definition 401 is included, credible reasons for not providing it SHOULD be 402 given. 404 o The scheme definition SHOULD include a clear Security 405 Considerations (Section 3.7) or explain why a full security 406 analysis is not available (e.g., in a third-party scheme 407 registration). 409 o If the scheme definition does not meet the guidelines laid out in 410 Section 3, the differences and reasons SHOULD be noted. 412 5. Guidelines for Historical URI Scheme Registration 414 In some circumstances, it is appropriate to note a scheme that was 415 once in use or registered but for whatever reason is no longer in 416 common use or the use is not recommended. In this case, it is 417 possible for an individual to request that the URI scheme be 418 registered (newly, or as an update to an existing registration) as 419 'historical'. Any scheme that is no longer in common use MAY be 420 designated as historical; the registration SHOULD contain some 421 indication to where the scheme was previously defined or documented. 423 6. Guidelines for Private URI Scheme Use 425 Unregistered schemes can cause problems if use is not limited to a 426 private environment within a single organization, since the use could 427 leak out beyond the closed environment. Even within a closed 428 environment, other colliding uses of the same scheme name could 429 occur. As such, a unique namespace (see Section 3.8) MUST be used, 430 and it is strongly encouraged to do a Provisional registration unless 431 the scheme name is constructed from a domain name. 433 7. URI Scheme Registration Procedure 435 7.1. General 437 The IANA policy (using terms defined in [RFC5226]) for Provisional 438 registration was formerly Expert Review and is now changed to simply 439 use a First Come First Served policy. The policy for Permanent and 440 Historic registration continues to be Expert Review. [[CREF5: 441 Updated text in this section per proposal to use FCFS as discussed at 442 IETF 89 (ticket #19). --DT]] 444 The registration procedure is intended to be very lightweight for 445 non-contentious registrations. For the most part, we expect the good 446 sense of submitters and reviewers, guided by these procedures, to 447 achieve an acceptable and useful consensus for the community. 449 In exceptional cases, where the negotiating parties cannot form a 450 consensus, the final arbiter of any contested registration shall be 451 the IESG. 453 If parties achieve consensus on a registration proposal that does not 454 fully conform to the strict wording of this procedure, this should be 455 drawn to the attention of a relevant member of the IESG. 457 7.2. Registration Procedures 459 Someone wishing to register a new scheme MUST: 461 1. Check the IANA URI Schemes registry to see whether there is 462 already an entry for the desired name. If there is already an 463 entry under the name, choose a different scheme name, or update 464 the existing scheme specification. 466 2. Prepare a scheme registration request using the template 467 specified in Section 7.4. The scheme registration request can be 468 contained in an Internet Draft, submitted alone, or as part of 469 some other permanently available, stable, protocol specification. 470 The completed template can also be submitted in some other form 471 (as part of another document or as a stand-alone document), but 472 the completed template will be treated as an "IETF Contribution" 473 under the guidelines of [RFC3978]. [[CREF6: Updated above text 474 to clarify that the registration request (not the scheme's spec 475 per se) is an IETF contribution, per ticket #21. --DT]] 477 3. If the registration request is for a Permanent registration: 479 1. Review the requirements in Section 3. 481 2. Send a copy of the completed template or a pointer to the 482 containing document (with specific reference to the section 483 with the completed template) to the mailing list uri- 484 review@ietf.org , requesting review. In addition, request 485 review on other relevant mailing lists as appropriate. For 486 example, general discussion of URI syntactical issues could 487 be discussed on uri@w3.org; schemes for a network protocol 488 could be discussed on a mailing list for that protocol. 489 Allow a reasonable time for discussion and comments. Four 490 weeks is reasonable for a permanent registration request. 492 3. Respond to review comments and make revisions to the proposed 493 registration as needed to bring it into line with the 494 guidelines given in this document. 496 4. Submit the (possibly updated) registration template (or pointer 497 to document containing it) to IANA at iana@iana.org. 499 Upon receipt of a scheme registration request, the following steps 500 MUST be followed: 502 1. IANA checks the submission for completeness; if sections of the 503 template are missing or citations are not correct, IANA will 504 reject the registration request. 506 2. IANA checks the current registry for a entry with the same name; 507 if such an entry exists, IANA will reject the registration 508 request. [[CREF7: Ticket #25: This contradicts section 4 which 509 states, "In the unfortunate case that there are multiple, 510 different uses of the same scheme name, the IESG can approve a 511 request to modify an existing entry to note the separate use." 512 Should IANA refer the request to the IESG rather than rejecting? 513 Or should the applicant submit the template to the IESG rather 514 than IANA? --DT]] 516 3. If the request is for Provisional registration, IANA adds the 517 registration to the registry, under the First Come First Served 518 policy. 520 4. For requests for Permanent or Historic status, the remainder of 521 this section applies. 523 5. IANA enters the registration request in the IANA registry, with 524 status marked as "Pending Review". 526 6. IANA requests Expert Review of the registration request against 527 the corresponding guidelines from this document. 529 7. The Designated Expert will evaluate the request against the 530 criteria of the requested status. In the case of a permanent 531 registration request, the Designated Expert may: 533 * Accept the specification of the scheme for permanent 534 registration. 536 * Suggest provisional registration instead. 538 * Request IETF review and IESG approval; in the meanwhile, 539 suggest provisional registration. 541 * Request additional review or discussion, as necessary. 543 8. Once Expert Review approves registration for a given status, IANA 544 adds the registration to the registry. 546 Either based on an explicit request or independently initiated, the 547 Designated Expert or IESG can request the upgrade of a 'provisional' 548 registration to a 'permanent' one. In such cases, IANA will update 549 the status of the corresponding entry. [[CREF8: Ticket #22: Say more 550 about guidance to the Designated Expert. Under what circumstance 551 would the expert request this? Why would the expert be able to 552 request this differently than anyone else (following the normal 553 process for a permanent registration, per the next section below)? 554 --DT]] 556 7.3. Change Control 558 Registrations can be updated in the registry by the same mechanism as 559 required for an initial registration. In cases where the original 560 definition of the scheme is contained in an IESG-approved document, 561 update of the specification also requires IESG approval. 563 Provisional registrations can be updated by the original registrant 564 or anyone designated by the original registrant. In addition, the 565 IESG can reassign responsibility for a provisional registration 566 scheme, or can request specific changes to a scheme registration. 567 This will enable changes to be made to schemes where the original 568 registrant is out of contact, or unwilling or unable to make changes. 570 Transition from 'provisional' to 'permanent' status can be requested 571 and approved in the same manner as a new 'permanent' registration. 572 Transition from 'permanent' to 'historical' status requires IESG 573 approval. Transition from 'provisional' to 'historical' can be 574 requested by anyone authorized to update the provisional 575 registration. 577 7.4. URI Scheme Registration Template 579 This template describes the fields that MUST be supplied in a scheme 580 registration request: 582 Scheme name: 583 See Section 3.8 for guidelines. 585 Status: 586 This reflects the status requested, and must be one of 'permanent', 587 'provisional', or 'historical'. 589 Applications/protocols that use this scheme name: 590 See Section 3.5. 592 Contact: 593 Person (including contact information) to contact for further 594 information. 596 Author/Change controller: 597 Person (including contact information) authorized to change this. 599 References: 600 Include full citations for all referenced documents. Registration 601 templates for provisional registration can be included in an 602 Internet Draft; when the documents expire or are approved for 603 publication as an RFC, the registration will be updated. A scheme 604 specification is only required for Permanent registration. 606 The following fields are no longer required in a scheme registration 607 request. The answers instead belong in the scheme specification. 609 Scheme syntax: 610 See Section 3.2 for guidelines. 612 Scheme semantics: 613 See Section 3.3 and Section 3.4 for guidelines. 615 Encoding considerations: 616 See Section 3.3 and Section 3.6 for guidelines. 618 Interoperability considerations: 619 If the person or group registering the scheme is aware of any 620 details regarding the scheme that might impact interoperability, 621 identify them here. For example: proprietary or uncommon encoding 622 methods; inability to support multibyte character sets; 623 incompatibility with types or versions of any underlying protocol. 625 Security considerations: 626 See Section 3.7 for guidelines. 628 [[CREF9: Moved the following fields out of the template and into the 629 requirements for a scheme specification, per ticket #23 and ticket 630 #24: Scheme syntax, Scheme semantics, Encoding considerations, 631 Interoperability considerations, and Security considerations. --DT]] 633 8. The "example" Scheme 635 There is a need for a scheme name that can be used for examples in 636 documentation without fear of conflicts with current or future actual 637 schemes. The scheme "example" is hereby registered as a Permanent 638 scheme for that purpose. 640 The "example" scheme is specified as follows: 642 Scheme syntax: The entire range of allowable syntax specified in 643 [RFC3986] is allowed for "example" URIs. 645 Scheme semantics: URIs in the "example" scheme are to be used for 646 documentation purposes only. The use of "example" URIs must not be 647 used as locators, identify any resources, or specify any particular 648 set of operations. 650 Encoding considerations: See Section 2.5 of [RFC3986] for 651 guidelines. 653 Interoperability considerations: None. 655 Security considerations: None. 657 8.1. "Example" Scheme Registration Request 659 Scheme name: example 661 Status: permanent 663 Applications/protocols that use this scheme name: An "example" URI 664 is to be used for documentation purposes only. It MUST NOT be used 665 for any protocol. 667 Contact: N/A 669 Author/Change controller: IETF 670 References: Section 8 of this RFC XXXX. 671 RFC Editor Note: Replace XXXX with this RFC's reference. 673 9. IANA Considerations 675 Previously, the former "URL Scheme" registry was replaced by the 676 "Uniform Resource Identifier (URI) Schemes" registry. The process 677 was based on [RFC5226] "Expert Review" with an initial (optional) 678 mailing list review. 680 The updated template has an additional field for the status of the 681 scheme, and the procedures for entering new name schemes have been 682 augmented. Section 7 establishes the process for new scheme 683 registration. 685 IANA is requested to do the following: 687 o Update the URI Schemes registry to point to this document. 689 o Combine the "Permanent URI Schemes", "Provisional URI Schemes", 690 and "Historical URI Schemes" sub-registries into a single common 691 registry with an additional "Status" column containing the status 692 (Permanent, Provisional, Historical, or Pending Review), and an 693 additional "Notes" column which is normally empty, but may contain 694 notes approved by the Designated Expert. 696 o Add the "example" URI scheme to the registry (see the template in 697 Section 8.1 for registration). 699 10. Security Considerations 701 All registered values are expected to contain accurate security 702 consideration sections; 'permanent' registered scheme names are 703 expected to contain complete definitions. 705 Information concerning possible security vulnerabilities of a 706 protocol might change over time. Consequently, claims as to the 707 security properties of a registered scheme might change as well. As 708 new vulnerabilities are discovered, information about such 709 vulnerabilities might need to be attached to existing documentation, 710 so that users are not misled as to the true security properties of a 711 registered scheme. 713 11. Acknowledgements 715 Thanks to Mark Nottingham and Graham Klyne and other members of the 716 apps-discuss@ietf.org mailing list for their comments on this 717 document. 719 Many thanks to Patrik Faltstrom, Paul Hoffmann, Ira McDonald, Roy 720 Fielding, Stu Weibel, Tony Hammond, Charles Lindsey, Mark Baker, and 721 other members of the uri@w3.org mailing list for their comments on 722 earlier versions. 724 Parts of this document are based on [RFC2717], [RFC2718] and 725 [RFC3864]. Some of the ideas about use of URIs were taken from the 726 "Architecture of the World Wide Web" [W3CWebArch]. 728 12. References 730 12.1. Normative References 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, March 1997. 735 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 737 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 738 March 2005. 740 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 741 Resource Identifier (URI): Generic Syntax", STD 66, RFC 742 3986, January 2005. 744 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 745 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 746 May 2008. 748 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 749 Cheshire, "Internet Assigned Numbers Authority (IANA) 750 Procedures for the Management of the Service Name and 751 Transport Protocol Port Number Registry", BCP 165, RFC 752 6335, August 2011. 754 12.2. Informative References 756 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 757 Scheme Names", BCP 35, RFC 2717, November 1999. 759 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 760 "Guidelines for new URL Schemes", RFC 2718, November 1999. 762 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 763 "Uniform Resource Names (URN) Namespace Definition 764 Mechanisms", BCP 66, RFC 3406, October 2002. 766 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 767 Procedures for Message Header Fields", BCP 90, RFC 3864, 768 September 2004. 770 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 771 Identifiers (IRIs)", RFC 3987, January 2005. 773 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 774 Registration Procedures for New URI Schemes", BCP 35, RFC 775 4395, February 2006. 777 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 778 Recommendations for Internationalized Domain Names 779 (IDNs)", RFC 4690, September 2006. 781 [W3CWebArch] 782 W3C Technical Architecture Group, "Architecture of the 783 World Wide Web, Volume One", December 2004, 784 . 786 Appendix A. Changes Since RFC 4395 788 1. Combined the Historical, Permanent, and Provisional URI Schemes 789 registries into one registry with a status column. This is done 790 to make it easier to prevent duplicates and see existing 791 conventions. 793 2. Simplified the process for Provisional registration 794 significantly: changed from Expert Review to First Come First 795 Served, and clarified that mailing list review is not required. 797 3. Added a Notes column for notes approved by the Designated 798 Expert. 800 4. Clarified that a "URI scheme name" and an "IRI scheme name" are 801 the same thing and thus use the same IANA registry. 803 5. Clarified that a registration request falls under the "IETF 804 Contribution" rules, but the scheme's specification need not. 806 6. Added the "example:" URI scheme. 808 7. Added text about when to use Provisional registration. 810 8. Updated convention for Private use schemes to use "." instead of 811 "-" between domain name labels, to reduce chance of collision, 812 and noted that new schemes must only use "." with the reversed 813 domain name convention. 815 9. Recommended that scheme definitions define a "default" operation 816 for when a URI is invoked. 818 10. Moved the following fields out of the scheme registration 819 request template and into the requirements for a scheme 820 specification: Scheme syntax, Scheme semantics, Encoding 821 considerations, Interoperability considerations, and Security 822 considerations. 824 11. Recommended that a scheme name be the same as the service name, 825 when there exists a 1:1 correspondence. 827 Authors' Addresses 829 Dave Thaler (editor) 830 Microsoft 831 One Microsoft Way 832 Redmond, WA 98052 833 US 835 Phone: +1 425 703 8835 836 Email: dthaler@microsoft.com 838 Tony Hansen 839 AT&T Laboratories 840 200 Laurel Ave. 841 Middletown, NJ 07748 842 USA 844 Email: tony+urireg@maillennium.att.com 846 Ted Hardie 847 Google 849 Phone: +1 408 628 5864 850 Email: ted.ietf@gmail.com 851 Larry Masinter 852 Adobe 853 345 Park Ave. 854 San Jose, CA 95110 855 US 857 Phone: +1 408 536 3024 858 Email: masinter@adobe.com 859 URI: http://larry.masinter.net