< draft-ietf-appsawg-uri-get-off-my-lawn-03.txt		draft-ietf-appsawg-uri-get-off-my-lawn-04.txt >
	appsawg M. Nottingham		appsawg M. Nottingham
	Internet-Draft April 7, 2014		Internet-Draft
	Updates: 3986 (if approved)		Updates: 3986 (if approved) April 23, 2014
	Intended status: BCP		Intended status: Best Current Practice
	Expires: October 9, 2014		Expires: October 25, 2014
	URI Design and Ownership		URI Design and Ownership
	draft-ietf-appsawg-uri-get-off-my-lawn-03		draft-ietf-appsawg-uri-get-off-my-lawn-04
	Abstract		Abstract
	RFC3986 Section 1.1.1 defines URI syntax as "a federated and		RFC3986 Section 1.1.1 defines URI syntax as "a federated and
	extensible naming system wherein each scheme's specification may		extensible naming system wherein each scheme's specification may
	further restrict the syntax and semantics of identifiers using that		further restrict the syntax and semantics of identifiers using that
	scheme." In other words, the structure of a URI is defined by its		scheme." In other words, the structure of a URI is defined by its
	scheme. While it is common for schemes to further delegate their		scheme. While it is common for schemes to further delegate their
	substructure to the URI's owner, publishing independent standards		substructure to the URI's owner, publishing independent standards
	that mandate particular forms of URI substructure is inappropriate,		that mandate particular forms of URI substructure is inappropriate,
	because the essentially usurps ownership. This document clarifies		because that essentially usurps ownership. This document further
	both this problematic practice and some acceptable alternatives in		describes this problematic practice and provides some acceptable
	standards.		alternatives for use in standards.
	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 October 9, 2014.		This Internet-Draft will expire on October 25, 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
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Who This Document Is For . . . . . . . . . . . . . . . . . 4		1.1. Who This Document Is For . . . . . . . . . . . . . . . . 3
	1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4		1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
	2. Best Current Practices for Standardizing Structured URIs . . . 4		2. Best Current Practices for Standardizing Structured URIs . . 4
	2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. URI Authorities . . . . . . . . . . . . . . . . . . . . . . 5		2.2. URI Authorities . . . . . . . . . . . . . . . . . . . . . 4
	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 . . . . . . . . . . . . . . . . 5
	3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		3. Alternatives to Specifying Structure in URIs . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 6		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Informative References . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . 7
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7		6.2. Informative References . . . . . . . . . . . . . . . . . 7
	Appendix B. Alternatives to Specifying Structure in URIs . . . . . 7		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	URIs [RFC3986] very often include structured application data. This		URIs [RFC3986] very often include structured application data. This
	might include artifacts from filesystems (often occurring in the path		might include artifacts from filesystems (often occurring in the path
	component), and user information (often in the query component). In		component), and user information (often in the query component). In
	some cases, there can even be application-specific data in the		some cases, there can even be application-specific data in the
	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 (as defined in [webarch] Section		Because the owner of the URI (as defined in [webarch]
	2.2.2.1) is choosing to use the server or the software, this can be		Section 2.2.2.1) is choosing to use the server or the software, this
	seen as reasonable delegation of authority. When such conventions		can be seen as reasonable delegation of authority. When such
	are mandated by a party other than the owner, however, it can have		conventions are mandated by a party other than the owner, however, it
	several potentially detrimental effects:		can have several potentially detrimental effects:
	o Collisions - As more ad hoc conventions for URI structure become		o Collisions - As more ad hoc conventions for URI structure become
	standardized, it becomes more likely that there will be collisions		standardized, it becomes more likely that there will be collisions
	between them (especially considering that servers, applications		between them (especially considering that servers, applications
	and individual deployments will have their own conventions).		and individual deployments will have their own 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 standardized, 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 behavior.		signature for the URI, it can lead to undesirable behavior.
	Publishing an independent standard that constrains an existing URI		Publishing an independent standard that constrains an existing URI
	structure in ways which aren't explicitly allowed by [RFC3986] (e.g.,		structure in ways which aren't explicitly allowed by [RFC3986] (e.g.,
	by defining it in the URI scheme) is usually inappropriate, because		by defining it in the URI scheme) is usually inappropriate, because
	the structure of a URI needs to be firmly under the control of its		the structure of a URI needs to be firmly under the control of its
	owner, and the IETF (as well as other organizations) should not usurp		owner, and the IETF (as well as other organizations) should not usurp
	it.		it.
	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.		Section 3.
	1.1. Who This Document Is For		1.1. Who This Document Is For
	This document's requirements primarily target a few different types		This document's requirements primarily target a few different types
	of specifications:		of specifications:
	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.
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 31 ¶
	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 Standardizing Structured URIs		2. Best Current Practices for Standardizing Structured URIs
	Best practices differ depending on the URI component, as described in		This section updates [RFC3986] by setting limitations on how other
	this section.		specifications may define structure and semantics within URIs. Best
			practices differ depending on the URI component, as described below.
	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
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 22 ¶
	path component in URIs; all other specifications MUST NOT constrain,		path component in URIs; all other specifications MUST NOT constrain,
	or define the structure or the semantics for any path component.		or define the structure or the semantics for any path component.
	The only exception to this requirement is registered "well-known"		The only exception to this requirement is registered "well-known"
	URIs, as specified by [RFC5785]. See that document for a description		URIs, as specified by [RFC5785]. See that document for a description
	of the applicability of that mechanism.		of the applicability of that mechanism.
	For example, an application cannot specify a fixed URI path "/myapp",		For example, an application cannot specify a fixed URI path "/myapp",
	since this usurps the host's control of that space. Specifying a		since this usurps the host's control of that space. Specifying a
	fixed path relative to another (e.g., {whatever}/myapp) is also bad		fixed path relative to another (e.g., {whatever}/myapp) is also bad
	practice, since it "locks" the URIs in use; while doing so might		practice (even if "whatever" is discovered as suggested in
	prevent collisions, it does not avoid the other issues discussed.		Section 3); while doing so might prevent collisions, it does not
			avoid the potential for operational difficulties discussed in
			Section 1.
	2.4. URI Queries		2.4. URI Queries
	The presence, format and semantics of the query component of URIs is		The presence, format and semantics of the query component of URIs is
	dependent upon many factors, and MAY be constrained by a scheme		dependent upon many factors, and MAY be constrained by a scheme
	definition. Often, they are determined by the implementation of a		definition. Often, they are determined by the implementation of a
	resource itself.		resource itself.
	Applications SHOULD NOT directly specify the syntax of queries, as		Applications SHOULD NOT directly specify the syntax of queries, as
	this can cause operational difficulties for deployments that do not		this can cause operational difficulties for deployments that do not
	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 that indicates that all query parameters
	query parameters with the name "sig" indicate a cryptographic		with the name "sig" indicate a cryptographic signature is not
	signature.		conforming; doing so would collide with potentially pre-existing
			query parameters on sites, and lead clients to assume that any
			matching query parameter is a 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		For example, an application that defines common fragment identifiers
			across media types not controlled by it is not conforming, and would
			engender interoperability problems with handlers for those media
			types (because the new, non-standard syntax is not expected).
			3. Alternatives to Specifying Structure in URIs
			Given the issues described in Section 1, the most successful strategy
			for applications 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 protocol, rather than statically specified syntax.
			Several existing specifications can aid in this.
			[RFC5988] specifies relation types for Web links. By providing a
			framework for linking on the Web, where every link has a relation
			type, context and target, it allows applications to define a link's
			semantics and connectivity.
			[RFC6570] provides a standard syntax for URI Templates that can be
			used to dynamically insert application-specific variables into a URI
			to enable such applications while avoiding impinging upon URI owners'
			control of them.
			[RFC5785] allows specific paths to be 'reserved' for standard use on
			URI schemes that opt into that mechanism ('http' and 'https' by
			default). Note, however, that this is not a general "escape valve"
			for applications that need structured URIs; see that specification
			for more information.
			Specifying more elaborate structures in an attempt to avoid
			collisions is not an acceptable solution, and does not address the
			issues in Section 1. For example, prefixing query parameters with
			"myapp_" does not help, because the prefix itself is subject to the
			risk of collision (since it is not "reserved").
			4. 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). See also [RFC6943].		sites that already use the chosen string). See also [RFC6943].
	4. IANA Considerations		5. IANA Considerations
	There are no direct IANA actions specified in this document.		There are no direct IANA actions specified in this document.
	5. References		6. References
	5.1. Normative References		6.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, RFC
	RFC 3986, January 2005.		3986, January 2005.
	[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
	Registration Procedures for New URI Schemes", BCP 35,
	RFC 4395, February 2006.
	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,		Specifications and Registration Procedures", BCP 13, RFC
	RFC 6838, January 2013.		6838, January 2013.
	5.2. Informative References		[webarch] Jacobs, I. and N. Walsh, "Architecture of the World Wide
			Web, Volume One", December 2004,
			<http://www.w3.org/TR/2004/REC-webarch-20041215>.
			6.2. Informative References
			[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
			Registration Procedures for New URI Schemes", BCP 35, RFC
			4395, February 2006.
	[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
	April 2010.		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		[RFC6943] Thaler, D., "Issues in Identifier Comparison for Security
	Purposes", RFC 6943, May 2013.		Purposes", RFC 6943, May 2013.
	[webarch] Jacobs, I. and N. Walsh, "Architecture of the World Wide
	Web, Volume One", December 2004,
	<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, Erik Wilde and Dave Thaler for their suggestions and		Martin Thomson, Erik Wilde, Dave Thaler and Barry Leiba for their
	feedback.		suggestions and feedback.
	Appendix B. Alternatives to Specifying Structure in URIs
	Given the issues above, the most successful strategy for applications
	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
	protocol, rather than statically specified syntax. Several existing
	specifications can aid in this.
	[RFC5988] specifies relation types for Web links. By providing a
	framework for linking on the Web, where every link has a relation
	type, context and target, it allows applications to define a link's
	semantics and connectivity.
	[RFC6570] provides a standard syntax for URI Templates that can be
	used to dynamically insert application-specific variables into a URI
	to enable such applications while avoiding impinging upon URI owners'
	control of them.
	[RFC5785] allows specific paths to be 'reserved' for standard use on
	URI schemes that opt into that mechanism ('http' and 'https' by
	default). Note, however, that this is not a general "escape valve"
	for applications that need structured URIs; see that specification
	for more information.
	Specifying more elaborate structures in an attempt to avoid
	collisions is not adequate to conform to this document. For example,
	prefixing query parameters with "myapp_" does not help, because the
	prefix itself is subject to the risk of collision (since it is not
	"reserved").
	Author's Address		Author's Address
	Mark Nottingham		Mark Nottingham
	Email: mnot@mnot.net		Email: mnot@mnot.net
	URI: http://www.mnot.net/		URI: http://www.mnot.net/
End of changes. 25 change blocks.
	91 lines changed or deleted		105 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/