draft-ietf-iri-4395bis-irireg-00.txt   draft-ietf-iri-4395bis-irireg-01.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: April 11, 2011 L. Masinter Expires: September 30, 2011 L. Masinter
Adobe Systems Adobe
October 8, 2010 March 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-00 draft-ietf-iri-4395bis-irireg-01
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 April 11, 2011. This Internet-Draft will expire on September 30, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6 3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6
3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 14 Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Uniform Resource Identifier (URI) protocol element and generic The Uniform Resource Identifier (URI) protocol element and generic
syntax is defined by [RFC3986]. Each URI begins with a scheme name, 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 as defined by Section 3.1 of RFC 3986, that refers to a specification
for identifiers within that scheme. The URI syntax provides a for identifiers within that scheme. The URI syntax provides a
federated and extensible naming system, where each scheme's federated and extensible naming system, where each scheme's
specification may further restrict the syntax and semantics of specification may further restrict the syntax and semantics of
skipping to change at page 5, line 24 skipping to change at page 5, line 24
global namespace; it is desirable to avoid contention over use of global namespace; it is desirable to avoid contention over use of
short, mnemonic scheme names. For these reasons, the unbounded short, mnemonic scheme names. For these reasons, the unbounded
registration of new schemes is harmful. New URI/IRI schemes SHOULD registration of new schemes is harmful. New URI/IRI schemes SHOULD
have clear utility to the broad Internet community, beyond that have clear utility to the broad Internet community, beyond that
available with already registered URI/IRI schemes. available with already registered URI/IRI schemes.
3.2. Syntactic Compatibility 3.2. Syntactic Compatibility
[RFC3986] defines the generic syntax for all URI schemes, along with [RFC3986] defines the generic syntax for all URI schemes, along with
the syntax of common URI components that are used by many URI schemes the syntax of common URI components that are used by many URI schemes
to define hierarchical identifiers. [RFC3987] and [RFC3987bis] to define hierarchical identifiers. [RFC3987] and subsequently
extended this generic syntax to cover IRIs. All URI/IRI scheme [RFC3987bis] extended this generic syntax to cover IRIs. All URI/IRI
specifications MUST define their own syntax such that all strings scheme specifications MUST define their own syntax such that all
matching their scheme-specific syntax will also match the strings matching their scheme-specific syntax will also match the
<absolute-URI> grammar described in [RFC3987bis]. <absolute-URI> grammar described in [RFC3987bis].
New schemes SHOULD reuse the common components of [RFC3987bis] for New schemes SHOULD reuse the common components of [RFC3987bis] for
the definition of hierarchical naming schemes. However, if there is the definition of hierarchical naming schemes. However, if there is
a strong reason for a scheme not to use the hierarchical syntax, then a strong reason for a scheme not to use the hierarchical syntax, then
the new scheme definition SHOULD follow the syntax of previously the new scheme definition SHOULD follow the syntax of previously
registered schemes. registered schemes.
Schemes that are not intended for use with relative URIs/IRIs SHOULD Schemes that are not intended for use with relative URIs/IRIs SHOULD
avoid use of the forward slash "/" character, which is used for avoid use of the forward slash "/" character, which is used for
skipping to change at page 7, line 48 skipping to change at page 7, line 48
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]).
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
registrations [RFC2434]. registrations [RFC5226].
In particular, Section 7 of RFC 3986 [RFC3986] describes general In particular, Section 7 of RFC 3986 [RFC3986] describes general
security considerations for URIs, while Section ??? of [RFC3987bis] security considerations for URIs, while Section ??? of [RFC3987bis]
gives those for IRIs. The definition of an individual URI/IRI scheme gives those for IRIs. The definition of an individual URI/IRI scheme
should note which of these apply to the specified scheme. should note which of these apply to the specified scheme.
3.8. Scheme Name Considerations 3.8. Scheme Name Considerations
Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this
sytax remains the same for IRIs. New registered schemes sytax remains the same for IRIs. New registered schemes
skipping to change at page 8, line 37 skipping to change at page 8, line 37
that allude to their "universal" or "standard" nature.) that allude to their "universal" or "standard" nature.)
Organizations that desire a private name space for URI scheme names Organizations that desire a private name space for URI scheme names
are encouraged to use a prefix based on their domain name, expressed are encouraged to use a prefix based on their domain name, expressed
in reverse order. For example, a URI scheme name of com-example-info in reverse order. For example, a URI scheme name of com-example-info
might be registered by the vendor that owns the example.com domain might be registered by the vendor that owns the example.com domain
name. name.
4. Guidelines for Provisional URI/IRI Scheme Registration 4. Guidelines for Provisional URI/IRI Scheme Registration
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 While the guidelines in Section 3 are REQUIRED for permanent
registration, they are RECOMMENDED for provisional registration. For registration, they are RECOMMENDED for provisional registration. For
a provisional registration, the following are REQUIRED: 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.
o There is not already an entry with the same scheme name. (In the o There is not already an entry with the same scheme name. (In the
unfortunate case that there are multiple, different uses of the unfortunate case that there are multiple, different uses of the
same scheme name, the IESG may approve a request to modify an same scheme name, the IESG may approve a request to modify an
existing entry to note the separate use.) existing entry to note the separate use.)
o Contact information identifying the person supplying the o Contact information identifying the person supplying the
skipping to change at page 9, line 4 skipping to change at page 9, line 10
o The scheme name meets the syntactic requirements of Section 3.8. o The scheme name meets the syntactic requirements of Section 3.8.
o There is not already an entry with the same scheme name. (In the o There is not already an entry with the same scheme name. (In the
unfortunate case that there are multiple, different uses of the unfortunate case that there are multiple, different uses of the
same scheme name, the IESG may approve a request to modify an same scheme name, the IESG may approve a request to modify an
existing entry to note the separate use.) existing entry to note the separate use.)
o Contact information identifying the person supplying the o Contact information identifying the person supplying the
registration is included. Previously unregistered schemes registration is included. Previously unregistered schemes
discovered in use may be registered by third parties (even if not discovered in use may be registered by third parties (even if not
on behalf of those who created the scheme). In this case, both on behalf of those who created the scheme). In this case, both
the registering party and the scheme creator SHOULD be identified. the registering party and the scheme creator SHOULD be identified.
o If no permanent, citable specification for the scheme definition o If no permanent, citable specification for the scheme definition
is included, credible reasons for not providing it should be is included, credible reasons for not providing it should be
given. given.
o A valid Security Considerations section, as required by Section 6 o A valid Security Considerations section, as required by Section 6
of [RFC2434]. of [RFC5226].
o If the scheme definition does not meet the guidelines laid out in o If the scheme definition does not meet the guidelines laid out in
Section 3, the differences and reasons SHOULD be noted. Section 3, the differences and reasons SHOULD be noted.
5. Guidelines for Historical URI/IRI Scheme Registration 5. Guidelines for Historical URI/IRI Scheme Registration
In some circumstances, it is appropriate to note a URI scheme that 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 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 common use or the use is not recommended. In this case, it is
possible for an individual to request that the scheme be registered possible for an individual to request that the scheme be registered
(newly, or as an update to an existing registration) as 'historical'. (newly, or as an update to an existing registration) as 'historical'.
Any scheme that is no longer in common use MAY be designated as Any scheme that is no longer in common use MAY be designated as
historical; the registration should contain some indication to where historical; the registration should contain some indication to where
the scheme was previously defined or documented. the scheme was previously defined or documented.
6. URI/IRI Scheme Registration Procedure 6. URI/IRI Scheme Registration Procedure
6.1. General 6.1. General
The URI/IRI registration process is described in the terminology of The URI/IRI registration process is described in the terminology of
[RFC2434]. The registration process is an optional mailing list [RFC5226]. The registration process is an optional mailing list
review, followed by "Expert Review". The registration request should review, followed by "Expert Review". The registration request should
note the desired status. The Designated Expert will evaluate the note the desired status. The Designated Expert will evaluate the
request against the criteria of the requested status. In the case of request against the criteria of the requested status. In the case of
a permanent registration request, the Designated Expert may: a permanent registration request, the Designated Expert may:
o Accept the specification of the scheme for permanent registration. o Accept the specification of the scheme for permanent registration.
o Suggest provisional registration instead. o Suggest provisional registration instead.
o Request IETF review and IESG approval; in the meanwhile, suggest o Request IETF review and IESG approval; in the meanwhile, suggest
provisional registration. provisional registration.
URI/IRI scheme definitions contained within other IETF documents URI/IRI scheme definitions contained within other IETF documents
(Informational, Experimental, or Standards-Track RFCs) must also (Informational, Experimental, or Standards-Track RFCs) must also
undergo Expert Review; in the case of Standards-Track documents, undergo Expert Review; in the case of Standards-Track documents,
permanent registration status approval is required. permanent registration status approval is required.
The registration procedure for URI schemes is intended to be very
lightweight for non-contentious registrations. For the most part, we
expect the good sense of submitters and reviewers, guided by these
procedures, to achieve an acceptable and useful consensus for the
community.
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 6.2. Registration Procedures
Someone wishing to register a new URI/IRI scheme SHOULD: Someone wishing to register a new URI/IRI scheme SHOULD:
1. Check the IANA URI scheme registry to see whether or not there is 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 already an entry for the desired name. If there is already an
entry under the name, choose a different URI scheme name, or entry under the name, choose a different URI scheme name, or
update the existing scheme definition. update the existing scheme definition.
2. Prepare a URI/IRI scheme registration template, as specified in 2. Prepare a URI/IRI scheme registration template, as specified in
Section 6.4. The scheme registration template may be contained Section 6.4. The scheme registration template may be contained
skipping to change at page 12, line 49 skipping to change at page 13, line 24
Security considerations None. Security considerations None.
Contact N/A Contact N/A
Author/Change controller IETF Author/Change controller IETF
References This RFC XXXX. References This RFC XXXX.
RFC Editor Note: Replace XXXX with this RFC's reference. RFC Editor Note: Replace XXXX with this RFC's reference.
8. IANA Considerations 8. IANA Considerations
Previously, the former "URL Scheme" registry was replaced by the Previously, the former "URL Scheme" registry was replaced by the
Uniform Resource Identifier scheme registry. The process was based Uniform Resource Identifier scheme registry. The process was based
on [RFC2434] "Expert Review" with an initial (optional) mailing list on [RFC5226] "Expert Review" with an initial (optional) mailing list
review. review.
The updated template has an additional field for the status of the The updated template has an additional field for the status of the
scheme, and the procedures for entering new name schemes have been scheme, and the procedures for entering new name schemes have been
augmented. Section 6 establishes the process for new URI/IRI scheme augmented. Section 6 establishes the process for new URI/IRI scheme
registration. registration.
The example URI scheme "example" is hereby registered. (See the The example URI scheme "example" is hereby registered. (See the
template above for registration.) template above for registration.)
skipping to change at page 14, line 23 skipping to change at page 14, line 35
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
October 1998. May 2008.
[RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978,
March 2005. March 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987bis] [RFC3987bis]
Duerst, M., Masinter, L., and M. Suignard, Duerst, M., Masinter, L., and M. Suignard,
"Internationalized Resource Identifiers (IRIs)", "Internationalized Resource Identifiers (IRIs)",
September 2010, September 2010,
<http://tools.ietf.org/id/draft-ietf-iri-3987bis>. <http://tools.ietf.org/id/draft-ietf-iri-3987bis>.
11.2. Informative References 11.2. Informative References
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL [RFC2717] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999. Scheme Names", BCP 35, RFC 2717, November 1999.
skipping to change at page 15, line 11 skipping to change at page 15, line 21
"Guidelines for new URL Schemes", RFC 2718, November 1999. "Guidelines for new URL Schemes", RFC 2718, November 1999.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition "Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002. Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006. RFC 4395, February 2006.
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
Recommendations for Internationalized Domain Names Recommendations for Internationalized Domain Names
(IDNs)", RFC 4690, September 2006. (IDNs)", RFC 4690, September 2006.
[W3CWebArch] [W3CWebArch]
W3C Technical Architecture Group, "Architecture of the W3C Technical Architecture Group, "Architecture of the
skipping to change at page 15, line 33 skipping to change at page 16, line 4
Authors' Addresses Authors' Addresses
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. 200 Laurel Ave.
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+urireg@maillennium.att.com Email: tony+urireg@maillennium.att.com
Ted Hardie Ted Hardie
Panasonic Wireless Research Lab Panasonic Wireless Research Lab
10900 Tantau Ave. 10900 Tantau Ave.
Cupertino, CA Cupertino, CA
USA USA
Phone: +1 408 628 5864 Phone: +1 408 628 5864
Email: ted.ietf@gmail.com Email: ted.ietf@gmail.com
Larry Masinter Larry Masinter
Adobe Systems Adobe
345 Park Ave. 345 Park Ave.
San Jose, CA 95110 San Jose, CA 95110
US US
Phone: +1 408 536 3024 Phone: +1 408 536 3024
Email: masinter@adobe.com Email: masinter@adobe.com
URI: http://larry.masinter.net URI: http://larry.masinter.net
 End of changes. 22 change blocks. 
27 lines changed or deleted 46 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/