< draft-nottingham-rfc5785bis-03.txt		draft-nottingham-rfc5785bis-04.txt >
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft February 7, 2018		Internet-Draft February 15, 2018
	Obsoletes: 5785 (if approved)		Obsoletes: 5785 (if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: August 11, 2018		Expires: August 19, 2018
	Defining Well-Known Uniform Resource Identifiers (URIs)		Defining Well-Known Uniform Resource Identifiers (URIs)
	draft-nottingham-rfc5785bis-03		draft-nottingham-rfc5785bis-04
	Abstract		Abstract
	This memo defines a path prefix for "well-known locations", "/.well-		This memo defines a path prefix for "well-known locations", "/.well-
	known/", in selected Uniform Resource Identifier (URI) schemes.		known/", in selected Uniform Resource Identifier (URI) schemes.
	Note to Readers		Note to Readers
	_RFC EDITOR: please remove this section before publication_		_RFC EDITOR: please remove this section before publication_
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 11, 2018.		This Internet-Draft will expire on August 19, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 37 ¶		skipping to change at page 2, line 37 ¶
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 5		5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 5
	5.1.1. Registration Template . . . . . . . . . . . . . . . . 6		5.1.1. Registration Template . . . . . . . . . . . . . . . . 6
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Normative References . . . . . . . . . . . . . . . . . . 6		6.1. Normative References . . . . . . . . . . . . . . . . . . 6
	6.2. Informative References . . . . . . . . . . . . . . . . . 7		6.2. Informative References . . . . . . . . . . . . . . . . . 7
	6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7		6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 8		Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 8
	Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 8		Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Some applications on the Web require the discovery of policy or other		Some applications on the Web require the discovery of information
	information about an origin [RFC6454] (sometimes called "site-wide		about an origin [RFC6454] (sometimes called "site-wide metadata")
	metadata") before making a request. For example, the Robots		before making a request. For example, the Robots Exclusion Protocol
	Exclusion Protocol (http://www.robotstxt.org/ [5]) specifies a way		(http://www.robotstxt.org/ [5]) specifies a way for automated
	for automated processes to obtain permission to access resources;		processes to obtain permission to access resources; likewise, the
	likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416]		Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-
	tells user-agents how to discover privacy policy before interacting		agents how to discover privacy policy before interacting with an
	with an origin server.		origin server.
	While there are several ways to access per-resource metadata (e.g.,		While there are several ways to access per-resource metadata (e.g.,
	HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead		HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
	(either in terms of client-perceived latency and/or deployment		(either in terms of client-perceived latency and/or deployment
	difficulties) associated with them often precludes their use in these		difficulties) associated with them often precludes their use in these
	scenarios.		scenarios.
	When this happens, one solution is designating a "well-known		When this happens, one solution is designating a "well-known
	location" for data or services related to the origin, so that it can		location" for data or services related to the origin overall, so that
	be easily located. However, this approach has the drawback of		it can be easily located. However, this approach has the drawback of
	risking collisions, both with other such designated "well-known		risking collisions, both with other such designated "well-known
	locations" and with pre-existing resources.		locations" and with resources that the origin has created (or wishes
			to create).
	To address this, this memo defines a path prefix in HTTP(S) URIs for		To address this, this memo defines a path prefix in HTTP(S) URIs for
	these "well-known locations", "/.well-known/". Future specifications		these "well-known locations", "/.well-known/". Future specifications
	that need to define a resource for such metadata can register their		that need to define a resource for such metadata can register their
	use to avoid collisions and minimise impingement upon origins' URI		use to avoid collisions and minimise impingement upon origins' URI
	space.		space.
	Well-known URIs can also be used with other URI schemes, but only		Well-known URIs can also be used with other URI schemes, but only
	when those schemes' definitions explicitly allow it.		when those schemes' definitions explicitly allow it.
	1.1. Appropriate Use of Well-Known URIs		1.1. Appropriate Use of Well-Known URIs
	There are a number of possible ways that applications could use well-		As per [RFC7320], "publishing independent standards that mandate
	known URIs. However, in keeping with the Architecture of the World-		particular forms of URI substructure is inappropriate, because that
	Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended		essentially usurps ownership." Well-known URIs are not an escape
	for general information retrieval or establishment of large URI		hatch from the requirements therein; they are a very limited carve-
	namespaces.		out of the path name space owned by the authority, ceded to standard
			use for a designated purpose.
	Rather, they are designed to facilitate discovery of information		That purpose is to facilitate discovery of information about an
	about an origin when it isn't practical to use other mechanisms; for		origin when it isn't practical to use other mechanisms; for example,
	example, when discovering policy that needs to be evaluated before a		when discovering policy that needs to be evaluated before a resource
	resource is accessed, or when the information applies to many (or		is accessed, or when the information applies to many (or all) of the
	all) of the origin's resources.		origin's resources.
	As such, the well-known URI space was created with the expectation		Typically, the resource(s) identified by a well-known URI will make
	that it will be used to make policy information and other metadata		information about the origin (e.g., policy) available directly, or
	about the origin available directly (if sufficiently concise), or		provide references to other URIs that provide it. In general, that
	provide references to other URIs that provide it. In general, the		information should be applicable to most origins (i.e., Web sites -
	information it contains should be applicable to most Web origins		while acknowledging that some origins might not use a particular
	(while acknowledging that many will not use a particular well-known		well-known location, for various reasons).
	location, for various reasons).
	In particular, well-known URIs are not a "protocol registry" for		In keeping with the Architecture of the World-Wide Web
	applications and protocols that wish to use HTTP as a substrate.		[W3C.REC-webarch-20041215], well-known URIs are not intended for
	Even if a particular origin is dedicated to the protocol in question,		general information retrieval or establishment of large URI
	it is inappropriate to devote a URL on all origins to a specialist		namespaces.
	protocol that has little or no potential benefit for them.
	Instead, such applications and protocols are encouraged to used a URI		Specifically, well-known URIs are not a "protocol registry" for
	to bootstrap their operation, rather than using a hostname and a		applications and protocols that wish to use HTTP as a substrate.
	well-known URI.		Instead, such applications and protocols are encouraged to used an
			absolute URI to bootstrap their operation, rather than using a
			hostname and a well-known URI.
	Exceptionally, the registry expert(s) may approve such a registration		Exceptionally, the registry expert(s) may approve such a registration
	for documents in the IETF Stream [RFC5741], in consultation with the		for documents in the IETF Stream [RFC5741], in consultation with the
	IESG, provided that the protocol in question cannot be bootstrapped		IESG, provided that the protocol in question cannot be bootstrapped
	with a URI (e.g., the discovery mechanism can only carry a hostname).		with a URI (e.g., the discovery mechanism can only carry a hostname).
	However, merely making it easier to locate it is not a sufficient		However, merely making it easier to locate it is not a sufficient
	reason. Likewise, future use unsupported by the specification in		reason. Likewise, future use unsupported by the specification in
	question is not sufficient reason to register a well-known location.		question is not sufficient reason to register a well-known location.
	Well-known locations are also not suited for information on topics		Well-known locations are also not suited for information on topics
	skipping to change at page 7, line 9 ¶		skipping to change at page 7, line 9 ¶
	[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,		[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
	Headers, and Boilerplates", RFC 5741,		Headers, and Boilerplates", RFC 5741,
	DOI 10.17487/RFC5741, December 2009,		DOI 10.17487/RFC5741, December 2009,
	<https://www.rfc-editor.org/info/rfc5741>.		<https://www.rfc-editor.org/info/rfc5741>.
	[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,		[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	DOI 10.17487/RFC6454, December 2011,		DOI 10.17487/RFC6454, December 2011,
	<https://www.rfc-editor.org/info/rfc6454>.		<https://www.rfc-editor.org/info/rfc6454>.
			[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
			RFC 7320, DOI 10.17487/RFC7320, July 2014,
			<https://www.rfc-editor.org/info/rfc7320>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	6.2. Informative References		6.2. Informative References
	[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed		[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
	Authoring and Versioning (WebDAV)", RFC 4918,		Authoring and Versioning (WebDAV)", RFC 4918,
	DOI 10.17487/RFC4918, June 2007,		DOI 10.17487/RFC4918, June 2007,
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 41 ¶
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014,
	<https://www.rfc-editor.org/info/rfc7231>.		<https://www.rfc-editor.org/info/rfc7231>.
	[W3C.REC-P3P-20020416]		[W3C.REC-P3P-20020416]
	Marchiori, M., "The Platform for Privacy Preferences 1.0		Marchiori, M., "The Platform for Privacy Preferences 1.0
	(P3P1.0) Specification", World Wide Web Consortium		(P3P1.0) Specification", World Wide Web Consortium
	Recommendation REC-P3P-20020416, April 2002,		Recommendation REC-P3P-20020416, April 2002,
	<http://www.w3.org/TR/2002/REC-P3P-20020416>.		<http://www.w3.org/TR/2002/REC-P3P-20020416>.
			[W3C.REC-webarch-20041215]
			Jacobs, I. and N. Walsh, "Architecture of the World Wide
			Web, Volume One", World Wide Web Consortium
			Recommendation REC-webarch-20041215, December 2004,
			<http://www.w3.org/TR/2004/REC-webarch-20041215>.
	6.3. URIs		6.3. URIs
	[1] https://github.com/mnot/I-D/labels/rfc5785bis		[1] https://github.com/mnot/I-D/labels/rfc5785bis
	[2] https://mnot.github.io/I-D/rfc5785bis/		[2] https://mnot.github.io/I-D/rfc5785bis/
	[3] https://github.com/mnot/I-D/commits/gh-pages/rfc5785bis		[3] https://github.com/mnot/I-D/commits/gh-pages/rfc5785bis
	[4] https://datatracker.ietf.org/doc/draft-nottingham-rfc5785bis/		[4] https://datatracker.ietf.org/doc/draft-nottingham-rfc5785bis/
End of changes. 15 change blocks.
	41 lines changed or deleted		53 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/