--- 1/draft-ietf-iri-4395bis-irireg-03.txt 2011-12-14 04:14:43.206671246 +0100 +++ 2/draft-ietf-iri-4395bis-irireg-04.txt 2011-12-14 04:14:43.234671348 +0100 @@ -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: January 30, 2012 L. Masinter +Expires: June 16, 2012 L. Masinter Adobe - July 29, 2011 + December 14, 2011 Guidelines and Registration Procedures for New URI/IRI Schemes - draft-ietf-iri-4395bis-irireg-03 + draft-ietf-iri-4395bis-irireg-04 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 January 30, 2012. + This Internet-Draft will expire on June 16, 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 @@ -53,24 +53,24 @@ 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 . . . . . . . . . 4 3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5 3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6 - 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Internationalization and Character Encoding . . . . . . . 7 3.7. Clear Security Considerations . . . . . . . . . . . . . . 7 - 3.8. Scheme Name 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 7. The "example" Scheme . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 @@ -157,31 +157,32 @@ 3. Guidelines for Permanent URI/IRI Scheme Definitions This section gives considerations for new URI/IRI schemes. Meeting these guidelines is REQUIRED for permanent scheme registration. Meeting these guidelines is also RECOMMENDED for provisional registration, as described in Section 4. 3.1. Demonstratable, New, Long-Lived Utility The use and deployment of new URI/IRI schemes in the Internet - infrastructure is costly; some parts of URI/IRI processing may be + infrastructure may be costly; some parts of URI/IRI processing may be scheme-dependent, and deployed software already processes URIs and IRIs of well-known schemes. Introducing a new scheme may require additional software, not only for client software and user agents but also in additional parts of the network infrastructure (gateways, proxies, caches) [W3CWebArch]. URI/IRI schemes constitute a single, global namespace; it is desirable to avoid contention over use of short, mnemonic scheme names. For these reasons, the unbounded - registration of new schemes is harmful. New URI/IRI schemes SHOULD - have clear utility to the broad Internet community, beyond that - available with already registered URI/IRI schemes. + registration of new schemes is harmful. New schemes should have + utility to the Internet community beyond that available with already + registered schemes. The registration document SHOULD discuss the + utility of the scheme being registered. 3.2. Syntactic Compatibility [RFC3986] defines the generic syntax for all URI schemes, along with the syntax of common URI components that are used by many URI schemes to define hierarchical identifiers. [RFC3987] and subsequently [RFC3987bis] extended this generic syntax to cover IRIs. All URI/IRI scheme specifications MUST define their own syntax such that all strings matching their scheme-specific syntax will also match the grammar described in [RFC3987bis]. @@ -302,23 +303,23 @@ 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 - should note which of these apply to the specified scheme. + security considerations for URIs, while [RFC3987bis] gives those for + IRIs. The definition of an individual URI/IRI scheme should note + which of these apply to the specified scheme. 3.8. Scheme Name Considerations Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this sytax remains the same for IRIs. New registered schemes registrations MUST follow this syntax, which only allows a limited repertoire of characters (taken from US-ASCII). Although the syntax for the scheme name in URI/IRIs is case insensitive, the scheme names itself MUST be registered using lowercase letters. @@ -352,31 +353,33 @@ 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 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]. + o The scheme definition SHOULD include a clear Security + Considerations (Section 3.7) or explain why a full security + analysis is not available (e.g., in a third-party scheme + registration). o If the scheme definition does not meet the guidelines laid out in Section 3, the differences and reasons SHOULD be noted. 5. Guidelines for Historical URI/IRI Scheme Registration In some circumstances, it is appropriate to note a URI scheme that was once in use or registered but for whatever reason is no longer in common use or the use is not recommended. In this case, it is possible for an individual to request that the scheme be registered (newly, or as an update to an existing registration) as 'historical'. @@ -520,22 +521,21 @@ 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: See Section 3.7 for guidelines. Contact: Person (including contact information) to contact for further information. Author/Change controller: - Person (including contact information) authorized to change this, - if a provisional registration. + Person (including contact information) authorized to change this. 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