idnits 2.17.1 draft-ietf-appsawg-uri-scheme-reg-00.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 (March 31, 2014) is 3676 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 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) -- 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: October 2, 2014 T. Hardie 7 Google 8 L. Masinter 9 Adobe 10 March 31, 2014 12 Guidelines and Registration Procedures for New URI Schemes 13 draft-ietf-appsawg-uri-scheme-reg-00 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 2, 2014. 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 . . . . . . . . . . . . . . 9 70 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.2. Registration Procedures . . . . . . . . . . . . . . . . . 10 72 7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 12 73 7.4. URI Scheme Registration Template . . . . . . . . . . . . 12 74 8. The "example" Scheme . . . . . . . . . . . . . . . . . . . . 14 75 8.1. "Example" Scheme Registration Request . . . . . . . . . . 14 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . 17 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 their defining documents; 112 o discourage use of the same scheme name for different mechanisms 113 (often, but not always, protocols); 115 o help those proposing new scheme names to discern established 116 trends and conventions, and avoid names that might be confused 117 with existing ones; 119 o encourage registration by setting a low barrier for registration. 121 As originally defined, URIs only allowed a limited repertoire of 122 characters chosen from US-ASCII. An Interationalized Resource 123 Identifier (IRI), as defined by [RFC3987], extends the URI syntax to 124 allow characters from a much greater repertoire, to accomodate 125 resource identifiers from the world's languages. RFC 3987 [RFC3987] 126 also defined a mapping between URIs and IRIs. A URI scheme name is 127 the same as the corresponding IRI scheme name. Thus, there is no 128 separate, independent registry or registration process for IRI 129 schemes: the URI Schemes registry is used for both URIs and IRIs. 130 Those who wish to describe resource identifiers that are useful as 131 IRIs should define the corresponding URI syntax, and note that the 132 IRI usage follows the rules and transformations defined in [RFC3987]. 134 [RFC3986] defines the overall syntax for URIs as: 136 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 138 A scheme definition cannot override the overall syntax for URIs. For 139 example, this means that fragment identifiers (#) cannot be re-used 140 outside the generic syntax restrictions. A scheme definition must 141 specify the scheme name and the syntax of the scheme-specific part, 142 which is clarified as follows: 144 URI = scheme ":" scheme-specific-part [ "#" fragment ] 146 scheme-specific-part = hier-part [ "?" query ] 148 2. Terminology 150 Within this document, the key words MUST, MAY, SHOULD, REQUIRED, 151 RECOMMENDED, and so forth are used within the general meanings 152 established in [RFC2119], within the context that they are 153 requirements on future registrations. 155 This document distinguishes between a "scheme specification", being a 156 document defining the syntax and semantics of a scheme, vs. a "scheme 157 registration request" being the request submitted to IANA. The term 158 "scheme definition" refers generically to the syntax and semantics of 159 a scheme, typically documented in a scheme specification. 161 3. Requirements for Permanent Scheme Definitions 163 This section gives considerations for new schemes. Meeting these 164 guidelines is REQUIRED for permanent scheme registration. Permanent 165 status is appropriate for, but not limited to, use in standards. For 166 IETF Standards-Track documents, Permanent registration status is 167 REQUIRED. 169 3.1. Demonstrable, New, Long-Lived Utility 171 In general, the use and deployment of new schemes in the Internet 172 infrastructure can be costly; some parts of URI processing are often 173 scheme-dependent. Introducing a new scheme might require additional 174 software, not only for client software and user agents but also in 175 additional parts of the network infrastructure (gateways, proxies, 176 caches) [W3CWebArch]. Since scheme names share a single, global 177 namespace, it is desirable to avoid contention over use of short, 178 mnemonic scheme names. New schemes ought to have utility to the 179 Internet community beyond that available with already registered 180 schemes. The scheme specification SHOULD discuss the utility of the 181 scheme being registered. 183 3.2. Syntactic Compatibility 185 [RFC3986] defines the generic syntax for all URI schemes, along with 186 the syntax of common URI components that are used by many URI schemes 187 to define hierarchical identifiers. [RFC3987] extended this generic 188 syntax to cover IRIs. All scheme specifications MUST define their 189 own URI syntax. Care must be taken to ensure 190 that all strings matching their scheme-specific syntax will also 191 match the grammar described in [RFC3986]. 193 New schemes SHOULD reuse the common URI components of [RFC3986] for 194 the definition of hierarchical naming schemes. If there is a strong 195 reason for a scheme not to use the hierarchical syntax, then the new 196 scheme definition SHOULD follow the syntax of previously registered 197 schemes. 199 Schemes that are not intended for use with relative URIs SHOULD avoid 200 use of the forward slash "/" character, which is used for 201 hierarchical delimiters, and the complete path segments "." and ".." 202 (dot-segments). [[CREF1: Ticket #26: odd that we SHOULD prohibit the 203 string ".." in a URI scheme where it can't be mistaken for a relative 204 reference because there are no "/". I.e., avoiding one of them, not 205 both, is sufficient to prevent being mistaken for a relative 206 reference, so why are we overly restrictive here. --MN]] 208 Schemes SHOULD avoid improper use of "//". The use of double slashes 209 in the first part of a URI is not an indicator that what follows is a 210 URI: Double slashes are intended for use ONLY when the syntax of the 211 contains a hierarchical structure. In URIs 212 from such schemes, the use of double slashes indicates that what 213 follows is the top hierarchical element for a naming authority. 214 (Section 3.2 of RFC 3986 has more details.) Schemes that do not 215 contain a conformant hierarchical structure in their SHOULD NOT use double slashes following the 217 ":" string. 219 New schemes SHOULD clearly define the role of [RFC3986] reserved 220 characters in URIs of the scheme being defined. The syntax of the 221 new scheme should be clear about which of the "reserved" set of 222 characters are used as delimiters within the URIs of the new scheme, 223 and when those characters must be escaped, versus when they can be 224 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 MUST 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, might 247 be represented in a valid URI. See Section 3.6 for guidelines for 248 encoding binary or character strings within valid character sequences 249 in a URI . If not all legal values or protocol interactions of the 250 base standard can be represented using the scheme, the definition 251 SHOULD be clear about which subset are 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. 278 3.5. Context of Use 280 In general, URIs are used within a broad range of protocols and 281 applications. Most commonly, URIs are used as references to 282 resources within directories or hypertext documents, as hyperlinks to 283 other resources. In some cases, a scheme is intended for use within 284 a different, specific set of protocols or applications. If so, the 285 scheme definition SHOULD describe the intended use and include 286 references to documentation that define the applications and/or 287 protocols cited. 289 3.6. Internationalization and Character Encoding 291 When describing schemes in which (some of) the elements of the URI 292 are actually representations of human-readable text, care should be 293 taken not to introduce unnecessary variety in the ways in which 294 characters are encoded into octets and then into URI characters; see 295 [RFC3987] and Section 2.5 of [RFC3986] for guidelines. If URIs of a 296 scheme contain any text fields, the scheme definition MUST describe 297 the ways in which characters are encoded and any compatibility issues 298 with IRIs of the scheme. 300 The scheme specification SHOULD be as restrictive as possible 301 regarding what characters are allowed in the URI, because some 302 characters can create several different security considerations (see, 303 for example [RFC4690]). 305 All percent-encoded variants are automatically included by definition 306 for any character given in an IRI production. This means that if you 307 want to restrict the URI percent-encoded forms in some way, you must 308 restrict the Unicode forms that would lead to them. 310 3.7. Clear Security Considerations 312 Definitions of schemes MUST be accompanied by a clear analysis of the 313 security implications for systems that use the scheme; this follows 314 the practice of Security Consideration sections within IANA 315 registrations [RFC5226]. 317 In particular, Section 7 of RFC 3986 [RFC3986] describes general 318 security considerations for URIs, while [RFC3987] gives those for 319 IRIs. The definition of an individual scheme should note which of 320 these apply to the specified scheme. 322 3.8. Scheme Name Considerations 324 Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this 325 syntax remains the same for IRIs. New registered schemes 326 registrations MUST follow this syntax, which only allows a limited 327 repertoire of characters (taken from US-ASCII). Although the syntax 328 for the scheme name in URIs is case insensitive, the scheme names 329 itself MUST be registered using lowercase letters. 331 Scheme names SHOULD be short, but also sufficiently descriptive and 332 distinguished to avoid problems. 334 Schemes SHOULD NOT use names or other symbols that might cause 335 problems with rights to use the name in IETF specifications and 336 Internet protocols. For example, be careful with trademark and 337 service mark names. (See Section 7.4 of [RFC3978].) 339 Schemes SHOULD NOT use names that are either very general purpose or 340 associated in the community with some other application or protocol. 341 Schemes also SHOULD NOT use names that are overly general or 342 grandiose in scope (e.g., that allude to their "universal" or 343 "standard" nature.) 345 Organizations that desire their own namespace for URI scheme names 346 for private use (see Section 6) MUST use a prefix based on their 347 domain name, expressed in reverse order. For example, a URI scheme 348 name of com.example.info might be used by the organization that owns 349 the example.com domain name. This is important to prevent 350 collisions, and to make it possible to find the owner of a private 351 use scheme. 353 Furthermore, to prevent collisions with private use scheme names, new 354 scheme names MUST NOT contain a "." unless actually constructed from 355 a reversed domain name. [[CREF2: Ticket #17: Are strings that look 356 like reversed FQDNs (other than grandfathered ones like "iris.beep") 357 reserved for use as such? Proposed answer is Yes, and text above has 358 been updated to reflect that proposal. --DT]] 360 4. Guidelines for Provisional URI Scheme Registration 362 Provisional registration can be used for schemes that are not part of 363 any standard, but that are intended for use (or observed to be in 364 use) that is not limited to a private environment within a single 365 organization. Provisional registration can also be used as an 366 intermediate step on the way to permanent registration, e.g., before 367 the scheme specification is finalized as a standard. 369 For a provisional registration, the following are REQUIRED: 371 o The scheme name meets the syntactic requirements of Section 3.8 372 and the encoding requirements of Section 3.6. 374 o There MUST NOT already be an entry with the same scheme name. (In 375 the unfortunate case that there are multiple, different uses of 376 the same scheme name, the IESG can approve a request to modify an 377 existing entry to note the separate use.) [[CREF3: Ticket #18: 378 Must the IESG do this? Why not the Expert Reviewer? --??]] 380 o Contact information identifying the person supplying the 381 registration is included. Previously unregistered schemes 382 discovered in use can be registered by third parties (even if not 383 on behalf of those who created the scheme). In this case, both 384 the registering party and the scheme creator SHOULD be identified. 386 o If no permanent, citable specification for the scheme definition 387 is included, credible reasons for not providing it SHOULD be 388 given. 390 o The scheme definition SHOULD include a clear Security 391 Considerations (Section 3.7) or explain why a full security 392 analysis is not available (e.g., in a third-party scheme 393 registration). 395 o If the scheme definition does not meet the guidelines laid out in 396 Section 3, the differences and reasons SHOULD be noted. 398 5. Guidelines for Historical URI Scheme Registration 400 In some circumstances, it is appropriate to note a scheme that was 401 once in use or registered but for whatever reason is no longer in 402 common use or the use is not recommended. In this case, it is 403 possible for an individual to request that the URI scheme be 404 registered (newly, or as an update to an existing registration) as 405 'historical'. Any scheme that is no longer in common use MAY be 406 designated as historical; the registration SHOULD contain some 407 indication to where the scheme was previously defined or documented. 409 6. Guidelines for Private URI Scheme Use 411 Unregistered schemes can cause problems if use is not limited to a 412 private environment within a single organization, since the use could 413 leak out beyond the closed environment. Even within a closed 414 environment, other colliding uses of the same scheme name could 415 occur. As such, a unique namespace (see Section 3.8) MUST be used, 416 and it is strongly encouraged to do a Provisional registration even 417 in such cases. 419 7. URI Scheme Registration Procedure 421 7.1. General 423 The IANA policy (using terms defined in [RFC5226]) for Provisional 424 registration was formerly Expert Review and is now changed to simply 425 use a First Come First Served policy. The policy for Permanent and 426 Historic registration continues to be Expert Review. [[CREF4: 427 Updated text in this section per proposal to use FCFS as discussed at 428 IETF 89 (ticket #19). --DT]] 429 The registration procedure is intended to be very lightweight for 430 non-contentious registrations. For the most part, we expect the good 431 sense of submitters and reviewers, guided by these procedures, to 432 achieve an acceptable and useful consensus for the community. 434 In exceptional cases, where the negotiating parties cannot form a 435 consensus, the final arbiter of any contested registration shall be 436 the IESG. 438 If parties achieve consensus on a registration proposal that does not 439 fully conform to the strict wording of this procedure, this should be 440 drawn to the attention of a relevant member of the IESG. 442 7.2. Registration Procedures 444 Someone wishing to register a new scheme MUST: 446 1. Check the IANA URI Schemes registry to see whether there is 447 already an entry for the desired name. If there is already an 448 entry under the name, choose a different scheme name, or update 449 the existing scheme specification. 451 2. Prepare a scheme registration request using the template 452 specified in Section 7.4. The scheme registration request can be 453 contained in an Internet Draft, submitted alone, or as part of 454 some other permanently available, stable, protocol specification. 455 The completed template can also be submitted in some other form 456 (as part of another document or as a stand-alone document), but 457 the completed template will be treated as an "IETF Contribution" 458 under the guidelines of [RFC3978]. [[CREF5: Updated above text 459 to clarify that the registration request (not the scheme's spec 460 per se) is an IETF contribution, per ticket #21. --DT]] 462 3. If the registration request is for a Permanent registration: 464 1. Review the requirements in Section 3. 466 2. Send a copy of the completed template or a pointer to the 467 containing document (with specific reference to the section 468 with the completed template) to the mailing list uri- 469 review@ietf.org , requesting review. In addition, request 470 review on other relevant mailing lists as appropriate. For 471 example, general discussion of URI syntactical issues could 472 be discussed on uri@w3.org; schemes for a network protocol 473 could be discussed on a mailing list for that protocol. 474 Allow a reasonable time for discussion and comments. Four 475 weeks is reasonable for a permanent registration request. 477 3. Respond to review comments and make revisions to the proposed 478 registration as needed to bring it into line with the 479 guidelines given in this document. 481 4. Submit the (possibly updated) registration template (or pointer 482 to document containing it) to IANA at iana@iana.org. 484 Upon receipt of a scheme registration request, the following steps 485 MUST be followed: 487 1. IANA checks the submission for completeness; if sections of the 488 template are missing or citations are not correct, IANA will 489 reject the registration request. 491 2. IANA checks the current registry for a entry with the same name; 492 if such an entry exists, IANA will reject the registration 493 request. [[CREF6: Ticket #25: This contradicts section 4 which 494 states, "In the unfortunate case that there are multiple, 495 different uses of the same scheme name, the IESG can approve a 496 request to modify an existing entry to note the separate use." 497 Should IANA refer the request to the IESG rather than rejecting? 498 Or should the applicant submit the template to the IESG rather 499 than IANA? --DT]] 501 3. If the request is for Provisional registration, IANA adds the 502 registration to the registry, under the First Come First Served 503 policy. 505 4. For requests for Permanent or Historic status, the remainder of 506 this section applies. 508 5. IANA enters the registration request in the IANA registry, with 509 status marked as "Pending Review". 511 6. IANA requests Expert Review of the registration request against 512 the corresponding guidelines from this document. 514 7. The Designated Expert will evaluate the request against the 515 criteria of the requested status. In the case of a permanent 516 registration request, the Designated Expert may: 518 * Accept the specification of the scheme for permanent 519 registration. 521 * Suggest provisional registration instead. 523 * Request IETF review and IESG approval; in the meanwhile, 524 suggest provisional registration. 526 * Request additional review or discussion, as necessary. 528 8. Once Expert Review approves registration for a given status, IANA 529 adds the registration to the registry. 531 Either based on an explicit request or independently initiated, the 532 Designated Expert or IESG can request the upgrade of a 'provisional' 533 registration to a 'permanent' one. In such cases, IANA will update 534 the status of the corresponding entry. [[CREF7: Ticket #22: Say more 535 about guidance to the Designated Expert. Under what circumstance 536 would the expert request this? Why would the expert be able to 537 request this differently than anyone else (following the normal 538 process for a permanent registration, per the next section below)? 539 --DT]] 541 7.3. Change Control 543 Registrations can be updated in the registry by the same mechanism as 544 required for an initial registration. In cases where the original 545 definition of the scheme is contained in an IESG-approved document, 546 update of the specification also requires IESG approval. 548 Provisional registrations can be updated by the original registrant 549 or anyone designated by the original registrant. In addition, the 550 IESG can reassign responsibility for a provisional registration 551 scheme, or can request specific changes to a scheme registration. 552 This will enable changes to be made to schemes where the original 553 registrant is out of contact, or unwilling or unable to make changes. 555 Transition from 'provisional' to 'permanent' status can be requested 556 and approved in the same manner as a new 'permanent' registration. 557 Transition from 'permanent' to 'historical' status requires IESG 558 approval. Transition from 'provisional' to 'historical' can be 559 requested by anyone authorized to update the provisional 560 registration. 562 7.4. URI Scheme Registration Template 564 This template describes the fields that MUST be supplied in a scheme 565 registration request: 567 Scheme name: 568 See Section 3.8 for guidelines. 570 Status: 571 This reflects the status requested, and must be one of 'permanent', 572 'provisional', or 'historical'. 574 Applications/protocols that use this scheme name: 575 See Section 3.5. 577 Contact: 578 Person (including contact information) to contact for further 579 information. 581 Author/Change controller: 582 Person (including contact information) authorized to change this. 584 References: 585 Include full citations for all referenced documents. Registration 586 templates for provisional registration can be included in an 587 Internet Draft; when the documents expire or are approved for 588 publication as an RFC, the registration will be updated. A scheme 589 specification is only required for Permanent registration. 591 The following fields are no longer required in a scheme registration 592 request. The answers instead belong in the scheme specification. 594 Scheme syntax: 595 See Section 3.2 for guidelines. 597 Scheme semantics: 598 See Section 3.3 and Section 3.4 for guidelines. 600 Encoding considerations: 601 See Section 3.3 and Section 3.6 for guidelines. 603 Interoperability considerations: 604 If the person or group registering the scheme is aware of any 605 details regarding the scheme that might impact interoperability, 606 identify them here. For example: proprietary or uncommon encoding 607 methods; inability to support multibyte character sets; 608 incompatibility with types or versions of any underlying protocol. 610 Security considerations: 611 See Section 3.7 for guidelines. 613 [[CREF8: Moved the following fields out of the template and into the 614 requirements for a scheme specification, per ticket #23 and ticket 615 #24: Scheme syntax, Scheme semantics, Encoding considerations, 616 Interoperability considerations, and Security considerations. --DT]] 618 8. The "example" Scheme 620 There is a need for a scheme name that can be used for examples in 621 documentation without fear of conflicts with current or future actual 622 schemes. The scheme "example" is hereby registered as a Permanent 623 scheme for that purpose. 625 The "example" scheme is specified as follows: 627 Scheme syntax: The entire range of allowable syntax specified in 628 [RFC3986] is allowed for "example" URIs. 630 Scheme semantics: URIs in the "example" scheme are to be used for 631 documentation purposes only. The use of "example" URIs must not be 632 used as locators, identify any resources, or specify any particular 633 set of operations. 635 Encoding considerations: See Section 2.5 of [RFC3986] for 636 guidelines. 638 Interoperability considerations: None. 640 Security considerations: None. 642 8.1. "Example" Scheme Registration Request 644 Scheme name: example 646 Status: permanent 648 Applications/protocols that use this scheme name: An "example" URI 649 is to be used for documentation purposes only. It MUST NOT be used 650 for any protocol. 652 Contact: N/A 654 Author/Change controller: IETF 656 References: Section 8 of this RFC XXXX. 657 RFC Editor Note: Replace XXXX with this RFC's reference. 659 9. IANA Considerations 661 Previously, the former "URL Scheme" registry was replaced by the 662 "Uniform Resource Identifier (URI) Schemes" registry. The process 663 was based on [RFC5226] "Expert Review" with an initial (optional) 664 mailing list review. 666 The updated template has an additional field for the status of the 667 scheme, and the procedures for entering new name schemes have been 668 augmented. Section 7 establishes the process for new scheme 669 registration. 671 IANA is requested to do the following: 673 o Update the URI Schemes registry to point to this document. 675 o Combine the "Permanent URI Schemes", "Provisional URI Schemes", 676 and "Historical URI Schemes" sub-registries into a single common 677 registry with an additional "Status" column containing the status 678 (Permanent, Provisional, Historical, or Pending Review), and an 679 additional "Notes" column which is normally empty, but may contain 680 notes approved by the Designated Expert. 682 o Add the "example" URI scheme to the registry (see the template in 683 Section 8.1 for registration). 685 10. Security Considerations 687 All registered values are expected to contain accurate security 688 consideration sections; 'permanent' registered scheme names are 689 expected to contain complete definitions. 691 Information concerning possible security vulnerabilities of a 692 protocol might change over time. Consequently, claims as to the 693 security properties of a registered scheme might change as well. As 694 new vulnerabilities are discovered, information about such 695 vulnerabilities might need to be attached to existing documentation, 696 so that users are not misled as to the true security properties of a 697 registered scheme. 699 11. Acknowledgements 701 Thanks to Mark Nottingham and Graham Klyne and other members of the 702 apps-discuss@ietf.org mailing list for their comments on this 703 document. 705 Many thanks to Patrik Faltstrom, Paul Hoffmann, Ira McDonald, Roy 706 Fielding, Stu Weibel, Tony Hammond, Charles Lindsey, Mark Baker, and 707 other members of the uri@w3.org mailing list for their comments on 708 earlier versions. 710 Parts of this document are based on [RFC2717], [RFC2718] and 711 [RFC3864]. Some of the ideas about use of URIs were taken from the 712 "Architecture of the World Wide Web" [W3CWebArch]. 714 12. References 716 12.1. Normative References 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, March 1997. 721 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 723 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 724 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 725 May 2008. 727 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 728 March 2005. 730 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 731 Resource Identifier (URI): Generic Syntax", STD 66, RFC 732 3986, January 2005. 734 12.2. Informative References 736 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 737 Scheme Names", BCP 35, RFC 2717, November 1999. 739 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 740 "Guidelines for new URL Schemes", RFC 2718, November 1999. 742 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 743 "Uniform Resource Names (URN) Namespace Definition 744 Mechanisms", BCP 66, RFC 3406, October 2002. 746 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 747 Procedures for Message Header Fields", BCP 90, RFC 3864, 748 September 2004. 750 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 751 Identifiers (IRIs)", RFC 3987, January 2005. 753 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 754 Registration Procedures for New URI Schemes", BCP 35, RFC 755 4395, February 2006. 757 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 758 Recommendations for Internationalized Domain Names 759 (IDNs)", RFC 4690, September 2006. 761 [W3CWebArch] 762 W3C Technical Architecture Group, "Architecture of the 763 World Wide Web, Volume One", December 2004, 764 . 766 Appendix A. Changes Since RFC 4395 768 1. Combined the Historical, Permanent, and Provisional URI Schemes 769 registries into one registry with a status column. This is done 770 to make it easier to prevent duplicates and see existing 771 conventions. 773 2. Simplified the process for Provisional registration 774 significantly: changed from Expert Review to First Come First 775 Served, and clarified that mailing list review is not required. 777 3. Added a Notes column for notes approved by the Designated 778 Expert. 780 4. Clarified that a "URI scheme name" and an "IRI scheme name" are 781 the same thing and thus use the same IANA registry. 783 5. Clarified that a registration request falls under the "IETF 784 Contribution" rules, but the scheme's specification need not. 786 6. Added the "example:" URI scheme. 788 7. Added text about when to use Provisional registration. 790 8. Updated convention for Private use schemes to use "." instead of 791 "-" between domain name labels, to reduce chance of collision, 792 and noted that new schemes must only use "." with the reversed 793 domain name convention. 795 9. Recommended that scheme definitions define a "default" operation 796 for when a URI is invoked. 798 10. Moved the following fields out of the scheme registration 799 request template and into the requirements for a scheme 800 specification: Scheme syntax, Scheme semantics, Encoding 801 considerations, Interoperability considerations, and Security 802 considerations. 804 Authors' Addresses 805 Dave Thaler (editor) 806 Microsoft 807 One Microsoft Way 808 Redmond, WA 98052 809 US 811 Phone: +1 425 703 8835 812 Email: dthaler@microsoft.com 814 Tony Hansen 815 AT&T Laboratories 816 200 Laurel Ave. 817 Middletown, NJ 07748 818 USA 820 Email: tony+urireg@maillennium.att.com 822 Ted Hardie 823 Google 825 Phone: +1 408 628 5864 826 Email: ted.ietf@gmail.com 828 Larry Masinter 829 Adobe 830 345 Park Ave. 831 San Jose, CA 95110 832 US 834 Phone: +1 408 536 3024 835 Email: masinter@adobe.com 836 URI: http://larry.masinter.net