draft-ietf-iri-4395bis-irireg-02.txt   draft-ietf-iri-4395bis-irireg-03.txt 
Network Working Group T. Hansen Network Working Group T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Obsoletes: 4395 (if approved) T. Hardie Obsoletes: 4395 (if approved) T. Hardie
Intended status: BCP Panasonic Wireless Research Lab Intended status: BCP Panasonic Wireless Research Lab
Expires: January 29, 2012 L. Masinter Expires: January 30, 2012 L. Masinter
Adobe Adobe
July 28, 2011 July 29, 2011
Guidelines and Registration Procedures for New URI/IRI Schemes Guidelines and Registration Procedures for New URI/IRI Schemes
draft-ietf-iri-4395bis-irireg-02 draft-ietf-iri-4395bis-irireg-03
Abstract Abstract
This document updates the guidelines and recommendations for the This document updates the guidelines and recommendations for the
definition of Uniform Resource Identifier (URI) schemes, and extends definition of Uniform Resource Identifier (URI) schemes, and extends
the registry and guidelines to apply when the schemes are used with the registry and guidelines to apply when the schemes are used with
Internationalized Resource Identifiers (IRIs). It also updates the Internationalized Resource Identifiers (IRIs). It also updates the
process and IANA registry for URI/IRI schemes. It obsoletes RFC process and IANA registry for URI/IRI schemes. It obsoletes RFC
4395. 4395.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 29, 2012. This Internet-Draft will expire on January 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conformance Guidelines . . . . . . . . . . . . . . . . . . . . 4 2. Conformance Guidelines . . . . . . . . . . . . . . . . . . . . 4
3. Guidelines for Permanent URI/IRI Scheme Definitions . . . . . 4 3. Guidelines for Permanent URI/IRI Scheme Definitions . . . . . 4
3.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4 3.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4
3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5 3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5
3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6 3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6
3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 6
3.6. Internationalization and Character Encoding . . . . . . . 7 3.6. Internationalization and Character Encoding . . . . . . . 7
3.7. Clear Security Considerations . . . . . . . . . . . . . . 7 3.7. Clear Security Considerations . . . . . . . . . . . . . . 7
3.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 8 3.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 7
4. Guidelines for Provisional URI/IRI Scheme Registration . . . . 8 4. Guidelines for Provisional URI/IRI Scheme Registration . . . . 8
5. Guidelines for Historical URI/IRI Scheme Registration . . . . 9 5. Guidelines for Historical URI/IRI Scheme Registration . . . . 9
6. URI/IRI Scheme Registration Procedure . . . . . . . . . . . . 9 6. URI/IRI Scheme Registration Procedure . . . . . . . . . . . . 9
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Registration Procedures . . . . . . . . . . . . . . . . . 10 6.2. Registration Procedures . . . . . . . . . . . . . . . . . 10
6.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 11
6.4. URI/IRI Scheme Registration Template . . . . . . . . . . . 11 6.4. URI/IRI Scheme Registration Template . . . . . . . . . . . 11
7. The "example" Scheme . . . . . . . . . . . . . . . . . . . . . 12 7. The "example" Scheme . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 4, line 18 skipping to change at page 4, line 18
There is no separate, independent registry or registration process There is no separate, independent registry or registration process
for IRIs: the URI Scheme Registry is to be used for both URIs and for IRIs: the URI Scheme Registry is to be used for both URIs and
IRIs. Previously, those who wish to describe resource identifiers IRIs. Previously, those who wish to describe resource identifiers
that are useful as IRIs were encouraged to define the corresponding that are useful as IRIs were encouraged to define the corresponding
URI syntax, and note that the IRI usage follows the rules and URI syntax, and note that the IRI usage follows the rules and
transformations defined in [RFC3987]. This document changes that transformations defined in [RFC3987]. This document changes that
advice to encourage explicit definition of the scheme and allowable advice to encourage explicit definition of the scheme and allowable
syntax elements within the larger character repertoire of IRIs, as syntax elements within the larger character repertoire of IRIs, as
defined by [RFC3987bis]. defined by [RFC3987bis].
A scheme definition cannot override the orverall syntax for IRIs. A scheme definition cannot override the overall syntax for IRIs. For
For example, this means that fragment identifiers (#) cannot be re- example, this means that fragment identifiers (#) cannot be re-used
used outside the generic syntax restrictions, and in particular outside the generic syntax restrictions, and in particular scheme-
scheme-specific syntax cannot override the fragment identifier syntax specific syntax cannot override the fragment identifier syntax
because it is generic. because it is generic.
2. Conformance Guidelines 2. Conformance Guidelines
Within this document, the key words MUST, MAY, SHOULD, REQUIRED, Within this document, the key words MUST, MAY, SHOULD, REQUIRED,
RECOMMENDED, and so forth are used within the general meanings RECOMMENDED, and so forth are used within the general meanings
established in [RFC2119], within the context that they are established in [RFC2119], within the context that they are
requirements on future registration specifications. requirements on future registration specifications.
3. Guidelines for Permanent URI/IRI Scheme Definitions 3. Guidelines for Permanent URI/IRI Scheme Definitions
skipping to change at page 7, line 29 skipping to change at page 7, line 29
compatibility issues with IRIs of the scheme. compatibility issues with IRIs of the scheme.
Specifications for IRIs schemes MUST be described in terms of Specifications for IRIs schemes MUST be described in terms of
processing an IRI as a sequence of Unicode codepoints, without processing an IRI as a sequence of Unicode codepoints, without
reference to the encoding of those code points as a sequence of 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 bytes, using UTF-8 or UTF-16. The scheme specification SHOULD be as
restrictive as possible regarding what characters are allowed in the restrictive as possible regarding what characters are allowed in the
URI/IRI, because some characters can create several different URI/IRI, because some characters can create several different
security considerations (see for example [RFC4690]). 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 All percent-encoded variants are automatically included by definition
for any character given in an IRI production. This means that if you 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 want to restrict the URI percent-encoded forms in some way, you must
restrict the Unicode forms that would lead to them. restrict the Unicode forms that would lead to them.
3.7. Clear Security Considerations 3.7. Clear Security Considerations
Definitions of schemes MUST be accompanied by a clear analysis of the Definitions of schemes MUST be accompanied by a clear analysis of the
security implications for systems that use the scheme; this follows security implications for systems that use the scheme; this follows
the practice of Security Consideration sections within IANA the practice of Security Consideration sections within IANA
 End of changes. 7 change blocks. 
13 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/