--- 1/draft-ietf-iri-4395bis-irireg-01.txt 2011-07-28 20:17:01.000000000 +0200 +++ 2/draft-ietf-iri-4395bis-irireg-02.txt 2011-07-28 20:17:01.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group T. Hansen Internet-Draft AT&T Laboratories Obsoletes: 4395 (if approved) T. Hardie Intended status: BCP Panasonic Wireless Research Lab -Expires: September 30, 2011 L. Masinter +Expires: January 29, 2012 L. Masinter Adobe - March 29, 2011 + July 28, 2011 Guidelines and Registration Procedures for New URI/IRI Schemes - draft-ietf-iri-4395bis-irireg-01 + draft-ietf-iri-4395bis-irireg-02 Abstract This document updates the guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes, and extends the registry and guidelines to apply when the schemes are used with Internationalized Resource Identifiers (IRIs). It also updates the process and IANA registry for URI/IRI schemes. It obsoletes RFC 4395. @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 30, 2011. + This Internet-Draft will expire on January 29, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -49,25 +49,25 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conformance Guidelines . . . . . . . . . . . . . . . . . . . . 4 3. Guidelines for Permanent URI/IRI Scheme Definitions . . . . . 4 - 3.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 5 + 3.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4 3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5 - 3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6 - 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 7 + 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Internationalization and Character Encoding . . . . . . . 7 3.7. Clear Security Considerations . . . . . . . . . . . . . . 7 3.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 8 4. Guidelines for Provisional URI/IRI Scheme Registration . . . . 8 5. Guidelines for Historical URI/IRI Scheme Registration . . . . 9 6. URI/IRI Scheme Registration Procedure . . . . . . . . . . . . 9 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Registration Procedures . . . . . . . . . . . . . . . . . 10 6.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 11 6.4. URI/IRI Scheme Registration Template . . . . . . . . . . . 11 @@ -81,90 +81,79 @@ 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The Uniform Resource Identifier (URI) protocol element and generic syntax is defined by [RFC3986]. Each URI begins with a scheme name, as defined by Section 3.1 of RFC 3986, that refers to a specification for identifiers within that scheme. The URI syntax provides a federated and extensible naming system, where each scheme's - specification may further restrict the syntax and semantics of - identifiers using that scheme. As originally defined, URIs only - allowed a limited repertoire of characters chosen from US-ASCII. An - Interationalized Resource Identifier (IRI) as defined by + specification may further restrict the syntax and define the + semantics of identifiers using that scheme. As originally defined, + URIs only allowed a limited repertoire of characters chosen from US- + ASCII. + + An Interationalized Resource Identifier (IRI), as defined by [RFC3987bis], extends the URI syntax to allow characters from a much greater repertoire, to accomodate resource identifiers from the world's languages. The same schemes used in URIs are used in IRIs. The term Resource Identifier (RI) is used as a shorthand for both - URIs and IRIs. + URIs and IRIs. [RFC3987] introduced IRIs by defining a mapping + between URIs and IRIs; [RFC3987bis] updates that definition, allowing + an IRI to be interpreted directly without translating into a URI. + + This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] + and [RFC2718]. Recent documents have used the terms "URI"/"IRI" for + all resource identifiers, avoiding the term "URL" and reserving the + term "URN" explicitly for those URIs/IRIs using the "urn" scheme name + ([RFC2141]). URN "namespaces" ([RFC3406]) are specific to the "urn" + scheme and are not covered explicitly by this specification. This document extends the URI scheme registry to be a registry of URI/IRI schemes (i.e., applicable to both URIs and IRIs). This document also provides updated guidelines for the definition of new schemes, for consideration by those who are defining, registering, or evaluating those definitions, as well as a process and mechanism for - registering URI/IRI schemes within the IANA URI scheme registry. The - registry has two parts: 'provisional' and 'permanent', with different - requirements. Guidelines and requirements for both parts are given. - - This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] - and [RFC2718]. RFCs 2717 and 2718 drew a distinction between - 'locators' (identifiers used for accessing resources available on the - Internet) and 'names' (identifiers used for naming possibly abstract - resources, independent of any mechanism for accessing them). The - intent was to use the designation "URL" (Uniform Resource Locator) - for those identifiers that were locators and "URN" (Uniform Resource - Name) for those identifiers that were names. In practice, the line - between 'locator' and 'name' has been difficult to draw: locators can - be used as names, and names can be used as locators. As a result, - recent documents have used the terms "URI"/"IRI" for all resource - identifiers, avoiding the term "URL" and reserving the term "URN" - explicitly for those URIs/IRIs using the "urn" scheme name - ([RFC2141]). URN "namespaces" ([RFC3406]) are specific to the "urn" - scheme and not covered explicitly by this specification. - - RFC 2717 defined a set of registration trees in which URI schemes - could be registered, one of which was called the IETF Tree, to be - managed by IANA. RFC 2717 proposed that additional registration - trees might be approved by the IESG. However, no such registration - trees have been submitted. This document eliminates RFC 2717's - distinction between different 'trees' for URI schemes; instead there - is a single namespace for registered values. Within that namespace, - there are values that are approved as meeting a set of criteria for - URI schemes. Other scheme names may also be registered - provisionally, without necessarily meeting those criteria. The - intent of the registry is to: + registering URI/IRI schemes within the IANA URI scheme registry. + There is a single namespace for registered schemes. Within that + namespace, there are values that are approved as meeting a set of + criteria for permanent URI/IRI schemes. Other scheme names may also + be registered provisionally or historically, without necessarily + meeting those criteria. The intent of the registry is to: o provide a central point of discovery for established URI/IRI scheme names, and easy location of their defining documents; o discourage use of the same scheme name for different purposes; o help those proposing new scheme names to discern established trends and conventions, and avoid names that might be confused with existing ones; + o encourage registration by setting a low barrier for provisional registrations. - [RFC3987] introduced a new protocol element, the Internationalized - Resource Identifier (IRI), by defining a mapping between URIs and - IRIs. [RFC3987bis] updates this definition, allowing an IRI to be - interpreted directly without translating into a URI. There is no - separate, independent registry or registration process for IRIs: the - URI Scheme Registry is to be used for both URIs and IRIs. - Previously, those who wish to describe resource identifiers that are - useful as IRIs were encouraged to define the corresponding URI - syntax, and note that the IRI usage follows the rules and + There is no separate, independent registry or registration process + for IRIs: the URI Scheme Registry is to be used for both URIs and + IRIs. Previously, those who wish to describe resource identifiers + that are useful as IRIs were encouraged to define the corresponding + URI syntax, and note that the IRI usage follows the rules and transformations defined in [RFC3987]. This document changes that advice to encourage explicit definition of the scheme and allowable syntax elements within the larger character repertoire of IRIs, as defined by [RFC3987bis]. + A scheme definition cannot override the orverall syntax for IRIs. + For example, this means that fragment identifiers (#) cannot be re- + used outside the generic syntax restrictions, and in particular + scheme-specific syntax cannot override the fragment identifier syntax + because it is generic. + 2. Conformance Guidelines Within this document, the key words MUST, MAY, SHOULD, REQUIRED, RECOMMENDED, and so forth are used within the general meanings established in [RFC2119], within the context that they are requirements on future registration specifications. 3. Guidelines for Permanent URI/IRI Scheme Definitions This section gives considerations for new URI/IRI schemes. Meeting @@ -300,20 +289,29 @@ compatibility issues with IRIs of the scheme. Specifications for IRIs schemes MUST be described in terms of processing an IRI as a sequence of Unicode codepoints, without reference to the encoding of those code points as a sequence of bytes, using UTF-8 or UTF-16. The scheme specification SHOULD be as restrictive as possible regarding what characters are allowed in the URI/IRI, because some characters can create several different security considerations (see for example [RFC4690]). + If an IRI scheme has specific length limitations, they MUST be + specified in terms of Unicode codepoints and not in terms of octets + (in any particular encoding). + + All percent-encoded variants are automatically included by definition + for any character given in an IRI production. This means that if you + want to restrict the URI percent-encoded forms in some way, you must + restrict the Unicode forms that would lead to them. + 3.7. Clear Security Considerations Definitions of schemes MUST be accompanied by a clear analysis of the security implications for systems that use the scheme; this follows the practice of Security Consideration sections within IANA registrations [RFC5226]. In particular, Section 7 of RFC 3986 [RFC3986] describes general security considerations for URIs, while Section ??? of [RFC3987bis] gives those for IRIs. The definition of an individual URI/IRI scheme @@ -352,25 +350,27 @@ Provisional registration can be an intermediate step on the way to permanent registration, e.g., before the scheme specification is finalized. Provisional registration is also appropriate for schemes that are known to be used, but where a definitive specification is not available. There is no time limit for provisional registration. While the guidelines in Section 3 are REQUIRED for permanent registration, they are RECOMMENDED for provisional registration. For a provisional registration, the following are REQUIRED: - o The scheme name meets the syntactic requirements of Section 3.8. + o The scheme name meets the syntactic requirements of Section 3.8 + and the encoding requirements of Section 3.6. o There is not already an entry with the same scheme name. (In the unfortunate case that there are multiple, different uses of the same scheme name, the IESG may approve a request to modify an existing entry to note the separate use.) + o Contact information identifying the person supplying the registration is included. Previously unregistered schemes discovered in use may be registered by third parties (even if not on behalf of those who created the scheme). In this case, both the registering party and the scheme creator SHOULD be identified. o If no permanent, citable specification for the scheme definition is included, credible reasons for not providing it should be given. o A valid Security Considerations section, as required by Section 6 of [RFC5226]. @@ -417,22 +417,21 @@ In exceptional cases, where the negotiating parties cannot form a consensus, the final arbiter of any contested registration shall be the IESG. If parties achieve consensus on a registration proposal that does not fully conform to the strict wording of this procedure, this should be drawn to the attention of a relevant member of the IESG. 6.2. Registration Procedures - Someone wishing to register a new URI/IRI scheme SHOULD: - + Someone wishing to register a new URI/IRI scheme MUST: 1. Check the IANA URI scheme registry to see whether or not there is already an entry for the desired name. If there is already an entry under the name, choose a different URI scheme name, or update the existing scheme definition. 2. Prepare a URI/IRI scheme registration template, as specified in Section 6.4. The scheme registration template may be contained in an Internet Draft, submitted alone, or as part of some other permanently available, stable, protocol specification. The template may also be submitted in some other form (as part of another document or as a stand-alone document), but the contents @@ -498,92 +497,100 @@ Transition from 'permanent' to 'historical' status requires IESG approval. Transition from 'provisional' to 'historical' may be requested by anyone authorized to update the provisional registration. 6.4. URI/IRI Scheme Registration Template This template describes the fields that must be supplied in a URI/IRI scheme registration request: - Resource Identifier (RI) Scheme name. + Resource Identifier (RI) Scheme name: See Section 3.8 for guidelines. - Status. + Status: This reflects the status requested, and should be one of 'permanent', 'provisional', or 'historical'. - Scheme syntax. + Scheme syntax: See Section 3.2 for guidelines. - Scheme semantics. + Scheme semantics: See Section 3.3 and Section 3.4 for guidelines. - Encoding considerations. + Encoding considerations: See Section 3.3 and Section 3.6 for guidelines. - Applications/protocols that use this scheme name. + Applications/protocols that use this scheme name: See Section 3.5. - Interoperability considerations. + Interoperability considerations: If the person or group registering the scheme is aware of any details regarding the scheme that might impact interoperability, identify them here. For example: proprietary or uncommon encoding methods; inability to support multibyte character sets; incompatibility with types or versions of any underlying protocol. - Security considerations. + Security considerations: See Section 3.7 for guidelines. - Contact. + Contact: Person (including contact information) to contact for further information. - Author/Change controller. + Author/Change controller: Person (including contact information) authorized to change this, if a provisional registration. - References. + References: Include full citations for all referenced documents. Registration templates for provisional registration may be included in an Internet Draft; when the documents expire or are approved for publication as an RFC, the registration will be updated. 7. The "example" Scheme 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 + 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" + 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. + 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. 8. IANA Considerations Previously, the former "URL Scheme" registry was replaced by the Uniform Resource Identifier scheme registry. The process was based on [RFC5226] "Expert Review" with an initial (optional) mailing list review. The updated template has an additional field for the status of the scheme, and the procedures for entering new name schemes have been augmented. Section 6 establishes the process for new URI/IRI scheme registration. + IANA is requested to update the name of the registry "URI Schemes" to + "URI/IRI Schemes". The registry should be updated to point to this + document. For the tables within that registry "Permanent URI + Schemes" should become "Permanent URI/IRI Schemes", "Provisional URI + Schemes" should become "Provisional URI/IRI Schemes", and "Historical + URI Schemes" should become "Historical URI/IRI Schemes". + The example URI scheme "example" is hereby registered. (See the template above for registration.) 9. Security Considerations All registered values are expected to contain accurate security consideration sections; 'permanent' registered scheme names are expected to contain complete definitions. Information concerning possible security vulnerabilities of a