draft-ietf-iri-4395bis-irireg-01.txt		draft-ietf-iri-4395bis-irireg-02.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: September 30, 2011 L. Masinter		Expires: January 29, 2012 L. Masinter
	Adobe		Adobe
	March 29, 2011		July 28, 2011
	Guidelines and Registration Procedures for New URI/IRI Schemes		Guidelines and Registration Procedures for New URI/IRI Schemes
	draft-ietf-iri-4395bis-irireg-01		draft-ietf-iri-4395bis-irireg-02
	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 September 30, 2011.		This Internet-Draft will expire on January 29, 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 14		skipping to change at page 2, line 14
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	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 . . . . . . . . . 5		3.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4
	3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5		3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5
	3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5
	3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6		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.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 . . . . . . . . . . . . . . . . . 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
	skipping to change at page 3, line 12		skipping to change at page 3, line 12
	11.2. Informative References . . . . . . . . . . . . . . . . . . 15		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 define the
	identifiers using that scheme. As originally defined, URIs only		semantics of identifiers using that scheme. As originally defined,
	allowed a limited repertoire of characters chosen from US-ASCII. An		URIs only allowed a limited repertoire of characters chosen from US-
	Interationalized Resource Identifier (IRI) as defined by		ASCII.
			An Interationalized Resource Identifier (IRI), as defined by
	[RFC3987bis], extends the URI syntax to allow characters from a much		[RFC3987bis], extends the URI syntax to allow characters from a much
	greater repertoire, to accomodate resource identifiers from the		greater repertoire, to accomodate resource identifiers from the
	world's languages. The same schemes used in URIs are used in IRIs.		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		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		This document extends the URI scheme registry to be a registry of
	URI/IRI schemes (i.e., applicable to both URIs and IRIs). This		URI/IRI schemes (i.e., applicable to both URIs and IRIs). This
	document also provides updated guidelines for the definition of new		document also provides updated guidelines for the definition of new
	schemes, for consideration by those who are defining, registering, or		schemes, for consideration by those who are defining, registering, or
	evaluating those definitions, as well as a process and mechanism for		evaluating those definitions, as well as a process and mechanism for
	registering URI/IRI schemes within the IANA URI scheme registry. The		registering URI/IRI schemes within the IANA URI scheme registry.
	registry has two parts: 'provisional' and 'permanent', with different		There is a single namespace for registered schemes. Within that
	requirements. Guidelines and requirements for both parts are given.		namespace, there are values that are approved as meeting a set of
			criteria for permanent URI/IRI schemes. Other scheme names may also
	This document obsoletes [RFC4395], which in turn obsoleted [RFC2717]		be registered provisionally or historically, without necessarily
	and [RFC2718]. RFCs 2717 and 2718 drew a distinction between		meeting those criteria. The intent of the registry is to:
	'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:
	o provide a central point of discovery for established URI/IRI		o provide a central point of discovery for established URI/IRI
	scheme names, and easy location of their defining documents;		scheme names, and easy location of their defining documents;
	o discourage use of the same scheme name for different purposes;		o discourage use of the same scheme name for different purposes;
	o help those proposing new scheme names to discern established		o help those proposing new scheme names to discern established
	trends and conventions, and avoid names that might be confused		trends and conventions, and avoid names that might be confused
	with existing ones;		with existing ones;
	o encourage registration by setting a low barrier for provisional		o encourage registration by setting a low barrier for provisional
	registrations.		registrations.
	[RFC3987] introduced a new protocol element, the Internationalized		There is no separate, independent registry or registration process
	Resource Identifier (IRI), by defining a mapping between URIs and		for IRIs: the URI Scheme Registry is to be used for both URIs and
	IRIs. [RFC3987bis] updates this definition, allowing an IRI to be		IRIs. Previously, those who wish to describe resource identifiers
	interpreted directly without translating into a URI. There is no		that are useful as IRIs were encouraged to define the corresponding
	separate, independent registry or registration process for IRIs: the		URI syntax, and note that the IRI usage follows the rules and
	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		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.
			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		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
	This section gives considerations for new URI/IRI schemes. Meeting		This section gives considerations for new URI/IRI schemes. Meeting
	skipping to change at page 7, line 43		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
			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		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 [RFC5226].		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
	skipping to change at page 8, line 47		skipping to change at page 8, line 45
	Provisional registration can be an intermediate step on the way to		Provisional registration can be an intermediate step on the way to
	permanent registration, e.g., before the scheme specification is		permanent registration, e.g., before the scheme specification is
	finalized. Provisional registration is also appropriate for schemes		finalized. Provisional registration is also appropriate for schemes
	that are known to be used, but where a definitive specification is		that are known to be used, but where a definitive specification is
	not available. There is no time limit for provisional registration.		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
			and the encoding requirements of Section 3.6.
	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 [RFC5226].		of [RFC5226].
	skipping to change at page 10, line 19		skipping to change at page 10, line 18
	In exceptional cases, where the negotiating parties cannot form a		In exceptional cases, where the negotiating parties cannot form a
	consensus, the final arbiter of any contested registration shall be		consensus, the final arbiter of any contested registration shall be
	the IESG.		the IESG.
	If parties achieve consensus on a registration proposal that does not		If parties achieve consensus on a registration proposal that does not
	fully conform to the strict wording of this procedure, this should be		fully conform to the strict wording of this procedure, this should be
	drawn to the attention of a relevant member of the IESG.		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 MUST:
	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
	in an Internet Draft, submitted alone, or as part of some other		in an Internet Draft, submitted alone, or as part of some other
	permanently available, stable, protocol specification. The		permanently available, stable, protocol specification. The
	template may also be submitted in some other form (as part of		template may also be submitted in some other form (as part of
	another document or as a stand-alone document), but the contents		another document or as a stand-alone document), but the contents
	skipping to change at page 12, line 5		skipping to change at page 12, line 5
	Transition from 'permanent' to 'historical' status requires IESG		Transition from 'permanent' to 'historical' status requires IESG
	approval. Transition from 'provisional' to 'historical' may be		approval. Transition from 'provisional' to 'historical' may be
	requested by anyone authorized to update the provisional		requested by anyone authorized to update the provisional
	registration.		registration.
	6.4. URI/IRI Scheme Registration Template		6.4. URI/IRI Scheme Registration Template
	This template describes the fields that must be supplied in a URI/IRI		This template describes the fields that must be supplied in a URI/IRI
	scheme registration request:		scheme registration request:
	Resource Identifier (RI) Scheme name.		Resource Identifier (RI) Scheme name:
	See Section 3.8 for guidelines.		See Section 3.8 for guidelines.
	Status.		Status:
	This reflects the status requested, and should be one of		This reflects the status requested, and should be one of
	'permanent', 'provisional', or 'historical'.		'permanent', 'provisional', or 'historical'.
	Scheme syntax.		Scheme syntax:
	See Section 3.2 for guidelines.		See Section 3.2 for guidelines.
	Scheme semantics.		Scheme semantics:
	See Section 3.3 and Section 3.4 for guidelines.		See Section 3.3 and Section 3.4 for guidelines.
	Encoding considerations.		Encoding considerations:
	See Section 3.3 and Section 3.6 for guidelines.		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.		See Section 3.5.
	Interoperability considerations.		Interoperability considerations:
	If the person or group registering the scheme is aware of any		If the person or group registering the scheme is aware of any
	details regarding the scheme that might impact interoperability,		details regarding the scheme that might impact interoperability,
	identify them here. For example: proprietary or uncommon encoding		identify them here. For example: proprietary or uncommon encoding
	methods; inability to support multibyte character sets;		methods; inability to support multibyte character sets;
	incompatibility with types or versions of any underlying protocol.		incompatibility with types or versions of any underlying protocol.
	Security considerations.		Security considerations:
	See Section 3.7 for guidelines.		See Section 3.7 for guidelines.
	Contact.		Contact:
	Person (including contact information) to contact for further		Person (including contact information) to contact for further
	information.		information.
	Author/Change controller.		Author/Change controller:
	Person (including contact information) authorized to change this,		Person (including contact information) authorized to change this,
	if a provisional registration.		if a provisional registration.
	References.		References:
	Include full citations for all referenced documents. Registration		Include full citations for all referenced documents. Registration
	templates for provisional registration may be included in an		templates for provisional registration may be included in an
	Internet Draft; when the documents expire or are approved for		Internet Draft; when the documents expire or are approved for
	publication as an RFC, the registration will be updated.		publication as an RFC, the registration will be updated.
	7. The "example" Scheme		7. The "example" Scheme
	There is a need for a URI/IRI Scheme name that can be used for		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		examples in documentation without fear of conflicts with current or
	future actual schemes. The URI/IRI Scheme "example" is hereby		future actual schemes. The URI/IRI Scheme "example" is hereby
	registered as a Permanent URI/IRI Scheme for that purpose.		registered as a Permanent URI/IRI Scheme for that purpose.
	Scheme name example		Scheme name: example
	Status permanent		Status: permanent
	Scheme syntax The entire range of allowable syntax for URI/IRI		Scheme syntax: The entire range of allowable syntax for URI/IRI
	schemes specified in [RFC3987bis] is allowed for "example" URI/		schemes specified in [RFC3987bis] is allowed for "example" URI/
	IRIs.		IRIs.
	Scheme semantics URI/IRIs in the "example" scheme should be used for		Scheme semantics: URI/IRIs in the "example" scheme should be used
	documentation purposes only. The use of "example" URIs/IRIs must		for documentation purposes only. The use of "example" URIs/IRIs
	not be used as locators, identify any resources, or specify any		must not be used as locators, identify any resources, or specify
	particular set of operations.		any particular set of operations.
	Encoding considerations See Section 2.5 of [RFC3986] for guidelines.		Encoding considerations: See Section 2.5 of [RFC3986] for
	Applications/protocols that use this URI scheme name The "example"		guidelines.
			Applications/protocols that use this URI scheme name: The "example"
	URI should be used for documentation purposes only. It MUST not		URI should be used for documentation purposes only. It MUST not
	be used for any protocol.		be used for any protocol.
	Interoperability considerations None.		Interoperability considerations: None.
	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 [RFC5226] "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.
			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		The example URI scheme "example" is hereby registered. (See the
	template above for registration.)		template above for registration.)
	9. Security Considerations		9. Security Considerations
	All registered values are expected to contain accurate security		All registered values are expected to contain accurate security
	consideration sections; 'permanent' registered scheme names are		consideration sections; 'permanent' registered scheme names are
	expected to contain complete definitions.		expected to contain complete definitions.
	Information concerning possible security vulnerabilities of a		Information concerning possible security vulnerabilities of a
End of changes. 32 change blocks.
	80 lines changed or deleted		87 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/