idnits 2.17.1 draft-thaler-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 (February 14, 2014) is 3722 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 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 (==), 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: August 18, 2014 T. Hardie 7 Google 8 L. Masinter 9 Adobe 10 February 14, 2014 12 Guidelines and Registration Procedures for New URI Schemes 13 draft-thaler-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 August 18, 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. Guidelines for Permanent Scheme Definitions . . . . . . . . . 4 58 3.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4 59 3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5 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 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 12.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 The Uniform Resource Identifier (URI) protocol element and generic 87 syntax is defined by [RFC3986]. Each URI begins with a scheme name, 88 as defined by Section 3.1 of RFC 3986, that refers to a specification 89 for identifiers within that scheme. The URI syntax provides a 90 federated and extensible naming system, where each scheme's 91 specification may further restrict the syntax and define the 92 semantics of identifiers using that scheme. 94 This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] 95 and [RFC2718]. Recent documents have used the term "URI" for all 96 resource identifiers, avoiding the term "URL" and reserving the term 97 "URN" explicitly for those URIs using the "urn" scheme name 98 ([RFC2141]). URN "namespaces" ([RFC3406]) are specific to the "urn" 99 scheme and are not covered explicitly by this specification. 101 This document provides updated guidelines for the definition of new 102 schemes, for consideration by those who are defining, registering, or 103 evaluating those definitions, as well as a process and mechanism for 104 registering schemes within the IANA URI Schemes registry. There is a 105 single namespace for registered schemes. The intent of the registry 106 is to: 108 o provide a central point of discovery for established URI scheme 109 names, and easy location of their defining documents; 111 o discourage use of the same scheme name for different purposes; 113 o help those proposing new scheme names to discern established 114 trends and conventions, and avoid names that might be confused 115 with existing ones; 117 o encourage registration by setting a low barrier for registration. 119 As originally defined, URIs only allowed a limited repertoire of 120 characters chosen from US-ASCII. An Interationalized Resource 121 Identifier (IRI), as defined by [RFC3987], extends the URI syntax to 122 allow characters from a much greater repertoire, to accomodate 123 resource identifiers from the world's languages. RFC 3987 [RFC3987] 124 also defined a mapping between URIs and IRIs. A URI scheme name is 125 the same as the corresponding IRI scheme name. Thus, there is no 126 separate, independent registry or registration process for IRI 127 schemes: the URI Schemes registry is used for both URIs and IRIs. 128 Those who wish to describe resource identifiers that are useful as 129 IRIs should define the corresponding URI syntax, and note that the 130 IRI usage follows the rules and transformations defined in [RFC3987]. 132 [RFC3986] defines the overall syntax for URIs as: 134 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 136 A scheme definition cannot override the overall syntax for URIs. For 137 example, this means that fragment identifiers (#) cannot be re-used 138 outside the generic syntax restrictions. A scheme definition must 139 specify the scheme name and the syntax of the scheme-specific part, 140 which is clarified as follows: 142 URI = scheme ":" scheme-specific-part [ "#" fragment ] 144 scheme-specific-part = hier-part [ "?" query ] 146 2. Terminology 148 Within this document, the key words MUST, MAY, SHOULD, REQUIRED, 149 RECOMMENDED, and so forth are used within the general meanings 150 established in [RFC2119], within the context that they are 151 requirements on future registrations. 153 This document distinguishes between a "scheme specification", being a 154 document defining the syntax and semantics of a scheme, vs. a "scheme 155 registration request" being the request submitted to IANA. The term 156 "scheme definition" refers generically to the syntax and semantics of 157 a scheme, typically documented in a scheme specification. 159 3. Guidelines for Permanent Scheme Definitions 161 This section gives considerations for new schemes. Meeting these 162 guidelines is REQUIRED for permanent scheme registration. Permanent 163 status is appropriate for, but not limited to, use in standards. For 164 IETF Standards-Track documents, Permanent registration status is 165 REQUIRED. 167 3.1. Demonstratable, New, Long-Lived Utility 169 In general, the use and deployment of new schemes in the Internet 170 infrastructure may be costly; some parts of URI processing may be 171 scheme-dependent. Introducing a new scheme may require additional 172 software, not only for client software and user agents but also in 173 additional parts of the network infrastructure (gateways, proxies, 174 caches) [W3CWebArch]. Since scheme names share a single, global 175 namespace, it is desirable to avoid contention over use of short, 176 mnemonic scheme names. New schemes should have utility to the 177 Internet community beyond that available with already registered 178 schemes. The scheme specification SHOULD discuss the utility of the 179 scheme being registered. [[CREF1: Previously, "scheme definition" 180 above was "registration document", which was ambiguous as to whether 181 the scheme specification or the IANA registration request was meant. 182 But the template in this document has no field for this, so updated 183 as currently written. --DT]] 185 3.2. Syntactic Compatibility 187 [RFC3986] defines the generic syntax for all URI schemes, along with 188 the syntax of common URI components that are used by many URI schemes 189 to define hierarchical identifiers. [RFC3987] extended this generic 190 syntax to cover IRIs. All scheme specifications MUST define their 191 own URI syntax. Care must be taken to ensure 192 that all strings matching their scheme-specific syntax will also 193 match the grammar described in [RFC3986]. 195 New schemes SHOULD reuse the common URI components of [RFC3986] for 196 the definition of hierarchical naming schemes. If there is a strong 197 reason for a scheme not to use the hierarchical syntax, then the new 198 scheme definition SHOULD follow the syntax of previously registered 199 schemes. 201 Schemes that are not intended for use with relative URIs SHOULD avoid 202 use of the forward slash "/" character, which is used for 203 hierarchical delimiters, and the complete path segments "." and ".." 204 (dot-segments). 206 Schemes should avoid improper use of "//". The use of double slashes 207 in the first part of a URI is not an artistic indicator that what 208 follows is a URI: Double slashes are intended for use ONLY when the 209 syntax of the contains a hierarchical 210 structure. In URIs from such schemes, the use of double slashes 211 indicates that what follows is the top hierarchical element for a 212 naming authority. (Section 3.2 of RFC 3986 has more details.) 213 Schemes that do not contain a conformant hierarchical structure in 214 their SHOULD NOT use double slashes following 215 the ":" string. 217 New schemes SHOULD clearly define the role of [RFC3986] reserved 218 characters in URIs of the scheme being defined. The syntax of the 219 new scheme should be clear about which of the "reserved" set of 220 characters are used as delimiters within the URIs of the new scheme, 221 and when those characters must be escaped, versus when they may be 222 used without escaping. 224 3.3. Well-Defined 226 While URIs may or may not be defined as locators in practice, a 227 scheme definition itself MUST be clear as to how it is expected to 228 function. Schemes that are not intended to be used as locators 229 SHOULD describe how the resource identified can be determined or 230 accessed by software that obtains a URI of that scheme. 232 For schemes that function as locators, it is important that the 233 mechanism of resource location be clearly defined. This might mean 234 different things depending on the nature of the scheme. 236 In many cases, new schemes are defined as ways to translate between 237 other namespaces or protocols and the general framework of URIs. For 238 example, the "ftp" scheme translates into the FTP protocol, while the 239 "mid" scheme translates into a Message-ID identifier of an email 240 message. For such schemes, the description of the mapping MUST be 241 complete, and in sufficient detail so that the mapping in both 242 directions is clear: how to map from a URI into an identifier or set 243 of protocol actions or name in the target namespace, and how legal 244 values in the base namespace, or legal protocol interactions, might 245 be represented in a valid URI. In particular, the mapping SHOULD 246 describe the mechanisms for encoding binary or character strings 247 within valid character sequences in a URI (see Section 3.6 for 248 guidelines). If not all legal values or protocol interactions of the 249 base standard can be represented using the scheme, the definition 250 SHOULD be clear about which subset are allowed, and why. 252 3.4. Definition of Operations 254 As part of the definition of how a URI identifies a resource, a 255 scheme definition SHOULD define the applicable set of operations that 256 may be performed on a resource using the URI as its identifier. A 257 model for this is HTTP; an HTTP resource can be operated on by GET, 258 POST, PUT, and a number of other operations available through the 259 HTTP protocol. The scheme definition SHOULD describe all well- 260 defined operations on the resource identifier, and what they are 261 supposed to do. 263 Some schemes don't fit into the "information access" paradigm of 264 URIs. For example, "telnet" provides location information for 265 initiating a bi-directional data stream to a remote host; the only 266 operation defined is to initiate the connection. In any case, the 267 operations appropriate for a scheme SHOULD be documented. 269 Note: It is perfectly valid to say that "no operation apart from GET 270 is defined for this URI". It is also valid to say that "there's only 271 one operation defined for this URI, and it's not very GET-like". The 272 important point is that what is defined on this scheme is described. 274 3.5. Context of Use 276 In general, URIs are used within a broad range of protocols and 277 applications. Most commonly, URIs are used as references to 278 resources within directories or hypertext documents, as hyperlinks to 279 other resources. In some cases, a scheme is intended for use within 280 a different, specific set of protocols or applications. If so, the 281 scheme definition SHOULD describe the intended use and include 282 references to documentation that define the applications and/or 283 protocols cited. 285 3.6. Internationalization and Character Encoding 287 When describing schemes in which (some of) the elements of the URI 288 are actually representations of human-readable text, care should be 289 taken not to introduce unnecessary variety in the ways in which 290 characters are encoded into octets and then into URI characters; see 291 [RFC3987] and Section 2.5 of [RFC3986] for guidelines. If URIs of a 292 scheme contain any text fields, the scheme definition MUST describe 293 the ways in which characters are encoded and any compatibility issues 294 with IRIs of the scheme. 296 The scheme specification SHOULD be as restrictive as possible 297 regarding what characters are allowed in the URI, because some 298 characters can create several different security considerations (see, 299 for example [RFC4690]). 301 All percent-encoded variants are automatically included by definition 302 for any character given in an IRI production. This means that if you 303 want to restrict the URI percent-encoded forms in some way, you must 304 restrict the Unicode forms that would lead to them. 306 3.7. Clear Security Considerations 308 Definitions of schemes MUST be accompanied by a clear analysis of the 309 security implications for systems that use the scheme; this follows 310 the practice of Security Consideration sections within IANA 311 registrations [RFC5226]. 313 In particular, Section 7 of RFC 3986 [RFC3986] describes general 314 security considerations for URIs, while [RFC3987] gives those for 315 IRIs. The definition of an individual scheme should note which of 316 these apply to the specified scheme. 318 3.8. Scheme Name Considerations 320 Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this 321 syntax remains the same for IRIs. New registered schemes 322 registrations MUST follow this syntax, which only allows a limited 323 repertoire of characters (taken from US-ASCII). Although the syntax 324 for the scheme name in URIs is case insensitive, the scheme names 325 itself MUST be registered using lowercase letters. 327 Scheme names should be short, but also sufficiently descriptive and 328 distinguished to avoid problems. 330 Avoid names or other symbols that might cause problems with rights to 331 use the name in IETF specifications and Internet protocols. For 332 example, be careful with trademark and service mark names. (See 333 Section 7.4 of [RFC3978].) 335 Avoid using names that are either very general purpose or associated 336 in the community with some other application or protocol. Avoid 337 scheme names that are overly general or grandiose in scope (e.g., 338 that allude to their "universal" or "standard" nature.) 340 Organizations that desire their own namespace for URI scheme names 341 are encouraged to use a prefix based on their domain name, expressed 342 in reverse order. For example, a URI scheme name of com.example.info 343 might be used by the organization that owns the example.com domain 344 name. [[CREF2: Open Issue: Should we define a mechanism to register 345 a scheme prefix ("web+", "ms-", etc.)? --DT]] [[CREF3: Open Issue: 346 Are strings that look like reversed FQDNs (other than grandfathered 347 ones like "iris.beep") reserved for use as such? Proposed answer is 348 Yes, new schemes should not use a "." unless they are actually 349 constructed from a domain name. --DT]] 351 4. Guidelines for Provisional URI Scheme Registration 353 Provisional registration can be used for schemes that are not part of 354 any standard, but that are intended for use (or observed to be in 355 use) outside a private environment within a single organization. 356 Provisional registration can also be used as an intermediate step on 357 the way to permanent registration, e.g., before the scheme 358 specification is finalized as a standard. 360 [[CREF4: Open issue: previously this also RECOMMENDED following the 361 same guidelines as for permanent registration. However, this higher 362 bar disincented people to register schemes at all, and hence 363 interfered with the goals of the registry. Hence tentatively 364 removed, but need to confirm consensus on this. --DT]] For a 365 provisional registration, the following are REQUIRED: 367 o The scheme name meets the syntactic requirements of Section 3.8 368 and the encoding requirements of Section 3.6. 370 o There MUST NOT already be an entry with the same scheme name. (In 371 the unfortunate case that there are multiple, different uses of 372 the same scheme name, the IESG may approve a request to modify an 373 existing entry to note the separate use.) [[CREF5: Open Issue: 374 Must the IESG do this? Why not the Expert Reviewer? --??]] 376 o Contact information identifying the person supplying the 377 registration is included. Previously unregistered schemes 378 discovered in use may be registered by third parties (even if not 379 on behalf of those who created the scheme). In this case, both 380 the registering party and the scheme creator SHOULD be identified. 382 o If no permanent, citable specification for the scheme definition 383 is included, credible reasons for not providing it SHOULD be 384 given. 386 o The scheme definition SHOULD include a clear Security 387 Considerations (Section 3.7) or explain why a full security 388 analysis is not available (e.g., in a third-party scheme 389 registration). 391 o If the scheme definition does not meet the guidelines laid out in 392 Section 3, the differences and reasons SHOULD be noted. 394 5. Guidelines for Historical URI Scheme Registration 396 In some circumstances, it is appropriate to note a scheme that was 397 once in use or registered but for whatever reason is no longer in 398 common use or the use is not recommended. In this case, it is 399 possible for an individual to request that the URI scheme be 400 registered (newly, or as an update to an existing registration) as 401 'historical'. Any scheme that is no longer in common use MAY be 402 designated as historical; the registration should contain some 403 indication to where the scheme was previously defined or documented. 405 6. Guidelines for Private URI Scheme Use 407 Unregistered schemes can cause problems if used outside a private 408 environment within a single organization. For example, the use could 409 leak out beyond the closed environment, or other colliding uses of 410 the same scheme name could occur within the closed environment. As 411 such, a unique namespace (see Section 3.8) should be used, and it is 412 strongly encouraged to do a Provisional registration even in such 413 cases. [[CREF6: TODO: This is closely related to the open issue of 414 prefix registrations. --DT]] 416 7. URI Scheme Registration Procedure 418 7.1. General 420 [[CREF7: We are updating this, but have not made changes. --??]] 421 [[CREF8: Open Issue: Should Provisional status just use First Come 422 First Serve? Someone suggested FCFS with Expert Review afterwards, 423 but the benefit and efficacy of a subsequent Expert Review seems 424 dubious to me and might only serve to deter registrations in the 425 first place, which is the problem we're trying to solve. --DT]] The 426 scheme registration process is described in the terminology of 427 [RFC5226]. The registration process is an optional mailing list 428 review, followed by "Expert Review". The registration request should 429 note the desired status. The Designated Expert will evaluate the 430 request against the criteria of the requested status. In the case of 431 a permanent registration request, the Designated Expert may: 433 o Accept the specification of the scheme for permanent registration. 435 o Suggest provisional registration instead. 437 o Request IETF review and IESG approval; in the meanwhile, suggest 438 provisional registration. 440 Scheme definitions contained within other IETF documents 441 (Informational, Experimental, or Standards-Track RFCs) must also 442 undergo Expert Review; in the case of Standards-Track documents, 443 permanent registration status approval is REQUIRED. 445 The registration procedure is intended to be very lightweight for 446 non-contentious registrations. For the most part, we expect the good 447 sense of submitters and reviewers, guided by these procedures, to 448 achieve an acceptable and useful consensus for the community. 450 In exceptional cases, where the negotiating parties cannot form a 451 consensus, the final arbiter of any contested registration shall be 452 the IESG. 454 [[CREF9: TODO: We don't want this. --??]] If parties achieve 455 consensus on a registration proposal that does not fully conform to 456 the strict wording of this procedure, this should be drawn to the 457 attention of a relevant member of the IESG. 459 7.2. Registration Procedures 461 Someone wishing to register a new scheme MUST: 463 1. Check the IANA URI Schemes registry to see whether there is 464 already an entry for the desired name. If there is already an 465 entry under the name, choose a different scheme name, or update 466 the existing scheme definition. 468 2. Prepare a scheme registration request using the template 469 specified in Section 7.4. The scheme registration request may be 470 contained in an Internet Draft, submitted alone, or as part of 471 some other permanently available, stable, protocol specification. 473 The completed template may also be submitted in some other form 474 (as part of another document or as a stand-alone document), but 475 the contents will be treated as an "IETF Contribution" under the 476 guidelines of [RFC3978]. [[CREF10: Open Issue: I think the last 477 phrase above about RFC 3978 is problematic, as it just serves to 478 discourage registration. For example, third-party registrations 479 may have no way to grant such rights or make such assertions. 480 Similarly, a standard published by another SDO may have policy/ 481 process issues having a request treated as an IETF contribution. 482 Recommend deleting this sentence. --DT]] 484 3. If the registration request is for a Permanent registration: 486 1. Send a copy of the completed template or a pointer to the 487 containing document (with specific reference to the section 488 with the completed template) to the mailing list uri- 489 review@ietf.org , requesting review. In addition, request 490 review on other relevant mailing lists as appropriate. For 491 example, general discussion of URI syntactical issues could 492 be discussed on uri@w3.org; schemes for a network protocol 493 could be discussed on a mailing list for that protocol. 494 Allow a reasonable time for discussion and comments. Four 495 weeks is reasonable for a permanent registration requests. 497 2. Respond to review comments and make revisions to the proposed 498 registration as needed to bring it into line with the 499 guidelines given in this document. 501 4. Submit the (possibly updated) registration template (or pointer 502 to document containing it) to IANA at iana@iana.org. 504 Upon receipt of a scheme registration request, the following steps 505 MUST be followed: 507 1. IANA checks the submission for completeness; if sections are 508 missing or citations are not correct, IANA may reject the 509 registration request. 511 2. IANA checks the current registry for a entry with the same name; 512 if such an entry exists, IANA may reject the registration 513 request. 515 3. IANA enters the registration request in the IANA registry, with 516 status marked as "Pending Review". 518 4. IANA requests Expert Review of the registration request against 519 the corresponding guidelines from this document. 521 5. The Designated Expert may request additional review or 522 discussion, as necessary. 524 6. If Expert Review recommends 'provisional' or 'permanent' 525 registration, IANA adds the registration to the registry with 526 appropriate review. 528 7. Unless Expert Review has explicitly rejected the registration 529 request within two weeks, IANA should automatically add the 530 registration to the registry as 'provisional'. 532 Either based on an explicit request or independently initiated, the 533 Designated Expert or IESG may request the upgrade of a 'provisional' 534 registration to a 'permanent' one. In such cases, IANA should update 535 the status of the corresponding entry. [[CREF11: Open Issue: Say 536 more about guidance to the Designated Expert. Under what 537 circumstance should this happen? --DT]] 539 7.3. Change Control 541 Registrations may be updated in the registry by the same mechanism as 542 required for an initial registration. In cases where the original 543 definition of the scheme is contained in an IESG-approved document, 544 update of the specification also requires IESG approval. 546 Provisional registrations may be updated by the original registrant 547 or anyone designated by the original registrant. In addition, the 548 IESG may reassign responsibility for a provisional registration 549 scheme, or may request specific changes to a scheme registration. 550 This will enable changes to be made to schemes where the original 551 registrant is out of contact, or unwilling or unable to make changes. 553 Transition from 'provisional' to 'permanent' status may be requested 554 and approved in the same manner as a new 'permanent' registration. 555 Transition from 'permanent' to 'historical' status requires IESG 556 approval. Transition from 'provisional' to 'historical' may be 557 requested by anyone authorized to update the provisional 558 registration. 560 7.4. URI Scheme Registration Template 562 This template describes the fields that must be supplied in a scheme 563 registration request: 565 Scheme name: 566 See Section 3.8 for guidelines. 568 Status: 570 This reflects the status requested, and should be one of 571 'permanent', 'provisional', or 'historical'. 573 Scheme syntax: 574 See Section 3.2 for guidelines. 576 Scheme semantics: 577 See Section 3.3 and Section 3.4 for guidelines. 579 Encoding considerations: 580 See Section 3.3 and Section 3.6 for guidelines. 582 Applications/protocols that use this scheme name: 583 See Section 3.5. 585 Interoperability considerations: 586 If the person or group registering the scheme is aware of any 587 details regarding the scheme that might impact interoperability, 588 identify them here. For example: proprietary or uncommon encoding 589 methods; inability to support multibyte character sets; 590 incompatibility with types or versions of any underlying protocol. 592 Security considerations: 593 See Section 3.7 for guidelines. 595 Contact: 596 Person (including contact information) to contact for further 597 information. 599 Author/Change controller: 600 Person (including contact information) authorized to change this. 602 References: 603 Include full citations for all referenced documents. Registration 604 templates for provisional registration may be included in an 605 Internet Draft; when the documents expire or are approved for 606 publication as an RFC, the registration will be updated. 608 [[CREF12: Open Issue: Some of the fields above may serve to deter 609 registration. Should some of them NOT be required for Provisional 610 registrations (including third-party ones)? For example, the 611 requirement to have clear security considerations is not appropriate 612 for third-party registrations. Typically one is forced to fill in 613 something like "Unknown, use with care." These seem to me to be more 614 appropriate inside the specification (if any) in the references, 615 rather than being required in the request template. Thus, as new 616 specifications update the uses (e.g., allow use with another HTTP 617 method), the IANA registry itself shouldn't be required to be 618 updated. --DT]] 620 8. The "example" Scheme 622 There is a need for a scheme name that can be used for examples in 623 documentation without fear of conflicts with current or future actual 624 schemes. The scheme "example" is hereby registered as a Permanent 625 scheme for that purpose. 627 Scheme name: example 629 Status: permanent 631 Scheme syntax: The entire range of allowable syntax specified in 632 [RFC3986] is allowed for "example" URIs. 634 Scheme semantics: URIs in the "example" scheme should be used for 635 documentation purposes only. The use of "example" URIs must not be 636 used as locators, identify any resources, or specify any particular 637 set of operations. 639 Encoding considerations: See Section 2.5 of [RFC3986] for 640 guidelines. 642 Applications/protocols that use this scheme name: An "example" URI 643 should be used for documentation purposes only. It MUST NOT be 644 used for any protocol. 646 Interoperability considerations: None. 648 Security considerations: None. 650 Contact: N/A 652 Author/Change controller: IETF 654 References: This RFC XXXX. 655 RFC Editor Note: Replace XXXX with this RFC's reference. 657 9. IANA Considerations 659 Previously, the former "URL Scheme" registry was replaced by the 660 "Uniform Resource Identifier (URI) Schemes" registry. The process 661 was based on [RFC5226] "Expert Review" with an initial (optional) 662 mailing list review. 664 The updated template has an additional field for the status of the 665 scheme, and the procedures for entering new name schemes have been 666 augmented. Section 7 establishes the process for new scheme 667 registration. 669 IANA is requested to do the following: 671 o Update the URI Schemes registry to point to this document. 673 o Combine the "Permanent URI Schemes", "Provisional URI Schemes", 674 and "Historical URI Schemes" sub-registries into a single common 675 registry with an additional "Status" column containing the status 676 (Permanent, Provisional, Historical, or Pending Review). 678 o Add the "example" URI scheme to the registry (see the template 679 above for registration). 681 10. Security Considerations 683 All registered values are expected to contain accurate security 684 consideration sections; 'permanent' registered scheme names are 685 expected to contain complete definitions. 687 Information concerning possible security vulnerabilities of a 688 protocol may change over time. Consequently, claims as to the 689 security properties of a registered scheme may change as well. As 690 new vulnerabilities are discovered, information about such 691 vulnerabilities may need to be attached to existing documentation, so 692 that users are not misled as to the true security properties of a 693 registered scheme. 695 11. Acknowledgements 697 Many thanks to Patrik Faltstrom, Paul Hoffmann, Ira McDonald, Roy 698 Fielding, Stu Weibel, Tony Hammond, Charles Lindsey, Mark Baker, and 699 other members of the uri@w3.org mailing list for their comments on 700 earlier versions. 702 Parts of this document are based on [RFC2717], [RFC2718] and 703 [RFC3864]. Some of the ideas about use of URIs were taken from the 704 "Architecture of the World Wide Web" [W3CWebArch]. 706 12. References 707 12.1. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, March 1997. 712 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 714 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 715 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 716 May 2008. 718 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 719 March 2005. 721 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 722 Resource Identifier (URI): Generic Syntax", STD 66, RFC 723 3986, January 2005. 725 12.2. Informative References 727 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 728 Scheme Names", BCP 35, RFC 2717, November 1999. 730 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 731 "Guidelines for new URL Schemes", RFC 2718, November 1999. 733 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 734 "Uniform Resource Names (URN) Namespace Definition 735 Mechanisms", BCP 66, RFC 3406, October 2002. 737 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 738 Procedures for Message Header Fields", BCP 90, RFC 3864, 739 September 2004. 741 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 742 Identifiers (IRIs)", RFC 3987, January 2005. 744 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 745 Registration Procedures for New URI Schemes", BCP 35, RFC 746 4395, February 2006. 748 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 749 Recommendations for Internationalized Domain Names 750 (IDNs)", RFC 4690, September 2006. 752 [W3CWebArch] 753 W3C Technical Architecture Group, "Architecture of the 754 World Wide Web, Volume One", December 2004, 755 . 757 Appendix A. Changes Since RFC 4395 759 1. Combined the Historical, Permanent, and Provisional URI Schemes 760 registries into one registry with a status column. This is done 761 to make it easier to prevent duplicates and see existing 762 conventions. 764 2. Clarified that a "URI scheme name" and an "IRI scheme name" are 765 the same thing and thus use the same IANA registry. 767 3. Clarified that mailing list review is not required for 768 Provisional registrations. 770 4. Added the "example:" URI scheme. 772 5. Added text about when to use Provisional registration. 774 6. Updated convention for Private scheme prefix to use "." instead 775 of "-" between domain name labels, to reduce chance of collision. 777 Authors' Addresses 779 Dave Thaler (editor) 780 Microsoft 781 One Microsoft Way 782 Redmond, WA 98052 783 US 785 Phone: +1 425 703 8835 786 Email: dthaler@microsoft.com 788 Tony Hansen 789 AT&T Laboratories 790 200 Laurel Ave. 791 Middletown, NJ 07748 792 USA 794 Email: tony+urireg@maillennium.att.com 795 Ted Hardie 796 Google 798 Phone: +1 408 628 5864 799 Email: ted.ietf@gmail.com 801 Larry Masinter 802 Adobe 803 345 Park Ave. 804 San Jose, CA 95110 805 US 807 Phone: +1 408 536 3024 808 Email: masinter@adobe.com 809 URI: http://larry.masinter.net