idnits 2.17.1 draft-ietf-iri-4395bis-irireg-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 529 has weird spacing: '...me name examp...' == Line 530 has weird spacing: '... Status perma...' == 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: There is a need for a URI/IRI Scheme name that can be used for examples in documentation without fear of conflicts with current or future actual schemes. The URI/IRI Scheme "example" is hereby registered as a Permanent URI/IRI Scheme for that purpose. Scheme name example Status permanent Scheme syntax The entire range of allowable syntax for URI/IRI schemes specified in [RFC3987bis] is allowed for "example" URI/ IRIs. 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 (October 8, 2010) is 4949 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 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) -- Duplicate reference: RFC3987, mentioned in 'RFC3987bis', was also mentioned in 'RFC3987'. -- 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 (~~), 5 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: April 11, 2011 L. Masinter 7 Adobe Systems 8 October 8, 2010 10 Guidelines and Registration Procedures for New URI/IRI Schemes 11 draft-ietf-iri-4395bis-irireg-00 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 April 11, 2011. 39 Copyright Notice 41 Copyright (c) 2010 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 . . . . . . . . . 5 60 3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5 61 3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 12 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 14 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 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 semantics of 92 identifiers using that scheme. As originally defined, URIs only 93 allowed a limited repertoire of characters chosen from US-ASCII. An 94 Interationalized Resource Identifier (IRI) as defined by 95 [RFC3987bis], extends the URI syntax to allow characters from a much 96 greater repertoire, to accomodate resource identifiers from the 97 world's languages. The same schemes used in URIs are used in IRIs. 98 The term Resource Identifier (RI) is used as a shorthand for both 99 URIs and IRIs. 101 This document extends the URI scheme registry to be a registry of 102 URI/IRI schemes (i.e., applicable to both URIs and IRIs). This 103 document also provides updated guidelines for the definition of new 104 schemes, for consideration by those who are defining, registering, or 105 evaluating those definitions, as well as a process and mechanism for 106 registering URI/IRI schemes within the IANA URI scheme registry. The 107 registry has two parts: 'provisional' and 'permanent', with different 108 requirements. Guidelines and requirements for both parts are given. 110 This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] 111 and [RFC2718]. RFCs 2717 and 2718 drew a distinction between 112 'locators' (identifiers used for accessing resources available on the 113 Internet) and 'names' (identifiers used for naming possibly abstract 114 resources, independent of any mechanism for accessing them). The 115 intent was to use the designation "URL" (Uniform Resource Locator) 116 for those identifiers that were locators and "URN" (Uniform Resource 117 Name) for those identifiers that were names. In practice, the line 118 between 'locator' and 'name' has been difficult to draw: locators can 119 be used as names, and names can be used as locators. As a result, 120 recent documents have used the terms "URI"/"IRI" for all resource 121 identifiers, avoiding the term "URL" and reserving the term "URN" 122 explicitly for those URIs/IRIs using the "urn" scheme name 123 ([RFC2141]). URN "namespaces" ([RFC3406]) are specific to the "urn" 124 scheme and not covered explicitly by this specification. 126 RFC 2717 defined a set of registration trees in which URI schemes 127 could be registered, one of which was called the IETF Tree, to be 128 managed by IANA. RFC 2717 proposed that additional registration 129 trees might be approved by the IESG. However, no such registration 130 trees have been submitted. This document eliminates RFC 2717's 131 distinction between different 'trees' for URI schemes; instead there 132 is a single namespace for registered values. Within that namespace, 133 there are values that are approved as meeting a set of criteria for 134 URI schemes. Other scheme names may also be registered 135 provisionally, without necessarily meeting those criteria. The 136 intent of the registry is to: 138 o provide a central point of discovery for established URI/IRI 139 scheme names, and easy location of their defining documents; 140 o discourage use of the same scheme name for different purposes; 141 o help those proposing new scheme names to discern established 142 trends and conventions, and avoid names that might be confused 143 with existing ones; 144 o encourage registration by setting a low barrier for provisional 145 registrations. 147 [RFC3987] introduced a new protocol element, the Internationalized 148 Resource Identifier (IRI), by defining a mapping between URIs and 149 IRIs. [RFC3987bis] updates this definition, allowing an IRI to be 150 interpreted directly without translating into a URI. There is no 151 separate, independent registry or registration process for IRIs: the 152 URI Scheme Registry is to be used for both URIs and IRIs. 153 Previously, those who wish to describe resource identifiers that are 154 useful as IRIs were encouraged to define the corresponding URI 155 syntax, and note that the IRI usage follows the rules and 156 transformations defined in [RFC3987]. This document changes that 157 advice to encourage explicit definition of the scheme and allowable 158 syntax elements within the larger character repertoire of IRIs, as 159 defined by [RFC3987bis]. 161 2. Conformance Guidelines 163 Within this document, the key words MUST, MAY, SHOULD, REQUIRED, 164 RECOMMENDED, and so forth are used within the general meanings 165 established in [RFC2119], within the context that they are 166 requirements on future registration specifications. 168 3. Guidelines for Permanent URI/IRI Scheme Definitions 170 This section gives considerations for new URI/IRI schemes. Meeting 171 these guidelines is REQUIRED for permanent scheme registration. 172 Meeting these guidelines is also RECOMMENDED for provisional 173 registration, as described in Section 4. 175 3.1. Demonstratable, New, Long-Lived Utility 177 The use and deployment of new URI/IRI schemes in the Internet 178 infrastructure is costly; some parts of URI/IRI processing may be 179 scheme-dependent, and deployed software already processes URIs and 180 IRIs of well-known schemes. Introducing a new scheme may require 181 additional software, not only for client software and user agents but 182 also in additional parts of the network infrastructure (gateways, 183 proxies, caches) [W3CWebArch]. URI/IRI schemes constitute a single, 184 global namespace; it is desirable to avoid contention over use of 185 short, mnemonic scheme names. For these reasons, the unbounded 186 registration of new schemes is harmful. New URI/IRI schemes SHOULD 187 have clear utility to the broad Internet community, beyond that 188 available with already registered URI/IRI schemes. 190 3.2. Syntactic Compatibility 192 [RFC3986] defines the generic syntax for all URI schemes, along with 193 the syntax of common URI components that are used by many URI schemes 194 to define hierarchical identifiers. [RFC3987] and [RFC3987bis] 195 extended this generic syntax to cover IRIs. All URI/IRI scheme 196 specifications MUST define their own syntax such that all strings 197 matching their scheme-specific syntax will also match the 198 grammar described in [RFC3987bis]. 200 New schemes SHOULD reuse the common components of [RFC3987bis] for 201 the definition of hierarchical naming schemes. However, if there is 202 a strong reason for a scheme not to use the hierarchical syntax, then 203 the new scheme definition SHOULD follow the syntax of previously 204 registered schemes. 206 Schemes that are not intended for use with relative URIs/IRIs SHOULD 207 avoid use of the forward slash "/" character, which is used for 208 hierarchical delimiters, and the complete path segments "." and ".." 209 (dot-segments). 211 Avoid improper use of "//". The use of double slashes in the first 212 part of a URI/IRI is not an artistic indicator that what follows is a 213 URI/IRI: Double slashes are used ONLY when the syntax of the contains a hierarchical structure. In URIs and IRIs 215 from such schemes, the use of double slashes indicates that what 216 follows is the top hierarchical element for a naming authority. 217 (Section 3.2 of RFC 3986 has more details.) Schemes that do not 218 contain a conformant hierarchical structure in their SHOULD NOT use double slashes following the 220 ":" string. 222 New schemes SHOULD clearly define the role of [RFC3986] reserved 223 characters in URIs/IRIs of the scheme being defined. The syntax of 224 the new scheme should be clear about which of the "reserved" set of 225 characters are used as delimiters within the URIs/IRIs of the new 226 scheme, and when those characters must be escaped, versus when they 227 may be used without escaping. 229 3.3. Well-Defined 231 While URIs/IRIs may or may not be defined as locators in practice, a 232 scheme definition itself MUST be clear as to how it is expected to 233 function. Schemes that are not intended to be used as locators 234 SHOULD describe how the resource identified can be determined or 235 accessed by software that obtains a URI/IRI of that scheme. 237 For schemes that function as locators, it is important that the 238 mechanism of resource location be clearly defined. This might mean 239 different things depending on the nature of the scheme. 241 In many cases, new schemes are defined as ways to translate between 242 other namespaces or protocols and the general framework of URIs. For 243 example, the "ftp" scheme translates into the FTP protocol, while the 244 "mid" scheme translates into a Message-ID identifier of an email 245 message. For such schemes, the description of the mapping must be 246 complete, and in sufficient detail so that the mapping in both 247 directions is clear: how to map from a URI/IRI into an identifier or 248 set of protocol actions or name in the target namespace, and how 249 legal values in the base namespace, or legal protocol interactions, 250 might be represented in a valid URI or IRI. In particular, the 251 mapping should describe the mechanisms for encoding binary or 252 character strings within valid character sequences in a URI/IRI (See 253 Section 3.6 for guidelines). If not all legal values or protocol 254 interactions of the base standard can be represented using the 255 scheme, the definition should be clear about which subset are 256 allowed, and why. 258 3.4. Definition of Operations 260 As part of the definition of how a URI/IRI identifies a resource, a 261 scheme definition SHOULD define the applicable set of operations that 262 may be performed on a resource using the RI as its identifier. A 263 model for this is HTTP; an HTTP resource can be operated on by GET, 264 POST, PUT, and a number of other operations available through the 265 HTTP protocol. The scheme definition should describe all well- 266 defined operations on the resource identifier, and what they are 267 supposed to do. 269 Some schemes don't fit into the "information access" paradigm of 270 URIs/IRIs. For example, "telnet" provides location information for 271 initiating a bi-directional data stream to a remote host; the only 272 operation defined is to initiate the connection. In any case, the 273 operations appropriate for a scheme should be documented. 275 Note: It is perfectly valid to say that "no operation apart from GET 276 is defined for this RI". It is also valid to say that "there's only 277 one operation defined for this RI, and it's not very GET-like". The 278 important point is that what is defined on this scheme is described. 280 3.5. Context of Use 282 In general, URIs/IRIs are used within a broad range of protocols and 283 applications. Most commonly, URIs/IRIs are used as references to 284 resources within directories or hypertext documents, as hyperlinks to 285 other resources. In some cases, a scheme is intended for use within 286 a different, specific set of protocols or applications. If so, the 287 scheme definition SHOULD describe the intended use and include 288 references to documentation that define the applications and/or 289 protocols cited. 291 3.6. Internationalization and Character Encoding 293 When describing schemes in which (some of) the elements of the URI or 294 IRI are actually representations of human-readable text, care should 295 be taken not to introduce unnecessary variety in the ways in which 296 characters are encoded into octets and then into characters; see 297 [RFC3987bis] and Section 2.5 of [RFC3986] for guidelines. If URIs/ 298 IRIs of a scheme contain any text fields, the scheme definition MUST 299 describe the ways in which characters are encoded and any 300 compatibility issues with IRIs of the scheme. 302 Specifications for IRIs schemes MUST be described in terms of 303 processing an IRI as a sequence of Unicode codepoints, without 304 reference to the encoding of those code points as a sequence of 305 bytes, using UTF-8 or UTF-16. The scheme specification SHOULD be as 306 restrictive as possible regarding what characters are allowed in the 307 URI/IRI, because some characters can create several different 308 security considerations (see for example [RFC4690]). 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 [RFC2434]. 317 In particular, Section 7 of RFC 3986 [RFC3986] describes general 318 security considerations for URIs, while Section ??? of [RFC3987bis] 319 gives those for IRIs. The definition of an individual URI/IRI scheme 320 should note which of 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 sytax 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 URI/IRIs is case insensitive, the scheme names 329 itself MUST be registered using lowercase letters. 331 URI/IRI scheme names should be short, but also sufficiently 332 descriptive and distinguished to avoid problems. 334 Avoid names or other symbols that might cause problems with rights to 335 use the name in IETF specifications and Internet protocols. For 336 example, be careful with trademark and service mark names. (See 337 Section 7.4 of [RFC3978].) 339 Avoid using names that are either very general purpose or associated 340 in the community with some other application or protocol. Avoid 341 scheme names that are overly general or grandiose in scope (e.g., 342 that allude to their "universal" or "standard" nature.) 344 Organizations that desire a private name space for URI scheme names 345 are encouraged to use a prefix based on their domain name, expressed 346 in reverse order. For example, a URI scheme name of com-example-info 347 might be registered by the vendor that owns the example.com domain 348 name. 350 4. Guidelines for Provisional URI/IRI Scheme Registration 352 While the guidelines in Section 3 are REQUIRED for permanent 353 registration, they are RECOMMENDED for provisional registration. For 354 a provisional registration, the following are REQUIRED: 356 o The scheme name meets the syntactic requirements of Section 3.8. 357 o There is not already an entry with the same scheme name. (In the 358 unfortunate case that there are multiple, different uses of the 359 same scheme name, the IESG may approve a request to modify an 360 existing entry to note the separate use.) 361 o Contact information identifying the person supplying the 362 registration is included. Previously unregistered schemes 363 discovered in use may be registered by third parties (even if not 364 on behalf of those who created the scheme). In this case, both 365 the registering party and the scheme creator SHOULD be identified. 367 o If no permanent, citable specification for the scheme definition 368 is included, credible reasons for not providing it should be 369 given. 370 o A valid Security Considerations section, as required by Section 6 371 of [RFC2434]. 372 o If the scheme definition does not meet the guidelines laid out in 373 Section 3, the differences and reasons SHOULD be noted. 375 5. Guidelines for Historical URI/IRI Scheme Registration 377 In some circumstances, it is appropriate to note a URI scheme that 378 was once in use or registered but for whatever reason is no longer in 379 common use or the use is not recommended. In this case, it is 380 possible for an individual to request that the scheme be registered 381 (newly, or as an update to an existing registration) as 'historical'. 382 Any scheme that is no longer in common use MAY be designated as 383 historical; the registration should contain some indication to where 384 the scheme was previously defined or documented. 386 6. URI/IRI Scheme Registration Procedure 388 6.1. General 390 The URI/IRI registration process is described in the terminology of 391 [RFC2434]. The registration process is an optional mailing list 392 review, followed by "Expert Review". The registration request should 393 note the desired status. The Designated Expert will evaluate the 394 request against the criteria of the requested status. In the case of 395 a permanent registration request, the Designated Expert may: 396 o Accept the specification of the scheme for permanent registration. 397 o Suggest provisional registration instead. 398 o Request IETF review and IESG approval; in the meanwhile, suggest 399 provisional registration. 401 URI/IRI scheme definitions contained within other IETF documents 402 (Informational, Experimental, or Standards-Track RFCs) must also 403 undergo Expert Review; in the case of Standards-Track documents, 404 permanent registration status approval is required. 406 6.2. Registration Procedures 408 Someone wishing to register a new URI/IRI scheme SHOULD: 410 1. Check the IANA URI scheme registry to see whether or not there is 411 already an entry for the desired name. If there is already an 412 entry under the name, choose a different URI scheme name, or 413 update the existing scheme definition. 414 2. Prepare a URI/IRI scheme registration template, as specified in 415 Section 6.4. The scheme registration template may be contained 416 in an Internet Draft, submitted alone, or as part of some other 417 permanently available, stable, protocol specification. The 418 template may also be submitted in some other form (as part of 419 another document or as a stand-alone document), but the contents 420 will be treated as an "IETF Contribution" under the guidelines of 421 [RFC3978]. 422 3. Send a copy of the template or a pointer to the containing 423 document (with specific reference to the section with the 424 template) to the mailing list uri-review@ietf.org, requesting 425 review. In addition, request review on other relevant mailing 426 lists as appropriate. For example, general discussion of URI/IRI 427 syntactical issues could be discussed on uri@w3.org; schemes for 428 a network protocol could be discussed on a mailing list for that 429 protocol. Allow a reasonable time for discussion and comments. 430 Four weeks is reasonable for a permanent registration requests. 431 4. Respond to review comments and make revisions to the proposed 432 registration as needed to bring it into line with the guidelines 433 given in this document. 434 5. Submit the (possibly updated) registration template (or pointer 435 to document containing it) to IANA at iana@iana.org, specifying 436 whether 'permanent' or 'provisional' registration is requested. 438 Upon receipt of a URI/IRI scheme registration request, the following 439 steps MUST be followed: 441 1. IANA checks the submission for completeness; if sections are 442 missing or citations are not correct, IANA may reject the 443 registration request. 444 2. IANA checks the current registry for a entry with the same name; 445 if such a registry exists, IANA may reject the registration 446 request. 447 3. IANA requests Expert Review of the registration request against 448 the corresponding guidelines (from this document.) 449 4. The Designated Expert may request additional review or 450 discussion, as necessary. 451 5. If Expert Review recommends registration 'provisional' or 452 'permanent' registration, IANA adds the registration to the 453 appropriate registry. 454 6. Unless Expert Review has explicitly rejected the registration 455 request within two weeks, IANA should automatically add the 456 registration in the 'provisional' registry. 458 Either based on an explicit request or independently initiated, the 459 Designated Expert or IESG may request the upgrade of a 'provisional' 460 registration to a 'permanent' one. In such cases, IANA should move 461 the corresponding entry from the provisional registry. 463 6.3. Change Control 465 Registrations may be updated in each registry by the same mechanism 466 as required for an initial registration. In cases where the original 467 definition of the scheme is contained in an IESG-approved document, 468 update of the specification also requires IESG approval. 470 Provisional registrations may be updated by the original registrant 471 or anyone designated by the original registrant. In addition, the 472 IESG may reassign responsibility for a provisional registration 473 scheme, or may request specific changes to a scheme registration. 474 This will enable changes to be made to schemes where the original 475 registrant is out of contact, or unwilling or unable to make changes. 477 Transition from 'provisional' to 'permanent' status may be requested 478 and approved in the same manner as a new 'permanent' registration. 479 Transition from 'permanent' to 'historical' status requires IESG 480 approval. Transition from 'provisional' to 'historical' may be 481 requested by anyone authorized to update the provisional 482 registration. 484 6.4. URI/IRI Scheme Registration Template 486 This template describes the fields that must be supplied in a URI/IRI 487 scheme registration request: 489 Resource Identifier (RI) Scheme name. 490 See Section 3.8 for guidelines. 491 Status. 492 This reflects the status requested, and should be one of 493 'permanent', 'provisional', or 'historical'. 494 Scheme syntax. 495 See Section 3.2 for guidelines. 496 Scheme semantics. 497 See Section 3.3 and Section 3.4 for guidelines. 498 Encoding considerations. 499 See Section 3.3 and Section 3.6 for guidelines. 500 Applications/protocols that use this scheme name. 501 See Section 3.5. 502 Interoperability considerations. 503 If the person or group registering the scheme is aware of any 504 details regarding the scheme that might impact interoperability, 505 identify them here. For example: proprietary or uncommon encoding 506 methods; inability to support multibyte character sets; 507 incompatibility with types or versions of any underlying protocol. 509 Security considerations. 510 See Section 3.7 for guidelines. 511 Contact. 512 Person (including contact information) to contact for further 513 information. 514 Author/Change controller. 515 Person (including contact information) authorized to change this, 516 if a provisional registration. 517 References. 518 Include full citations for all referenced documents. Registration 519 templates for provisional registration may be included in an 520 Internet Draft; when the documents expire or are approved for 521 publication as an RFC, the registration will be updated. 523 7. The "example" Scheme 525 There is a need for a URI/IRI Scheme name that can be used for 526 examples in documentation without fear of conflicts with current or 527 future actual schemes. The URI/IRI Scheme "example" is hereby 528 registered as a Permanent URI/IRI Scheme for that purpose. 529 Scheme name example 530 Status permanent 531 Scheme syntax The entire range of allowable syntax for URI/IRI 532 schemes specified in [RFC3987bis] is allowed for "example" URI/ 533 IRIs. 534 Scheme semantics URI/IRIs in the "example" scheme should be used for 535 documentation purposes only. The use of "example" URIs/IRIs must 536 not be used as locators, identify any resources, or specify any 537 particular set of operations. 538 Encoding considerations See Section 2.5 of [RFC3986] for guidelines. 539 Applications/protocols that use this URI scheme name The "example" 540 URI should be used for documentation purposes only. It MUST not 541 be used for any protocol. 542 Interoperability considerations None. 543 Security considerations None. 544 Contact N/A 545 Author/Change controller IETF 546 References This RFC XXXX. 547 RFC Editor Note: Replace XXXX with this RFC's reference. 549 8. IANA Considerations 551 Previously, the former "URL Scheme" registry was replaced by the 552 Uniform Resource Identifier scheme registry. The process was based 553 on [RFC2434] "Expert Review" with an initial (optional) mailing list 554 review. 556 The updated template has an additional field for the status of the 557 scheme, and the procedures for entering new name schemes have been 558 augmented. Section 6 establishes the process for new URI/IRI scheme 559 registration. 561 The example URI scheme "example" is hereby registered. (See the 562 template above for registration.) 564 9. Security Considerations 566 All registered values are expected to contain accurate security 567 consideration sections; 'permanent' registered scheme names are 568 expected to contain complete definitions. 570 Information concerning possible security vulnerabilities of a 571 protocol may change over time. Consequently, claims as to the 572 security properties of a registered URI/IRI scheme may change as 573 well. As new vulnerabilities are discovered, information about such 574 vulnerabilities may need to be attached to existing documentation, so 575 that users are not misled as to the true security properties of a 576 registered URI scheme. 578 10. Acknowledgements 580 Many thanks to Patrick Faltstrom for his comments on this version. 582 Many thanks to Paul Hoffmann, Ira McDonald, Roy Fielding, Stu Weibel, 583 Tony Hammond, Charles Lindsey, Mark Baker, and other members of the 584 uri@w3.org mailing list for their comments on earlier versions. 586 Parts of this document are based on [RFC2717], [RFC2718] and 587 [RFC3864]. Some of the ideas about use of URIs were taken from the 588 "Architecture of the World Wide Web" [W3CWebArch]. 590 Appendix A. Changes Since RFC 4395 592 1. Significant edits to be clear that a "URI scheme" and an "IRI 593 scheme" are the same thing. 594 2. Added the "example:" URL Scheme. 595 3. Allow for IRI-specific scheme registration. 596 4. Clarify that the URI scheme registry is also the IRI scheme 597 registry. 599 11. References 601 11.1. Normative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 608 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 609 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 610 October 1998. 612 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 613 March 2005. 615 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 616 Resource Identifier (URI): Generic Syntax", STD 66, 617 RFC 3986, January 2005. 619 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 620 Identifiers (IRIs)", RFC 3987, January 2005. 622 [RFC3987bis] 623 Duerst, M., Masinter, L., and M. Suignard, 624 "Internationalized Resource Identifiers (IRIs)", 625 September 2010, 626 . 628 11.2. Informative References 630 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 631 Scheme Names", BCP 35, RFC 2717, November 1999. 633 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 634 "Guidelines for new URL Schemes", RFC 2718, November 1999. 636 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 637 "Uniform Resource Names (URN) Namespace Definition 638 Mechanisms", BCP 66, RFC 3406, October 2002. 640 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 641 Procedures for Message Header Fields", BCP 90, RFC 3864, 642 September 2004. 644 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 645 Registration Procedures for New URI Schemes", BCP 35, 646 RFC 4395, February 2006. 648 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 649 Recommendations for Internationalized Domain Names 650 (IDNs)", RFC 4690, September 2006. 652 [W3CWebArch] 653 W3C Technical Architecture Group, "Architecture of the 654 World Wide Web, Volume One", December 2004, 655 . 657 Authors' Addresses 659 Tony Hansen 660 AT&T Laboratories 661 200 Laurel Ave. 662 Middletown, NJ 07748 663 USA 665 Email: tony+urireg@maillennium.att.com 667 Ted Hardie 668 Panasonic Wireless Research Lab 669 10900 Tantau Ave. 670 Cupertino, CA 671 USA 673 Phone: +1 408 628 5864 674 Email: ted.ietf@gmail.com 675 Larry Masinter 676 Adobe Systems 677 345 Park Ave. 678 San Jose, CA 95110 679 US 681 Phone: +1 408 536 3024 682 Email: masinter@adobe.com 683 URI: http://larry.masinter.net