idnits 2.17.1 draft-ietf-iri-4395bis-irireg-04.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 : ---------------------------------------------------------------------------- No issues found here. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Scheme semantics: URI/IRIs in the "example" scheme should be used for documentation purposes only. The use of "example" URIs/IRIs must not be used as locators, identify any resources, or specify any particular set of operations. Encoding considerations: See Section 2.5 of [RFC3986] for guidelines. Applications/protocols that use this URI scheme name: The "example" URI should be used for documentation purposes only. It MUST not be used for any protocol. Interoperability considerations: None. Security considerations: None. Contact: N/A Author/Change controller: IETF References: This RFC XXXX. RFC Editor Note: Replace XXXX with this RFC's reference. -- The document date (December 14, 2011) is 4511 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) -- Duplicate reference: RFC3987, mentioned in 'RFC3987', was also mentioned in 'RFC3987bis'. -- 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 T. Hansen 3 Internet-Draft AT&T Laboratories 4 Obsoletes: 4395 (if approved) T. Hardie 5 Intended status: BCP Panasonic Wireless Research Lab 6 Expires: June 16, 2012 L. Masinter 7 Adobe 8 December 14, 2011 10 Guidelines and Registration Procedures for New URI/IRI Schemes 11 draft-ietf-iri-4395bis-irireg-04 13 Abstract 15 This document updates the guidelines and recommendations for the 16 definition of Uniform Resource Identifier (URI) schemes, and extends 17 the registry and guidelines to apply when the schemes are used with 18 Internationalized Resource Identifiers (IRIs). It also updates the 19 process and IANA registry for URI/IRI schemes. It obsoletes RFC 20 4395. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 16, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conformance Guidelines . . . . . . . . . . . . . . . . . . . . 4 58 3. Guidelines for Permanent URI/IRI Scheme Definitions . . . . . 4 59 3.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4 60 3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5 61 3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6 63 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Internationalization and Character Encoding . . . . . . . 7 65 3.7. Clear Security Considerations . . . . . . . . . . . . . . 7 66 3.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 8 67 4. Guidelines for Provisional URI/IRI Scheme Registration . . . . 8 68 5. Guidelines for Historical URI/IRI Scheme Registration . . . . 9 69 6. URI/IRI Scheme Registration Procedure . . . . . . . . . . . . 9 70 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.2. Registration Procedures . . . . . . . . . . . . . . . . . 10 72 6.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 11 73 6.4. URI/IRI Scheme Registration Template . . . . . . . . . . . 11 74 7. The "example" Scheme . . . . . . . . . . . . . . . . . . . . . 12 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 14 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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. As originally defined, 93 URIs only allowed a limited repertoire of characters chosen from US- 94 ASCII. 96 An Interationalized Resource Identifier (IRI), as defined by 97 [RFC3987bis], extends the URI syntax to allow characters from a much 98 greater repertoire, to accomodate resource identifiers from the 99 world's languages. The same schemes used in URIs are used in IRIs. 100 The term Resource Identifier (RI) is used as a shorthand for both 101 URIs and IRIs. [RFC3987] introduced IRIs by defining a mapping 102 between URIs and IRIs; [RFC3987bis] updates that definition, allowing 103 an IRI to be interpreted directly without translating into a URI. 105 This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] 106 and [RFC2718]. Recent documents have used the terms "URI"/"IRI" for 107 all resource identifiers, avoiding the term "URL" and reserving the 108 term "URN" explicitly for those URIs/IRIs using the "urn" scheme name 109 ([RFC2141]). URN "namespaces" ([RFC3406]) are specific to the "urn" 110 scheme and are not covered explicitly by this specification. 112 This document extends the URI scheme registry to be a registry of 113 URI/IRI schemes (i.e., applicable to both URIs and IRIs). This 114 document also provides updated guidelines for the definition of new 115 schemes, for consideration by those who are defining, registering, or 116 evaluating those definitions, as well as a process and mechanism for 117 registering URI/IRI schemes within the IANA URI scheme registry. 118 There is a single namespace for registered schemes. Within that 119 namespace, there are values that are approved as meeting a set of 120 criteria for permanent URI/IRI schemes. Other scheme names may also 121 be registered provisionally or historically, without necessarily 122 meeting those criteria. The intent of the registry is to: 124 o provide a central point of discovery for established URI/IRI 125 scheme names, and easy location of their defining documents; 126 o discourage use of the same scheme name for different purposes; 127 o help those proposing new scheme names to discern established 128 trends and conventions, and avoid names that might be confused 129 with existing ones; 131 o encourage registration by setting a low barrier for provisional 132 registrations. 134 There is no separate, independent registry or registration process 135 for IRIs: the URI Scheme Registry is to be used for both URIs and 136 IRIs. Previously, those who wish to describe resource identifiers 137 that are useful as IRIs were encouraged to define the corresponding 138 URI syntax, and note that the IRI usage follows the rules and 139 transformations defined in [RFC3987]. This document changes that 140 advice to encourage explicit definition of the scheme and allowable 141 syntax elements within the larger character repertoire of IRIs, as 142 defined by [RFC3987bis]. 144 A scheme definition cannot override the overall syntax for IRIs. For 145 example, this means that fragment identifiers (#) cannot be re-used 146 outside the generic syntax restrictions, and in particular scheme- 147 specific syntax cannot override the fragment identifier syntax 148 because it is generic. 150 2. Conformance Guidelines 152 Within this document, the key words MUST, MAY, SHOULD, REQUIRED, 153 RECOMMENDED, and so forth are used within the general meanings 154 established in [RFC2119], within the context that they are 155 requirements on future registration specifications. 157 3. Guidelines for Permanent URI/IRI Scheme Definitions 159 This section gives considerations for new URI/IRI schemes. Meeting 160 these guidelines is REQUIRED for permanent scheme registration. 161 Meeting these guidelines is also RECOMMENDED for provisional 162 registration, as described in Section 4. 164 3.1. Demonstratable, New, Long-Lived Utility 166 The use and deployment of new URI/IRI schemes in the Internet 167 infrastructure may be costly; some parts of URI/IRI processing may be 168 scheme-dependent, and deployed software already processes URIs and 169 IRIs of well-known schemes. Introducing a new scheme may require 170 additional software, not only for client software and user agents but 171 also in additional parts of the network infrastructure (gateways, 172 proxies, caches) [W3CWebArch]. URI/IRI schemes constitute a single, 173 global namespace; it is desirable to avoid contention over use of 174 short, mnemonic scheme names. For these reasons, the unbounded 175 registration of new schemes is harmful. New schemes should have 176 utility to the Internet community beyond that available with already 177 registered schemes. The registration document SHOULD discuss the 178 utility of the scheme being registered. 180 3.2. Syntactic Compatibility 182 [RFC3986] defines the generic syntax for all URI schemes, along with 183 the syntax of common URI components that are used by many URI schemes 184 to define hierarchical identifiers. [RFC3987] and subsequently 185 [RFC3987bis] extended this generic syntax to cover IRIs. All URI/IRI 186 scheme specifications MUST define their own syntax such that all 187 strings matching their scheme-specific syntax will also match the 188 grammar described in [RFC3987bis]. 190 New schemes SHOULD reuse the common components of [RFC3987bis] for 191 the definition of hierarchical naming schemes. However, if there is 192 a strong reason for a scheme not to use the hierarchical syntax, then 193 the new scheme definition SHOULD follow the syntax of previously 194 registered schemes. 196 Schemes that are not intended for use with relative URIs/IRIs SHOULD 197 avoid use of the forward slash "/" character, which is used for 198 hierarchical delimiters, and the complete path segments "." and ".." 199 (dot-segments). 201 Avoid improper use of "//". The use of double slashes in the first 202 part of a URI/IRI is not an artistic indicator that what follows is a 203 URI/IRI: Double slashes are used ONLY when the syntax of the contains a hierarchical structure. In URIs and IRIs 205 from such schemes, the use of double slashes indicates that what 206 follows is the top hierarchical element for a naming authority. 207 (Section 3.2 of RFC 3986 has more details.) Schemes that do not 208 contain a conformant hierarchical structure in their SHOULD NOT use double slashes following the 210 ":" string. 212 New schemes SHOULD clearly define the role of [RFC3986] reserved 213 characters in URIs/IRIs of the scheme being defined. The syntax of 214 the new scheme should be clear about which of the "reserved" set of 215 characters are used as delimiters within the URIs/IRIs of the new 216 scheme, and when those characters must be escaped, versus when they 217 may be used without escaping. 219 3.3. Well-Defined 221 While URIs/IRIs may or may not be defined as locators in practice, a 222 scheme definition itself MUST be clear as to how it is expected to 223 function. Schemes that are not intended to be used as locators 224 SHOULD describe how the resource identified can be determined or 225 accessed by software that obtains a URI/IRI of that scheme. 227 For schemes that function as locators, it is important that the 228 mechanism of resource location be clearly defined. This might mean 229 different things depending on the nature of the scheme. 231 In many cases, new schemes are defined as ways to translate between 232 other namespaces or protocols and the general framework of URIs. For 233 example, the "ftp" scheme translates into the FTP protocol, while the 234 "mid" scheme translates into a Message-ID identifier of an email 235 message. For such schemes, the description of the mapping must be 236 complete, and in sufficient detail so that the mapping in both 237 directions is clear: how to map from a URI/IRI into an identifier or 238 set of protocol actions or name in the target namespace, and how 239 legal values in the base namespace, or legal protocol interactions, 240 might be represented in a valid URI or IRI. In particular, the 241 mapping should describe the mechanisms for encoding binary or 242 character strings within valid character sequences in a URI/IRI (See 243 Section 3.6 for guidelines). If not all legal values or protocol 244 interactions of the base standard can be represented using the 245 scheme, the definition should be clear about which subset are 246 allowed, and why. 248 3.4. Definition of Operations 250 As part of the definition of how a URI/IRI identifies a resource, a 251 scheme definition SHOULD define the applicable set of operations that 252 may be performed on a resource using the RI as its identifier. A 253 model for this is HTTP; an HTTP resource can be operated on by GET, 254 POST, PUT, and a number of other operations available through the 255 HTTP protocol. The scheme definition should describe all well- 256 defined operations on the resource identifier, and what they are 257 supposed to do. 259 Some schemes don't fit into the "information access" paradigm of 260 URIs/IRIs. For example, "telnet" provides location information for 261 initiating a bi-directional data stream to a remote host; the only 262 operation defined is to initiate the connection. In any case, the 263 operations appropriate for a scheme should be documented. 265 Note: It is perfectly valid to say that "no operation apart from GET 266 is defined for this RI". It is also valid to say that "there's only 267 one operation defined for this RI, and it's not very GET-like". The 268 important point is that what is defined on this scheme is described. 270 3.5. Context of Use 272 In general, URIs/IRIs are used within a broad range of protocols and 273 applications. Most commonly, URIs/IRIs are used as references to 274 resources within directories or hypertext documents, as hyperlinks to 275 other resources. In some cases, a scheme is intended for use within 276 a different, specific set of protocols or applications. If so, the 277 scheme definition SHOULD describe the intended use and include 278 references to documentation that define the applications and/or 279 protocols cited. 281 3.6. Internationalization and Character Encoding 283 When describing schemes in which (some of) the elements of the URI or 284 IRI are actually representations of human-readable text, care should 285 be taken not to introduce unnecessary variety in the ways in which 286 characters are encoded into octets and then into characters; see 287 [RFC3987bis] and Section 2.5 of [RFC3986] for guidelines. If URIs/ 288 IRIs of a scheme contain any text fields, the scheme definition MUST 289 describe the ways in which characters are encoded and any 290 compatibility issues with IRIs of the scheme. 292 Specifications for IRIs schemes MUST be described in terms of 293 processing an IRI as a sequence of Unicode codepoints, without 294 reference to the encoding of those code points as a sequence of 295 bytes, using UTF-8 or UTF-16. The scheme specification SHOULD be as 296 restrictive as possible regarding what characters are allowed in the 297 URI/IRI, because some characters can create several different 298 security considerations (see for example [RFC4690]). 300 All percent-encoded variants are automatically included by definition 301 for any character given in an IRI production. This means that if you 302 want to restrict the URI percent-encoded forms in some way, you must 303 restrict the Unicode forms that would lead to them. 305 3.7. Clear Security Considerations 307 Definitions of schemes MUST be accompanied by a clear analysis of the 308 security implications for systems that use the scheme; this follows 309 the practice of Security Consideration sections within IANA 310 registrations [RFC5226]. 312 In particular, Section 7 of RFC 3986 [RFC3986] describes general 313 security considerations for URIs, while [RFC3987bis] gives those for 314 IRIs. The definition of an individual URI/IRI scheme should note 315 which of these apply to the specified scheme. 317 3.8. Scheme Name Considerations 319 Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this 320 sytax remains the same for IRIs. New registered schemes 321 registrations MUST follow this syntax, which only allows a limited 322 repertoire of characters (taken from US-ASCII). Although the syntax 323 for the scheme name in URI/IRIs is case insensitive, the scheme names 324 itself MUST be registered using lowercase letters. 326 URI/IRI scheme names should be short, but also sufficiently 327 descriptive and distinguished to avoid problems. 329 Avoid names or other symbols that might cause problems with rights to 330 use the name in IETF specifications and Internet protocols. For 331 example, be careful with trademark and service mark names. (See 332 Section 7.4 of [RFC3978].) 334 Avoid using names that are either very general purpose or associated 335 in the community with some other application or protocol. Avoid 336 scheme names that are overly general or grandiose in scope (e.g., 337 that allude to their "universal" or "standard" nature.) 339 Organizations that desire a private name space for URI scheme names 340 are encouraged to use a prefix based on their domain name, expressed 341 in reverse order. For example, a URI scheme name of com-example-info 342 might be registered by the vendor that owns the example.com domain 343 name. 345 4. Guidelines for Provisional URI/IRI Scheme Registration 347 Provisional registration can be an intermediate step on the way to 348 permanent registration, e.g., before the scheme specification is 349 finalized. Provisional registration is also appropriate for schemes 350 that are known to be used, but where a definitive specification is 351 not available. There is no time limit for provisional registration. 353 While the guidelines in Section 3 are REQUIRED for permanent 354 registration, they are RECOMMENDED for provisional registration. For 355 a provisional registration, the following are REQUIRED: 357 o The scheme name meets the syntactic requirements of Section 3.8 358 and the encoding requirements of Section 3.6. 359 o There is not already an entry with the same scheme name. (In the 360 unfortunate case that there are multiple, different uses of the 361 same scheme name, the IESG may approve a request to modify an 362 existing entry to note the separate use.) 364 o Contact information identifying the person supplying the 365 registration is included. Previously unregistered schemes 366 discovered in use may be registered by third parties (even if not 367 on behalf of those who created the scheme). In this case, both 368 the registering party and the scheme creator SHOULD be identified. 369 o If no permanent, citable specification for the scheme definition 370 is included, credible reasons for not providing it should be 371 given. 372 o The scheme definition SHOULD include a clear Security 373 Considerations (Section 3.7) or explain why a full security 374 analysis is not available (e.g., in a third-party scheme 375 registration). 376 o If the scheme definition does not meet the guidelines laid out in 377 Section 3, the differences and reasons SHOULD be noted. 379 5. Guidelines for Historical URI/IRI Scheme Registration 381 In some circumstances, it is appropriate to note a URI scheme that 382 was once in use or registered but for whatever reason is no longer in 383 common use or the use is not recommended. In this case, it is 384 possible for an individual to request that the scheme be registered 385 (newly, or as an update to an existing registration) as 'historical'. 386 Any scheme that is no longer in common use MAY be designated as 387 historical; the registration should contain some indication to where 388 the scheme was previously defined or documented. 390 6. URI/IRI Scheme Registration Procedure 392 6.1. General 394 The URI/IRI registration process is described in the terminology of 395 [RFC5226]. The registration process is an optional mailing list 396 review, followed by "Expert Review". The registration request should 397 note the desired status. The Designated Expert will evaluate the 398 request against the criteria of the requested status. In the case of 399 a permanent registration request, the Designated Expert may: 400 o Accept the specification of the scheme for permanent registration. 401 o Suggest provisional registration instead. 402 o Request IETF review and IESG approval; in the meanwhile, suggest 403 provisional registration. 405 URI/IRI scheme definitions contained within other IETF documents 406 (Informational, Experimental, or Standards-Track RFCs) must also 407 undergo Expert Review; in the case of Standards-Track documents, 408 permanent registration status approval is required. 410 The registration procedure for URI schemes is intended to be very 411 lightweight for non-contentious registrations. For the most part, we 412 expect the good sense of submitters and reviewers, guided by these 413 procedures, to achieve an acceptable and useful consensus for the 414 community. 416 In exceptional cases, where the negotiating parties cannot form a 417 consensus, the final arbiter of any contested registration shall be 418 the IESG. 420 If parties achieve consensus on a registration proposal that does not 421 fully conform to the strict wording of this procedure, this should be 422 drawn to the attention of a relevant member of the IESG. 424 6.2. Registration Procedures 426 Someone wishing to register a new URI/IRI scheme MUST: 427 1. Check the IANA URI scheme registry to see whether or not there is 428 already an entry for the desired name. If there is already an 429 entry under the name, choose a different URI scheme name, or 430 update the existing scheme definition. 431 2. Prepare a URI/IRI scheme registration template, as specified in 432 Section 6.4. The scheme registration template may be contained 433 in an Internet Draft, submitted alone, or as part of some other 434 permanently available, stable, protocol specification. The 435 template may also be submitted in some other form (as part of 436 another document or as a stand-alone document), but the contents 437 will be treated as an "IETF Contribution" under the guidelines of 438 [RFC3978]. 439 3. Send a copy of the template or a pointer to the containing 440 document (with specific reference to the section with the 441 template) to the mailing list uri-review@ietf.org, requesting 442 review. In addition, request review on other relevant mailing 443 lists as appropriate. For example, general discussion of URI/IRI 444 syntactical issues could be discussed on uri@w3.org; schemes for 445 a network protocol could be discussed on a mailing list for that 446 protocol. Allow a reasonable time for discussion and comments. 447 Four weeks is reasonable for a permanent registration requests. 448 4. Respond to review comments and make revisions to the proposed 449 registration as needed to bring it into line with the guidelines 450 given in this document. 451 5. Submit the (possibly updated) registration template (or pointer 452 to document containing it) to IANA at iana@iana.org, specifying 453 whether 'permanent' or 'provisional' registration is requested. 455 Upon receipt of a URI/IRI scheme registration request, the following 456 steps MUST be followed: 458 1. IANA checks the submission for completeness; if sections are 459 missing or citations are not correct, IANA may reject the 460 registration request. 461 2. IANA checks the current registry for a entry with the same name; 462 if such a registry exists, IANA may reject the registration 463 request. 464 3. IANA requests Expert Review of the registration request against 465 the corresponding guidelines (from this document.) 466 4. The Designated Expert may request additional review or 467 discussion, as necessary. 468 5. If Expert Review recommends registration 'provisional' or 469 'permanent' registration, IANA adds the registration to the 470 appropriate registry. 471 6. Unless Expert Review has explicitly rejected the registration 472 request within two weeks, IANA should automatically add the 473 registration in the 'provisional' registry. 475 Either based on an explicit request or independently initiated, the 476 Designated Expert or IESG may request the upgrade of a 'provisional' 477 registration to a 'permanent' one. In such cases, IANA should move 478 the corresponding entry from the provisional registry. 480 6.3. Change Control 482 Registrations may be updated in each registry by the same mechanism 483 as required for an initial registration. In cases where the original 484 definition of the scheme is contained in an IESG-approved document, 485 update of the specification also requires IESG approval. 487 Provisional registrations may be updated by the original registrant 488 or anyone designated by the original registrant. In addition, the 489 IESG may reassign responsibility for a provisional registration 490 scheme, or may request specific changes to a scheme registration. 491 This will enable changes to be made to schemes where the original 492 registrant is out of contact, or unwilling or unable to make changes. 494 Transition from 'provisional' to 'permanent' status may be requested 495 and approved in the same manner as a new 'permanent' registration. 496 Transition from 'permanent' to 'historical' status requires IESG 497 approval. Transition from 'provisional' to 'historical' may be 498 requested by anyone authorized to update the provisional 499 registration. 501 6.4. URI/IRI Scheme Registration Template 503 This template describes the fields that must be supplied in a URI/IRI 504 scheme registration request: 506 Resource Identifier (RI) Scheme name: 507 See Section 3.8 for guidelines. 508 Status: 509 This reflects the status requested, and should be one of 510 'permanent', 'provisional', or 'historical'. 511 Scheme syntax: 512 See Section 3.2 for guidelines. 513 Scheme semantics: 514 See Section 3.3 and Section 3.4 for guidelines. 515 Encoding considerations: 516 See Section 3.3 and Section 3.6 for guidelines. 517 Applications/protocols that use this scheme name: 518 See Section 3.5. 519 Interoperability considerations: 520 If the person or group registering the scheme is aware of any 521 details regarding the scheme that might impact interoperability, 522 identify them here. For example: proprietary or uncommon encoding 523 methods; inability to support multibyte character sets; 524 incompatibility with types or versions of any underlying protocol. 525 Security considerations: 526 See Section 3.7 for guidelines. 527 Contact: 528 Person (including contact information) to contact for further 529 information. 530 Author/Change controller: 531 Person (including contact information) authorized to change this. 532 References: 533 Include full citations for all referenced documents. Registration 534 templates for provisional registration may be included in an 535 Internet Draft; when the documents expire or are approved for 536 publication as an RFC, the registration will be updated. 538 7. The "example" Scheme 540 There is a need for a URI/IRI Scheme name that can be used for 541 examples in documentation without fear of conflicts with current or 542 future actual schemes. The URI/IRI Scheme "example" is hereby 543 registered as a Permanent URI/IRI Scheme for that purpose. 544 Scheme name: example 545 Status: permanent 546 Scheme syntax: The entire range of allowable syntax for URI/IRI 547 schemes specified in [RFC3987bis] is allowed for "example" URI/ 548 IRIs. 550 Scheme semantics: URI/IRIs in the "example" scheme should be used 551 for documentation purposes only. The use of "example" URIs/IRIs 552 must not be used as locators, identify any resources, or specify 553 any particular set of operations. 554 Encoding considerations: See Section 2.5 of [RFC3986] for 555 guidelines. 556 Applications/protocols that use this URI scheme name: The "example" 557 URI should be used for documentation purposes only. It MUST not 558 be used for any protocol. 559 Interoperability considerations: None. 560 Security considerations: None. 561 Contact: N/A 562 Author/Change controller: IETF 563 References: This RFC XXXX. 564 RFC Editor Note: Replace XXXX with this RFC's reference. 566 8. IANA Considerations 568 Previously, the former "URL Scheme" registry was replaced by the 569 Uniform Resource Identifier scheme registry. The process was based 570 on [RFC5226] "Expert Review" with an initial (optional) mailing list 571 review. 573 The updated template has an additional field for the status of the 574 scheme, and the procedures for entering new name schemes have been 575 augmented. Section 6 establishes the process for new URI/IRI scheme 576 registration. 578 IANA is requested to update the name of the registry "URI Schemes" to 579 "URI/IRI Schemes". The registry should be updated to point to this 580 document. For the tables within that registry "Permanent URI 581 Schemes" should become "Permanent URI/IRI Schemes", "Provisional URI 582 Schemes" should become "Provisional URI/IRI Schemes", and "Historical 583 URI Schemes" should become "Historical URI/IRI Schemes". 585 The example URI scheme "example" is hereby registered. (See the 586 template above for registration.) 588 9. Security Considerations 590 All registered values are expected to contain accurate security 591 consideration sections; 'permanent' registered scheme names are 592 expected to contain complete definitions. 594 Information concerning possible security vulnerabilities of a 595 protocol may change over time. Consequently, claims as to the 596 security properties of a registered URI/IRI scheme may change as 597 well. As new vulnerabilities are discovered, information about such 598 vulnerabilities may need to be attached to existing documentation, so 599 that users are not misled as to the true security properties of a 600 registered URI scheme. 602 10. Acknowledgements 604 Many thanks to Patrick Faltstrom for his comments on this version. 606 Many thanks to Paul Hoffmann, Ira McDonald, Roy Fielding, Stu Weibel, 607 Tony Hammond, Charles Lindsey, Mark Baker, and other members of the 608 uri@w3.org mailing list for their comments on earlier versions. 610 Parts of this document are based on [RFC2717], [RFC2718] and 611 [RFC3864]. Some of the ideas about use of URIs were taken from the 612 "Architecture of the World Wide Web" [W3CWebArch]. 614 Appendix A. Changes Since RFC 4395 616 1. Significant edits to be clear that a "URI scheme" and an "IRI 617 scheme" are the same thing. 618 2. Added the "example:" URL Scheme. 619 3. Allow for IRI-specific scheme registration. 620 4. Clarify that the URI scheme registry is also the IRI scheme 621 registry. 623 11. References 625 11.1. Normative References 627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 628 Requirement Levels", BCP 14, RFC 2119, March 1997. 630 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 632 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 633 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 634 May 2008. 636 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 637 March 2005. 639 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 640 Resource Identifier (URI): Generic Syntax", STD 66, 641 RFC 3986, January 2005. 643 [RFC3987bis] 644 Duerst, M., Masinter, L., and M. Suignard, 645 "Internationalized Resource Identifiers (IRIs)", 646 September 2010, 647 . 649 11.2. Informative References 651 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 652 Scheme Names", BCP 35, RFC 2717, November 1999. 654 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 655 "Guidelines for new URL Schemes", RFC 2718, November 1999. 657 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 658 "Uniform Resource Names (URN) Namespace Definition 659 Mechanisms", BCP 66, RFC 3406, October 2002. 661 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 662 Procedures for Message Header Fields", BCP 90, RFC 3864, 663 September 2004. 665 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 666 Identifiers (IRIs)", RFC 3987, January 2005. 668 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 669 Registration Procedures for New URI Schemes", BCP 35, 670 RFC 4395, February 2006. 672 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 673 Recommendations for Internationalized Domain Names 674 (IDNs)", RFC 4690, September 2006. 676 [W3CWebArch] 677 W3C Technical Architecture Group, "Architecture of the 678 World Wide Web, Volume One", December 2004, 679 . 681 Authors' Addresses 683 Tony Hansen 684 AT&T Laboratories 685 200 Laurel Ave. 686 Middletown, NJ 07748 687 USA 689 Email: tony+urireg@maillennium.att.com 691 Ted Hardie 692 Panasonic Wireless Research Lab 693 10900 Tantau Ave. 694 Cupertino, CA 695 USA 697 Phone: +1 408 628 5864 698 Email: ted.ietf@gmail.com 700 Larry Masinter 701 Adobe 702 345 Park Ave. 703 San Jose, CA 95110 704 US 706 Phone: +1 408 536 3024 707 Email: masinter@adobe.com 708 URI: http://larry.masinter.net