< draft-ietf-appsawg-uri-get-off-my-lawn-02.txt		draft-ietf-appsawg-uri-get-off-my-lawn-03.txt >
	appsawg M. Nottingham		appsawg M. Nottingham
	Internet-Draft April 3, 2014		Internet-Draft April 7, 2014
	Updates: 3986 (if approved)		Updates: 3986 (if approved)
	Intended status: BCP		Intended status: BCP
	Expires: October 5, 2014		Expires: October 9, 2014
	URI Design and Ownership		URI Design and Ownership
	draft-ietf-appsawg-uri-get-off-my-lawn-02		draft-ietf-appsawg-uri-get-off-my-lawn-03
	Abstract		Abstract
	RFC3986 Section 3.1 defines URI syntax as "a federated and extensible		RFC3986 Section 1.1.1 defines URI syntax as "a federated and
	naming system my further restrict the syntax and semantics of		extensible naming system wherein each scheme's specification may
	identifiers using that scheme." In other words, the structure of a		further restrict the syntax and semantics of identifiers using that
	URI is defined by its scheme. While it is common for schemes to		scheme." In other words, the structure of a URI is defined by its
	further delegate their substructure to the URI's owner, publishing		scheme. While it is common for schemes to further delegate their
	standards that mandate particular forms of URI substructure is		substructure to the URI's owner, publishing independent standards
	inappropriate, because the effectively usurps ownership.		that mandate particular forms of URI substructure is inappropriate,
			because the essentially usurps ownership. This document clarifies
	This document is intended to prevent this practice (sometimes called		both this problematic practice and some acceptable alternatives in
	"URI Squatting") in standards, but updating RFC3986 to indicate where		standards.
	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 October 5, 2014.		This Internet-Draft will expire on October 9, 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 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	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] Section
	2.2.2.1) is choosing to use the server or the software, this can be		2.2.2.1) is choosing to use the server or the software, this can be
	seen as reasonable delegation of authority. When such conventions		seen as reasonable delegation of authority. When such conventions
	are mandated by a party other than the owner, however, it can have		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 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 such conventions (especially considering that servers,		between them (especially considering that servers, applications
	applications and individual deployments will have their own		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
	skipping to change at page 4, line 6 ¶		skipping to change at page 4, line 5 ¶
	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 standards that constrain URI structure in ways which		Publishing an independent standard that constrains an existing URI
	aren't explicitly allowed by [RFC3986] (e.g., by defining it in the		structure in ways which aren't explicitly allowed by [RFC3986] (e.g.,
	URI scheme) is usually inappropriate, because the structure of a URI		by defining it in the URI scheme) is usually inappropriate, because
	needs to be firmly under the control of its owner, and the IETF (as		the structure of a URI needs to be firmly under the control of its
	well as other organizations) should not usurp it.		owner, and the IETF (as well as other organizations) should not usurp
			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.		Appendix B.
	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:
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 47 ¶
	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.		Best practices differ depending on the URI component, as described in
			this section.
	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 the defining document for the URI scheme in question, or by		so in the defining document for that URI scheme, or by modifying
	modifying [RFC4395].		[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, unless		constrain, or define the structure or the semantics for URI
	they update the scheme registration itself.		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 in URIs.
	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.		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, since it "locks" the URIs in use; while doing so might
	prevent collisions, it does not avoid the other issues discussed.		prevent collisions, it does not avoid the other issues discussed.
End of changes. 13 change blocks.
	31 lines changed or deleted		31 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/