< draft-ietf-appsawg-uri-get-off-my-lawn-01.txt		draft-ietf-appsawg-uri-get-off-my-lawn-02.txt >
	appsawg M. Nottingham		appsawg M. Nottingham
	Internet-Draft January 30, 2014		Internet-Draft April 3, 2014
	Updates: 3986 (if approved)		Updates: 3986 (if approved)
	Intended status: BCP		Intended status: BCP
	Expires: August 3, 2014		Expires: October 5, 2014
	URI Design and Ownership		URI Design and Ownership
	draft-ietf-appsawg-uri-get-off-my-lawn-01		draft-ietf-appsawg-uri-get-off-my-lawn-02
	Abstract		Abstract
	Sometimes, it is attractive to add features to protocols or		RFC3986 Section 3.1 defines URI syntax as "a federated and extensible
	applications by specifying a particular structure for URIs (or parts		naming system my further restrict the syntax and semantics of
	thereof). However, publishing standards that mandate URI structure		identifiers using that scheme." In other words, the structure of a
	is inappropriate because the structure of a URI needs to be firmly		URI is defined by its scheme. While it is common for schemes to
	under the control of its owner, and the IETF (as well as other		further delegate their substructure to the URI's owner, publishing
	organisations) should not usurp this ownership.		standards that mandate particular forms of URI substructure is
			inappropriate, because the effectively usurps ownership.
	This document is intended to prevent this practice (sometimes called		This document is intended to prevent this practice (sometimes called
	"URI Squatting") in standards, but updating RFC3986 to indicate where		"URI Squatting") in standards, but updating RFC3986 to indicate where
	it is acceptable.		it is acceptable.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). 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 August 3, 2014.		This Internet-Draft will expire on October 5, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 16 ¶		skipping to change at page 2, line 17 ¶
	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
	1.1. Who This Document Is For . . . . . . . . . . . . . . . . . 4		1.1. Who This Document Is For . . . . . . . . . . . . . . . . . 4
	1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4		1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4
	2. Best Current Practices for Standardising Structured URIs . . . 5		2. Best Current Practices for Standardizing Structured URIs . . . 4
	2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. URI Authorities . . . . . . . . . . . . . . . . . . . . . . 5		2.2. URI Authorities . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. URI Paths . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. URI Paths . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.4. URI Queries . . . . . . . . . . . . . . . . . . . . . . . . 5		2.4. URI Queries . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.5. URI Fragment Identifiers . . . . . . . . . . . . . . . . . 6		2.5. URI Fragment Identifiers . . . . . . . . . . . . . . . . . 6
	3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	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
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 21 ¶
	authority component (e.g., some applications are spread across		authority component (e.g., some applications are spread across
	several hostnames to enable a form of partitioning or dispatch).		several hostnames to enable a form of partitioning or dispatch).
	Furthermore, constraints upon the structure of URIs can be imposed by		Furthermore, constraints upon the structure of URIs can be imposed by
	an implementation; for example, many Web servers use the filename		an implementation; for example, many Web servers use the filename
	extension of the last path segment to determine the media type of the		extension of the last path segment to determine the media type of the
	response. Likewise, pre-packaged applications often have highly		response. Likewise, pre-packaged applications often have highly
	structured URIs that can only be changed in limited ways (often, just		structured URIs that can only be changed in limited ways (often, just
	the hostname and port they are deployed upon).		the hostname and port they are deployed upon).
	Because the owner of the URI is choosing to use the server or the		Because the owner of the URI (as defined in [webarch] Section
	software, this can be seen as reasonable delegation of authority.		2.2.2.1) is choosing to use the server or the software, this can be
	When such conventions are mandated by standards, however, it can have		seen as reasonable delegation of authority. When such conventions
			are mandated by a party other than the owner, however, it can have
	several potentially detrimental effects:		several potentially detrimental effects:
	o Collisions - As more conventions for URI structure become		o Collisions - As more conventions for URI structure become
	standardised, it becomes more likely that there will be collisions		standardized, it becomes more likely that there will be collisions
	between such conventions (especially considering that servers,		between such conventions (especially considering that servers,
	applications and individual deployments will have their own		applications and individual deployments will have their own
	conventions).		conventions).
	o Dilution - When the information added to a URI is ephemeral, this		o Dilution - When the information added to a URI is ephemeral, this
	dilutes its utility by reducing its stability (see [webarch]		dilutes its utility by reducing its stability (see [webarch]
	Section 3.5.1), and can cause several alternate forms of the URI		Section 3.5.1), and can cause several alternate forms of the URI
	to exist (see [webarch] Section 2.3.1).		to exist (see [webarch] Section 2.3.1).
	o Rigidity - Fixed URI syntax often interferes with desired		o Rigidity - Fixed URI syntax often interferes with desired
	deployment patterns. For example, if an authority wishes to offer		deployment patterns. For example, if an authority wishes to offer
	several applications on a single hostname, it becomes difficult to		several applications on a single hostname, it becomes difficult to
	impossible to do if their URIs do not allow the required		impossible to do if their URIs do not allow the required
	flexibility.		flexibility.
	o Operational Difficulty - Supporting some URI conventions can be		o Operational Difficulty - Supporting some URI conventions can be
	difficult in some implementations. For example, specifying that a		difficult in some implementations. For example, specifying that a
	particular query parameter be used precludes the use of Web		particular query parameter be used precludes the use of Web
	servers that serve the response from a filesystem. Likewise, an		servers that serve the response from a filesystem. Likewise, an
	application that fixes a base path for its operation (e.g., "/v1")		application that fixes a base path for its operation (e.g., "/v1")
	makes it impossible to deploy other applications with the same		makes it impossible to deploy other applications with the same
	prefix on the same host.		prefix on the same host.
	o Client Assumptions - When conventions are standardised, some		o Client Assumptions - When conventions are standardized, some
	clients will inevitably assume that the standards are in use when		clients will inevitably assume that the standards are in use when
	those conventions are seen. This can lead to interoperability		those conventions are seen. This can lead to interoperability
	problems; for example, if a specification documents that the "sig"		problems; for example, if a specification documents that the "sig"
	URI query parameter indicates that its payload is a cryptographic		URI query parameter indicates that its payload is a cryptographic
	signature for the URI, it can lead to undesirable behaviour.		signature for the URI, it can lead to undesirable behavior.
	While it is not ideal when a server or a deployed application		Publishing standards that constrain URI structure in ways which
	constrains URI structure (indeed, this is not recommended practice,		aren't explicitly allowed by [RFC3986] (e.g., by defining it in the
	but that discussion is out of scope for this document), publishing		URI scheme) is usually inappropriate, because the structure of a URI
	standards that mandate URI structure (beyond those allowed by		needs to be firmly under the control of its owner, and the IETF (as
	[RFC3986]) is inappropriate because the structure of a URI needs to		well as other organizations) should not usurp it.
	be firmly under the control of its owner, and the IETF (as well as
	other organisations) should not usurp this ownership; see [webarch]
	Section 2.2.2.1.
	This document explains best current practices for establishing URI		This document explains best current practices for establishing URI
	structures, conventions and formats in standards. It also offers		structures, conventions and formats in standards. It also offers
	strategies for specifications to avoid violating these guidelines in		strategies for specifications to avoid violating these guidelines in
	Appendix B.		Appendix B.
	1.1. Who This Document Is For		1.1. Who This Document Is For
	This document's requirements specifically target a few different		This document's requirements primarily target a few different types
	types of specifications:		of specifications:
	o URI Scheme Definitions ("scheme definitions") - specifications
	that define and register URI schemes, as per [RFC4395].
	o Protocol Extensions ("extensions") - specifications that offer new		o Protocol Extensions ("extensions") - specifications that offer new
	capabilities to potentially any identifier, or a large subset;		capabilities to potentially any identifier, or a large subset;
	e.g., a new signature mechanism for 'http' URIs, or metadata for		e.g., a new signature mechanism for 'http' URIs, or metadata for
	any URI.		any URI.
	o Applications Using URIs ("applications") - specifications that use		o Applications Using URIs ("applications") - specifications that use
	URIs to meet specific needs; e.g., a HTTP interface to particular		URIs to meet specific needs; e.g., a HTTP interface to particular
	information on a host.		information on a host.
	Requirements that target the generic class "Specifications" apply to		Requirements that target the generic class "Specifications" apply to
	all specifications, including both those enumerated above above and		all specifications, including both those enumerated above and others.
	others.
	Note that this specification ought not be interpreted as preventing		Note that this specification ought not be interpreted as preventing
	the allocation of control of URIs by parties that legitimately own		the allocation of control of URIs by parties that legitimately own
	them, or have delegated that ownership; for example, a specification		them, or have delegated that ownership; for example, a specification
	might legitimately define the semantics of a URI on the IANA.ORG Web		might legitimately define the semantics of a URI on the IANA.ORG Web
	site as part of the establishment of a registry.		site as part of the establishment of a registry.
	1.2. Notational Conventions		1.2. Notational Conventions
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Best Current Practices for Standardising Structured URIs		2. Best Current Practices for Standardizing Structured URIs
	Best practices differ depending on the URI component.		Best practices differ depending on the URI component.
	2.1. URI Schemes		2.1. URI Schemes
	Applications and extensions MAY require use of specific URI		Applications and extensions MAY require use of specific URI
	scheme(s); for example, it is perfectly acceptable to require that an		scheme(s); for example, it is perfectly acceptable to require that an
	application support 'http' and 'https' URIs. However, applications		application support 'http' and 'https' URIs. However, applications
	SHOULD NOT preclude the use of other URI schemes in the future,		SHOULD NOT preclude the use of other URI schemes in the future,
	unless they are clearly specific to the nominated schemes.		unless they are clearly specific to the nominated schemes.
	A specification that defines substructure within a URI scheme MUST do		A specification that defines substructure within a URI scheme MUST do
	so in a registration document for the URI scheme in question, or by		so in the defining document for the URI scheme in question, or by
	modifying [RFC4395].		modifying [RFC4395].
	2.2. URI Authorities		2.2. URI Authorities
	Scheme definitions define the presence, format and semantics of an		Scheme definitions define the presence, format and semantics of an
	authority component in URIs; all other specifications MUST NOT		authority component in URIs; all other specifications MUST NOT
	constrain, define structure or semantics for URI authorities.		constrain, define structure or semantics for URI authorities, unless
			they update the scheme registration itself.
	For example, an extension or application cannot say that the "foo"		For example, an extension or application cannot say that the "foo"
	prefix in "foo_app.example.com" is meaningful or triggers special		prefix in "foo_app.example.com" is meaningful or triggers special
	handling.		handling.
	2.3. URI Paths		2.3. URI Paths
	Scheme definitions define the presence, format, and semantics of a		Scheme definitions define the presence, format, and semantics of a
	path component in URIs; all other specifications MUST NOT constrain,		path component in URIs; all other specifications MUST NOT constrain,
	define structure or semantics for any path component.		define structure or semantics for any path component.
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 14 ¶
	support a particular form of a query.		support a particular form of a query.
	Extensions MUST NOT specify the format or semantics of queries.		Extensions MUST NOT specify the format or semantics of queries.
	For example, an extension cannot be minted that indicates that all		For example, an extension cannot be minted that indicates that all
	query parameters with the name "sig" indicate a cryptographic		query parameters with the name "sig" indicate a cryptographic
	signature.		signature.
	2.5. URI Fragment Identifiers		2.5. URI Fragment Identifiers
	Media type definitions (as per [RFC6838] SHOULD specify the fragment		Media type definitions (as per [RFC6838]) SHOULD specify the fragment
	identifier syntax(es) to be used with them; other specifications MUST		identifier syntax(es) to be used with them; other specifications MUST
	NOT define structure within the fragment identifier, unless they are		NOT define structure within the fragment identifier, unless they are
	explicitly defining one for reuse by media type definitions.		explicitly defining one for reuse by media type definitions.
	3. Security Considerations		3. Security Considerations
	This document does not introduce new protocol artifacts with security		This document does not introduce new protocol artifacts with security
	considerations. It prohibits some practices that might lead to		considerations. It prohibits some practices that might lead to
	vulnerabilities; for example, if a security-sensitive mechanism is		vulnerabilities; for example, if a security-sensitive mechanism is
	introduced by assuming that a URI path component or query string has		introduced by assuming that a URI path component or query string has
	a particular meaning, false positives might be encountered (due to		a particular meaning, false positives might be encountered (due to
	sites that already use the chosen string).		sites that already use the chosen string). See also [RFC6943].
	4. IANA Considerations		4. IANA Considerations
	This document clarifies appropriate registry policy for new URI		There are no direct IANA actions specified in this document.
	schemes, and potentially for the creation of new URI-related
	registries, if they attempt to mandate structure within URIs. There
	are no direct IANA actions specified in 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 22 ¶		skipping to change at page 7, line 17 ¶
	[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known		[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
	Uniform Resource Identifiers (URIs)", RFC 5785,		Uniform Resource Identifiers (URIs)", RFC 5785,
	April 2010.		April 2010.
	[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.		[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
	[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,		[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
	and D. Orchard, "URI Template", RFC 6570, March 2012.		and D. Orchard, "URI Template", RFC 6570, March 2012.
			[RFC6943] Thaler, D., "Issues in Identifier Comparison for Security
			Purposes", RFC 6943, May 2013.
	[webarch] Jacobs, I. and N. Walsh, "Architecture of the World Wide		[webarch] Jacobs, I. and N. Walsh, "Architecture of the World Wide
	Web, Volume One", December 2004,		Web, Volume One", December 2004,
	<http://www.w3.org/TR/2004/REC-webarch-20041215>.		<http://www.w3.org/TR/2004/REC-webarch-20041215>.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	Thanks to David Booth, Dave Crocker, Tim Bray, Anne van Kesteren,		Thanks to David Booth, Dave Crocker, Tim Bray, Anne van Kesteren,
	Martin Thomson and Erik Wilde for their suggestions and feedback.		Martin Thomson, Erik Wilde and Dave Thaler for their suggestions and
			feedback.
	Appendix B. Alternatives to Specifying Structure in URIs		Appendix B. Alternatives to Specifying Structure in URIs
	Given the issues above, the most successful strategy for applications		Given the issues above, the most successful strategy for applications
	and extensions that wish to use URIs is to use them in the fashion		and extensions that wish to use URIs is to use them in the fashion
	they were designed; as links that are exchanged as part of the		they were designed; as links that are exchanged as part of the
	protocol, rather than statically specified syntax. Several existing		protocol, rather than statically specified syntax. Several existing
	specifications can aid in this.		specifications can aid in this.
	[RFC5988] specifies relation types for Web links. By providing a		[RFC5988] specifies relation types for Web links. By providing a
End of changes. 22 change blocks.
	41 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/