draft-ietf-appsawg-about-uri-scheme-00.txt		draft-ietf-appsawg-about-uri-scheme-01.txt
	Applications Area WG (APPSAWG) L. Hunt, Ed.		Applications Area WG (APPSAWG) L. Hunt, Ed.
	Internet-Draft Opera Software, ASA.		Internet-Draft Opera Software, ASA.
	Intended Status: Standards Track M. Yevstifeyev, Ed.		Intended Status: Standards Track M. Yevstifeyev, Ed.
	Expires: April 19, 2012 October 17, 2011		Expires: June 11, 2012 December 9, 2011
	The 'about' URI Scheme		The "about" URI Scheme
	draft-ietf-appsawg-about-uri-scheme-00		draft-ietf-appsawg-about-uri-scheme-01
	Abstract		Abstract
	This document defines the 'about' URI scheme, that is widely used by		This document specifies the "about" URI scheme, that is widely used
	Web browsers and some other applications to designate access to their		by Web browsers and some other applications to designate access to
	internal resources, such as settings, application information, hidden		their internal resources, such as settings, application information,
	built-in functionality, and so on.		hidden built-in functionality, and so on.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. URI Scheme Specification . . . . . . . . . . . . . . . . . . . 3		2. URI Scheme Specification . . . . . . . . . . . . . . . . . . . 3
	2.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 3		2.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 3
	2.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 3		2.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 3
	2.2.1. Special-Purpose 'about' URIs . . . . . . . . . . . . . 3		2.2.1. Special-Purpose "about" URIs . . . . . . . . . . . . . 4
	2.2.2. Unrecognized 'about' URIs . . . . . . . . . . . . . . . 4
	2.3. Encoding Considerations . . . . . . . . . . . . . . . . . . 4		2.3. Encoding Considerations . . . . . . . . . . . . . . . . . . 4
	3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. URI Scheme Registration . . . . . . . . . . . . . . . . . . 5		4.1. URI Scheme Registration . . . . . . . . . . . . . . . . . . 4
	4.2. A Registry for SPTs . . . . . . . . . . . . . . . . . . . . 5		4.2. A Registry for Registered Tokens . . . . . . . . . . . . . 5
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 6		5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	5.2. Informative References . . . . . . . . . . . . . . . . . . 7		5.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	This document specifies the 'about' Uniform Resource Identifier (URI)		This document specifies the "about" Uniform Resource Identifier (URI)
	scheme, that is currently widely used by Web browsers and some other		scheme, that is currently widely used by Web browsers and some other
	applications to designate access to their internal resources, such as		applications to designate access to their internal resources, such as
	settings, application information, so called "Easter eggs" (i.e.		settings, application information, so called "Easter eggs" (i.e.
	hidden feature or joke in an application), and so on.		hidden feature or joke in an application), and so on.
	The concept of 'about' URIs has been formed at the times when the		The concept of "about" URIs has been formed at the times when the
	applications did not have the "friendly" user interface, in order to		applications did not have the "friendly" user interface, in order to
	provide an access to the aforementioned resources via typing the URIs		provide an access to the aforementioned resources via typing the URIs
	in the address bar. Even though the user interface of current		in the address bar. Even though the user interface of current
	Internet-targeted software effectively rescinds the issue, and		Internet-targeted software effectively rescinds the issue, and
	'about' URIs can be thought to be a rudimentary phenomenon, they are		"about" URIs can be thought to be a rudimentary phenomenon, they are
	still supported by a variety of Web browsers and are not going to		still supported by a variety of Web browsers and are not going to
	cease to exist.		cease to exist.
	As use of 'about' URIs has been quiet long-lasting, and the URIs have		As use of "about" URIs has been quiet long-lasting, and the URIs have
	been used without any proper registration and absent any proper		been used without any proper registration and absent any proper
	specification, the necessity for the the latter two actions arises.		specification, the necessity for the the latter two actions arises.
	The purpose of this document is to provide a stable specification for		The purpose of this document is to provide a stable specification for
	'about' URI scheme and correspondingly register it in the IANA		"about" URI scheme and correspondingly register it in the IANA
	registry. Along, several provisions for handling the 'about' URIs		registry. Along, several provisions for handling the "about" URIs
	are set.		are set.
	Please consult RFC 3986 [RFC3986] for definition of generic URIs		Please consult RFC 3986 [RFC3986] for definition of generic URIs
	syntax and RFC 4395 [RFC4395] for description of registration process		syntax and RFC 4395 [RFC4395] for description of registration process
	for new URI schemes.		for new URI schemes.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. URI Scheme Specification		2. URI Scheme Specification
	2.1. URI Scheme Syntax		2.1. URI Scheme Syntax
	The 'about' URI MUST syntactically conform to the <about-uri> rule		The "about" URI MUST syntactically conform to the <about-uri> rule
	below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]:		below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]:
	about-uri = "about:" about-token [ about-query ]		about-uri = "about:" about-token [ about-query ]
	about-token = segment		about-token = *( unreserved / pct-encoded )
			; for the WG discussion: the possible variants are:
			; = *pchar or = segment
			; = 1*pchar or = segment-nz
			; = segment-nz-nc
			; this is to be decided by WG.
	about-query = "?" query		about-query = "?" query
	segment = <as specified in RFC 3986, Appendix A>		pchar = <as specified in RFC 3986, Appendix A>
	query = <as specified in RFC 3986, Appendix A>		query = <as specified in RFC 3986, Appendix A>
	In terms of RFC 3986, <about-token> part corresponds to <hier-part>,		In terms of RFC 3986, <about-token> part corresponds to <hier-part>,
	and <about-query> to the query component of URI.		and <about-query> to the query component of URI.
	2.2. URI Scheme Semantics		2.2. URI Scheme Semantics
	Generally speaking, the resource a particular 'about' URI resolves to		Generally speaking, the resource a particular "about" URI resolves to
	is denoted by <about-token> part of the URI, and <about-query>		is denoted by <about-token> part of the URI, and <about-query>
	specifies additional information concerning its handling and/or the		specifies additional information concerning its handling and/or the
	information that should be returned in the resource a URI is resolved		information that should be returned in the resource a URI is resolved
	to.		to.
	However, it is impossible to specify binding between all the possible		However, it is impossible to specify binding between all the possible
	tokens and the semantics of 'about' URIs that would contain such		tokens and the semantics of "about" URIs that would contain such
	tokens. Therefore any application MAY resolve an 'about' URI to any		tokens, which this document does not attempt to do. Therefore, any
	desired resource, and MAY redirect such URIs. Several exceptions are		application resolving an "about" URI MAY choose the resource it is
	defined, though; they are named "special-purpose 'about' URIs" and		resolved to at its own discretion, with the exception of those
	MUST be handled in strict accordance with provisions set in Section		defined below as 'special-purpose "about" URIs'. They MAY use
	2.2.1.		internal redirection to accomplish this (for instance, Opera
			redirects all "about" URIs except "about:blank" to its internal
			"opera" URIs).
	2.2.1. Special-Purpose 'about' URIs		2.2.1. Special-Purpose "about" URIs
	A small, though expandable, range of <about-token>s are reserved for		A small, though expandable, range of <about-token>s are reserved for
	use in special-purpose 'about' URIs, abbreviated "SPU" (special-		special purposes ("special-purpose tokens").
	purpose URI). Such tokens are named "special-purpose 'about' URI
	tokens", and abbreviated "SPT" (special-purpose token).
	An SPU is an 'about' URI containing one of the registered SPTs as the
	<about-token> part. An SPU MUST be handled in strict accordance with
	the rules defined for SPT contained therein. The SPT specification
	MAY define additional provisions on handling of <about-query> part in
	the corresponding SPU; by default, it MUST be ignored for the purpose
	of handling SPU.
	SPU MAY be defined to be unresolvable. This means that an
	application MUST NOT resolve it in some particular resource. Such
	SPUs may be used as placeholders, or in some other way.
	One pre-defined SPT is specified: the "blank" SPT. The URI
	<about:blank> MUST resolve to a blank page; this page need not
	necessarily contain no data, it should rather represent blank page.
	There is no additional handling of query component in <about:blank>
	URIs: both <about:blank> and <about:blank?foo> shall resolve into the
	blank page.
	Additional SPTs may be defined via adding the entry in the registry
	created by this document. Please note that defining an SPT should
	only be used as a last resort approach, when a strict limitation on
	handling 'about' URI with such SPT is necessary.
	2.2.2. Unrecognized 'about' URIs		A special-purpose URI is an "about" URI that has a special-purpose
			token as its <about-token> part. Such URIs MUST be handled in strict
			accordance with the rules defined in the special-purpose token
			registry (see Section 4.2). The registered entry MAY also define
			additional provisions for handling of the <about-query> part. If no
			such provisions are defined, the query part has no meaning, and MUST
			be ignored.
	Naturally, an application will support only a particular range of		This document defines one special-purpose token: "blank". The URI
	'about' URIs; also, some applications will support 'about' URIs that		"about:blank" MUST resolve to a blank page, as seen by the end user.
	are not supported by an other one. This document specifies the rules		There is no additional handling of the query component in
	for handling unrecognized 'about' URIs.		"about:blank" URIs.
	An unrecognized 'about' URIs as a URI that may not be recognized by		Additional special-purpose tokens can be defined by registering an
	an application. (Correspondingly, such categorization is per-		registry created in Section 4.2. Special-purpose "about" URIs are
	application, not per-fact.) An unrecognized 'about' URI SHOULD be		intended to be uncommon, and new ones should be defined only when
	handled as the <about:blank> URI, although other behavior is		there is a need to strongly connect a particular <about-token> with a
	possible.		particular function in all applications.
	2.3. Encoding Considerations		2.3. Encoding Considerations
	'about' URIs are subject to encoding rules defined in RFC 3986		"about" URIs are subject to encoding rules defined in RFC 3986
	[RFC3986]. 'about' IRIs [RFC3987] are not permitted.		[RFC3986]. "about" IRIs [RFC3987] are not permitted.
	3. Security Considerations		3. Security Considerations
	Generic security considerations for URIs are discussed in Section 7		Generic security considerations for URIs are discussed in Section 7
	of RFC 3986 [RFC3986]. However, many of those provisions hardly		of RFC 3986 [RFC3986]. However, many of those provisions hardly
	apply to 'about' URI scheme, as they are mainly scoped to schemes		apply to "about" URI scheme, as they are mainly scoped to schemes
	used in the Internet, not internally.		used in the Internet, not internally.
	'about' URIs may sometimes refer to a sensitive information, such as		"about" URIs may sometimes refer to a sensitive information, such as
	user passwords stored in a cache, or parameter that, if changed, may		user passwords stored in a cache, or parameter that, if changed, may
	affect user's data. The application should therefore ensure that		affect user's data. The application should therefore ensure that
	user's data is in the safety, and no threats are imposed by 'about'		user's data is in the safety, and no threats are imposed by "about"
	URIs.		URIs.
	4. IANA Considerations		4. IANA Considerations
	4.1. URI Scheme Registration		4.1. URI Scheme Registration
	IANA is asked to update the register the 'about' URI scheme using the		IANA is asked to register the "about" URI scheme in the "URI Schemes"
	following template, per [RFC4395]:		registry defined in Section 5.4 of RFC 4395 [RFC4395]:
	URI scheme name: about		URI scheme name: about
	Status: Permanent		Status: Permanent
	URI scheme syntax: see Section 2.1 of RFC xxxx		URI scheme syntax: see Section 2.1 of RFC xxxx
	URI scheme semantics: see Section 2.2 of RFC xxxx		URI scheme semantics: see Section 2.2 of RFC xxxx
	URI scheme encoding considerations: see Section 2.3 of RFC xxxx		URI scheme encoding considerations: see Section 2.3 of RFC xxxx
	Applications/protocols that use the scheme: 'about' URIs are		Applications/protocols that use the scheme: "about" URIs are
	predominantly used by Web browsers, although they may be used by		predominantly used by Web browsers, although they may be used by
	other applications.		other applications.
	Security considerations: see Section 3 of RFC xxxx		Security considerations: see Section 3 of RFC xxxx
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org> (on behalf of the IETF)
	Author/Change controller: IETF <ietf@ietf.org>		Author/Change controller: Applications Area IETF Working Group
			<apps-discuss@ietf.org>
	References: see Section 5 of RFC xxxx		References: see Section 5 of RFC xxxx
	[RFC Editor: Please replace xxxx with assigned RFC number]		[RFC Editor: Please replace xxxx with assigned RFC number]
	4.2. A Registry for SPTs		4.2. A Registry for Registered Tokens
	IANA is asked to set up a new registry entitled "'about' URIs SPTs"		IANA is asked to set up a new registry entitled "'about' URI Special
	following the guidelines below.		Purpose Tokens" following the guidelines below.
	The registry entries consist of 3 fields: SPT, Description and		The registry entries consist of 3 fields: Special-Purpose Token,
	Reference. The SPT field MUST conform to <about-token> production		Description and Reference. The Special-Purpose Token field MUST
	defined in Section 2.1. The initial registry contents consist of one		conform to <about-token> production defined in Section 2.1. The
	entry:		initial registry consists of one entry:
	+----------+----------------------------------------+-----------+		+------------------+------------------------------------+-----------+
	| SPT | Description | Reference |		| Special-Purpose | Description | Reference |
	+----------+----------------------------------------+-----------+		| Token | | |
	| blank | Used in 'about' URIs referring to a | RFC xxxx |		+------------------+------------------------------------+-----------+
	| | blank page. | |		| blank | Used in "about" URIs to refer to | RFC xxxx |
	+----------+----------------------------------------+-----------+		| | blank page. | |
			+------------------+------------------------------------+-----------+
	The registration policy for new entries is "Specification Required",		The registration procedures for this registry are "First Come First
	as defined in RFC 5226 [RFC5226]. Additionally, the following		Served", described in RFC 5226 [RFC5226], with supporting
	template MUST be provided by the registrant:		documentation meeting the requirements below. The registrant of the
			token MUST provide the following registration template, which will be
			made available on IANA web site:
	o SPT: The desired special-purpose token to be used in 'about' URIs.		[[for the WG discussion: I, as the WG participant, am convinced that
			we do need Specification Required here. This is a burden, but this
			(and the expert) will give us a warranty that the registered token is
			really useful and is really part of some serious project, probably
			standardization effort. I'd like this also would be discussed in the
			WG, and the WG would change its mind. (Moreover, as I don't expect
			the registrations to be very often, this won't take a great deal of
			experts' time.)]]
	o Intended usage: A short description of how 'about' URIs with the		o Registered Token: The desired special-purpose token to be used in
			"about" URIs.
			o Intended usage: A short description of how "about" URIs with the
	registered token must be handled; especially, what they must be		registered token must be handled; especially, what they must be
	resolved to, if resolvable.		resolved to, if resolvable.
	o Resolvable: "Yes" if resolvable (i.e. can be resolved to a
	particular resource) or "No" if unresolvable (see Section 2.2.1).
	o Handling query component: It should be mentioned whether there are		o Handling query component: It should be mentioned whether there are
	some provisions on handling query components in the 'about' URIs		some provisions on handling query components in the "about" URIs
	with the registered token.		with the registered token.
	o Contact/Change controller: An individual or an organization which		o Contact/Change controller: An individual or an organization which
	(1) should be contacted for more details, and (2) is authorized to		(1) should be contacted for more details, and (2) is authorized to
	change the registration.		change the registration.
	o Published specifications: A reference to the published		o Specification. This provides documentation at a level that could
	specification for the registered token.		be used to create a compliant, interoperable implementation of the
			registered "about" URI. The reference to a full specification MUST
			be provided here, and there should be a reasonable expectation that
			the documentation will remain available. IANA will consult with
			the IESG or its specified delegate if there is doubt about whether
			the specification is adequate for the purpose.
	The following is a template for "blank" SPT:		The following is a template for "blank" token:
	o SPT: blank		o Registered Token: blank
	o Intended usage: The <about:blank> URI must resolve to a blank		o Intended usage: The <about:blank> URI must resolve to a blank
	page.		page.
	o Resolvable: Yes.
	o Handling query component: No special provisions.		o Handling query component: No special provisions.
	o Contact/Change controller: IESG <iesg@ietf.org> (on behalf of		o Contact/Change controller: IESG <iesg@ietf.org> (on behalf of
	IETF).		IETF).
	o Published specifications: This document.		o Specification: This document.
	5. References		5. References
	5.1. Normative References		5.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.
	[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,
	skipping to change at page 7, line 30		skipping to change at page 7, line 30
	Identifiers (IRIs)", RFC 3987, January 2005.		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.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	This document has been formed from the draft initially authored by,		This document has been formed from the draft initially authored by,
	additionally to Lachlan Hunt, the editor of the current one, Joseph		additionally to Lachlan Hunt, the editor of the current one, Joseph
	Holsten. Additionally, the contributions of <TBD> are gratefully		Holsten. Additionally, the contributions of Frank Ellermann and
	acknowledged.		Alexey Melnikov are gratefully acknowledged. Barry Leiba deserves a
			special credit for providing a great amount of text which has been
			used in this document.
	Authors' Addresses		Authors' Addresses
	Lachlan Hunt (editor)		Lachlan Hunt (editor)
	Opera Software, ASA.		Opera Software, ASA.
	EMail: lachlan.hunt@lachy.id.au		EMail: lachlan.hunt@lachy.id.au
	URI: http://lachy.id.au/		URI: http://lachy.id.au/
	Mykyta Yevstifeyev (editor)		Mykyta Yevstifeyev (editor)
End of changes. 43 change blocks.
	105 lines changed or deleted		109 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/