< draft-nottingham-rfc5785bis-05.txt		draft-nottingham-rfc5785bis-06.txt >
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft April 5, 2018		Internet-Draft May 24, 2018
	Obsoletes: 5785 (if approved)		Obsoletes: 5785 (if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: October 7, 2018		Expires: November 25, 2018
	Defining Well-Known Uniform Resource Identifiers (URIs)		Well-Known Uniform Resource Identifiers (URIs)
	draft-nottingham-rfc5785bis-05		draft-nottingham-rfc5785bis-06
	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 October 7, 2018.		This Internet-Draft will expire on November 25, 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 28 ¶		skipping to change at page 2, line 28 ¶
	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
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3		2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
	3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 3		3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Registering Well-Known URIs . . . . . . . . . . . . . . . 4		3.1. Registering Well-Known URIs . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	4.1. Interaction with the Web . . . . . . . . . . . . . . . . 5		4.1. Interaction with Web Browsing . . . . . . . . . . . . . . 5
	4.2. Scoping Applications . . . . . . . . . . . . . . . . . . 6		4.2. Scoping Applications . . . . . . . . . . . . . . . . . . 6
	4.3. Hidden Capabilities . . . . . . . . . . . . . . . . . . . 7		4.3. Hidden Capabilities . . . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 7		5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Normative References . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . 8
	6.2. Informative References . . . . . . . . . . . . . . . . . 8		6.2. Informative References . . . . . . . . . . . . . . . . . 8
	6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 9		Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 10
	Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 10		Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Some applications on the Web require the discovery of information		Some applications on the Web require the discovery of information
	about an origin [RFC6454] (sometimes called "site-wide metadata")		about an origin [RFC6454] (sometimes called "site-wide metadata")
	before making a request. For example, the Robots Exclusion Protocol		before making a request. For example, the Robots Exclusion Protocol
	(http://www.robotstxt.org/ [5]) specifies a way for automated		(http://www.robotstxt.org/ [5]) specifies a way for automated
	processes to obtain permission to access resources; likewise, the		processes to obtain permission to access resources; likewise, the
	Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-		Platform for Privacy Preferences [P3P] tells user-agents how to
	agents how to discover privacy policy before interacting with an		discover privacy policy before interacting 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.
			At the same time, it has become more popular to use HTTP as a
			substrate for non-Web protocols. Sometimes, such protocols need a
			way to locate one or more resources on a given host.
	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 overall, so that		location" for data or services related to the origin overall, so that
	it can 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 resources that the origin has created (or wishes		locations" and with resources that the origin has created (or wishes
	to create).		to create). Furthermore, defining well-known locations usurp's the
			origin's control over its own URI space [RFC7320].
	At the same time, it has become more popular to use HTTP as a
	substrate for non-Web protocols. Sometimes, such protocols need a
	way to locate one or more resources on a given host.
	To address these uses, this memo defines a path prefix in HTTP(S)		To address these uses, this memo defines a path prefix in HTTP(S)
	URIs for these "well-known locations", "/.well-known/". Future		URIs for these "well-known locations", "/.well-known/". Future
	specifications that need to define a resource for such metadata can		specifications that need to define a resource for such metadata can
	register their use to avoid collisions and minimise impingement upon		register their use to avoid collisions and minimise impingement upon
	origins' URI space.		origins' URI 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.
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 15 ¶
	Registered names MUST conform to the segment-nz production in		Registered names MUST conform to the segment-nz production in
	[RFC3986]. This means they cannot contain the "/" character.		[RFC3986]. This means they cannot contain the "/" character.
	Registered names for a specific application SHOULD be correspondingly		Registered names for a specific application SHOULD be correspondingly
	precise; "squatting" on generic terms is not encouraged. For		precise; "squatting" on generic terms is not encouraged. For
	example, if the Example application wants a well-known location for		example, if the Example application wants a well-known location for
	metadata, an appropriate registered name might be "example-metadata"		metadata, an appropriate registered name might be "example-metadata"
	or even "example.com-metadata", not "metadata".		or even "example.com-metadata", not "metadata".
	At a minimum, a registration will reference a specification that		At a minimum, a registration will reference a specification that
	defines the format and associated media type to be obtained by		defines the format and associated media type(s) to be obtained by
	dereferencing the well-known URI, along with the URI scheme(s) that		dereferencing the well-known URI, along with the URI scheme(s) that
	the well-known URI can be used with. If no URI schemes are		the well-known URI can be used with. If no URI schemes are
	explicitly specified, "HTTP" and "HTTPS" are assumed.		explicitly specified, "HTTP" and "HTTPS" are assumed.
	It MAY also contain additional information, such as the syntax of		It MAY also contain additional information, such as the syntax of
	additional path components, query strings and/or fragment identifiers		additional path components, query strings and/or fragment identifiers
	to be appended to the well-known URI, or protocol-specific details		to be appended to the well-known URI, or protocol-specific details
	(e.g., HTTP [RFC7231] method handling).		(e.g., HTTP [RFC7231] method handling).
	Note that this specification defines neither how to determine the		Note that this specification defines neither how to determine the
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 24 ¶
	the field, preferably including a URI that can be used to retrieve		the field, preferably including a URI that can be used to retrieve
	a copy of the document. An indication of the relevant sections		a copy of the document. An indication of the relevant sections
	may also be included, but is not required.		may also be included, but is not required.
	Related information: Optionally, citations to additional documents		Related information: Optionally, citations to additional documents
	containing further relevant information.		containing further relevant information.
	General requirements for registered relation types are described in		General requirements for registered relation types are described in
	Section 3.		Section 3.
	Registrations MUST reference a freely available, stable
	specification.
	Note that well-known URIs can be registered by third parties		Note that well-known URIs can be registered by third parties
	(including the expert(s)), if the expert(s) determines that an		(including the expert(s)), if the expert(s) determines that an
	unregistered well-known URI is widely deployed and not likely to be		unregistered well-known URI is widely deployed and not likely to be
	registered in a timely manner otherwise. Such registrations still		registered in a timely manner otherwise. Such registrations still
	are subject to the requirements defined, including the need to		are subject to the requirements defined, including the need to
	reference a specification.		reference a specification.
	4. Security Considerations		4. Security Considerations
	Applications minting new well-known URIs, as well as administrators		Applications minting new well-known URIs, as well as administrators
	deploying them, will need to consider several security-related		deploying them, will need to consider several security-related
	issues, including (but not limited to) exposure of sensitive data,		issues, including (but not limited to) exposure of sensitive data,
	denial-of-service attacks (in addition to normal load issues), server		denial-of-service attacks (in addition to normal load issues), server
	and client authentication, vulnerability to DNS rebinding attacks,		and client authentication, vulnerability to DNS rebinding attacks,
	and attacks where limited access to a server grants the ability to		and attacks where limited access to a server grants the ability to
	affect how well-known URIs are served.		affect how well-known URIs are served.
	4.1. Interaction with the Web		4.1. Interaction with Web Browsing
	In particular, applications using well-known URIs for HTTP or HTTPS		Applications using well-known URIs for HTTP or HTTPS URLs need to be
	URLs need to be aware that well-known resources will be accessible to		aware that well-known resources will be accessible to Web browsers,
	Web browsers, and therefore is potentially able to be manipulated by		and therefore are able to be manipulated by content obtained from
	content obtained from other parts of that origin. If an attacker is		other parts of that origin. If an attacker is able to inject content
	able to inject content (e.g., through a Cross-Site Scripting		(e.g., through a Cross-Site Scripting vulnerability), they will be
	vulnerability), they will be able to make potentially arbitrary		able to make potentially arbitrary requests to the well-known
	requests to the well-known resource.		resource.
	HTTP and HTTPS also use origins as a security boundary for many other		HTTP and HTTPS also use origins as a security boundary for many other
	mechanisms, including (but not limited to) Cookies [RFC6265], Web		mechanisms, including (but not limited to) Cookies [RFC6265], Web
	Storage [W3C.REC-webstorage-20160419] and many capabilities.		Storage [WEBSTORAGE] and many capabilities.
	Applications defining well-known locations should not assume that		Applications defining well-known locations should not assume that
	they have sole access to these mechanisms.		they have sole access to these mechanisms, or that they are the only
			application using the origin. Depending on the nature of the
			application, mitigations can include:
	Applications defining well-known URIs should not assume or require		o Encrypting sensitive information
	that they are the only application using the origin, since this is a
	common deployment pattern; instead, they should use appropriate
	mechanisms to mitigate the risks of co-existing with Web
	applications, such as (but not limited to):
	o Using Strict Transport Security [RFC6797] to assure that HTTPS is		o Allowing flexibility in the use of identifiers (e.g., Cookie
	used		names) to avoid collisions with other applications
	o Using Content-Security-Policy [W3C.WD-CSP3-20160913] to constrain		o Using the 'HttpOnly' flag on Cookies to assure that cookies are
	the capabilities of content, thereby mitigating Cross-Site		not exposed to browser scripting languages [RFC6265]
	Scripting attacks (which are possible if client-provided data is
	exposed in any part of a response in the application)
	o Using X-Frame-Options [RFC7034] to prevent content from being		o Using the 'Path' parameter on Cookies to assure that they are not
	included in a HTML frame from another origin, thereby enabling		available to other parts of the origin [RFC6265]
	"clickjacking"
	o Using Referrer-Policy [W3C.CR-referrer-policy-20170126] to prevent		o Using X-Content-Type-Options: nosniff [FETCH] to assure that
	sensitive data in URLs from being leaked in the Referer request		content under attacker control can't be coaxed into a form that is
	header		interpreted as active content by a Web browser
	o Using the 'HttpOnly' flag on Cookies to assure that cookies are		Other good practices include:
	not exposed to browser scripting languages [RFC6265]
			o Using an application-specific media type in the Content-Type
			header, and requiring clients to fail if it is not used
			o Using Content-Security-Policy [CSP] to constrain the capabilities
			of active content (such as HTML [HTML5]), thereby mitigating
			Cross-Site Scripting attacks
			o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data
			in URLs from being leaked in the Referer request header
			o Avoiding use of compression on any sensitive information (e.g.,
			authentication tokens, passwords), as the scripting environment
			offered by Web browsers allows an attacker to repeatedly probe the
			compression space; if the attacker has access to the path of the
			communication, they can use this capability to recover that
			information.
	4.2. Scoping Applications		4.2. Scoping Applications
	This memo does not specify the scope of applicability of metadata or		This memo does not specify the scope of applicability for the
	policy obtained from a well-known URI, and does not specify how to		information obtained from a well-known URI, and does not specify how
	discover a well-known URI for a particular application.		to discover a well-known URI for a particular application.
	Individual applications using this mechanism must define both		Individual applications using this mechanism must define both
	aspects; if this is not specified, security issues can arise from		aspects; if this is not specified, security issues can arise from
	implementation deviations and confusion about boundaries between		implementation deviations and confusion about boundaries between
	applications.		applications.
	Applying metadata discovered in a well-known URI to resources other		Applying metadata discovered in a well-known URI to resources other
	than those co-located on the same origin risks administrative as well		than those co-located on the same origin risks administrative as well
	as security issues. For example, allowing		as security issues. For example, allowing
	"https://example.com/.well-known/example" to apply policy to		"https://example.com/.well-known/example" to apply policy to
	"https://department.example.com", "https://www.example.com" or even		"https://department.example.com", "https://www.example.com" or even
	"https://www.example.com:8000" assumes a relationship between hosts		"https://www.example.com:8000" assumes a relationship between hosts
	where there may be none, or there may be conflicting motivations.		where there might be none, giving control to a potential attacker.
			Likewise, specifying that a well-known URI on a particular hostname
			is to be used to bootstrap a protocol can cause a large number of
			undesired requests. For example, if a well-known HTTPS URI is used
			to find policy about a separate service such as e-mail, it can result
			in a flood of requests to Web servers, even if they don't implement
			the well-known URI. Such undesired requests can resemble a denial-
			of-services attack.
	4.3. Hidden Capabilities		4.3. Hidden Capabilities
	Applications using well-known locations should consider that some		Applications using well-known locations should consider that some
	server administrators might be unaware of its existence (especially		server administrators might be unaware of its existence (especially
	on operating systems that hide directories whose names begin with		on operating systems that hide directories whose names begin with
	"."). This means that if an attacker has write access to the .well-		"."). This means that if an attacker has write access to the .well-
	known directory, they would be able to control its contents, possibly		known directory, they would be able to control its contents, possibly
	without the administrator realising it.		without the administrator realising it.
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 47 ¶
	5.1. The Well-Known URI Registry		5.1. The Well-Known URI Registry
	This specification updates the registration procedures for the "Well-		This specification updates the registration procedures for the "Well-
	Known URI" registry, first defined in [RFC5785]; see Section 3.1.		Known URI" registry, first defined in [RFC5785]; see Section 3.1.
	Well-known URIs are registered on the advice of one or more experts		Well-known URIs are registered on the advice of one or more experts
	(appointed by the IESG or their delegate), with a Specification		(appointed by the IESG or their delegate), with a Specification
	Required (using terminology from [RFC8126]).		Required (using terminology from [RFC8126]).
	The Experts' primary considerations in evaluating registration		The Experts' primary considerations in evaluating registration
	requests are: * Conformance to the requirements in Section 3 * The		requests are:
	availability and stability of the specifying document * The security
	considerations outlined in Section 4		o Conformance to the requirements in Section 3
			o The availability and stability of the specifying document
			o The considerations outlined in Section 4
	IANA will direct any incoming requests regarding the registry to this		IANA will direct any incoming requests regarding the registry to this
	document and, if defined, the processes established by the expert(s);		document and, if defined, the processes established by the expert(s);
	typically, this will mean referring them to the registry Web page.		typically, this will mean referring them to the registry Web page.
	IANA should replace all references to RFC 5988 in that registry have		IANA should replace all references to RFC 5988 in that registry have
	been replaced with references to this document.		been replaced with references to this document.
	6. References		6. References
	skipping to change at page 8, line 16 ¶		skipping to change at page 8, line 38 ¶
	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>.
	[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
			[CSP] West, M., "Content Security Policy Level 3", World Wide
			Web Consortium WD WD-CSP3-20160913, September 2016,
			<https://www.w3.org/TR/2016/WD-CSP3-20160913>.
			[FETCH] WHATWG, "Fetch - Living Standard", n.d.,
			<https://fetch.spec.whatwg.org>.
			[HTML5] WHATWG, "HTML - Living Standard", n.d.,
			<https://html.spec.whatwg.org>.
			[P3P] Marchiori, M., "The Platform for Privacy Preferences 1.0
			(P3P1.0) Specification", World Wide Web Consortium
			Recommendation REC-P3P-20020416, April 2002,
			<http://www.w3.org/TR/2002/REC-P3P-20020416>.
			[REFERRER-POLICY]
			Eisinger, J. and E. Stark, "Referrer Policy", World Wide
			Web Consortium CR CR-referrer-policy-20170126, January
			2017,
			<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
	[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,
	<https://www.rfc-editor.org/info/rfc4918>.		<https://www.rfc-editor.org/info/rfc4918>.
	[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,
	DOI 10.17487/RFC5785, April 2010,		DOI 10.17487/RFC5785, April 2010,
	<https://www.rfc-editor.org/info/rfc5785>.		<https://www.rfc-editor.org/info/rfc5785>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
	Transport Security (HSTS)", RFC 6797,
	DOI 10.17487/RFC6797, November 2012,
	<https://www.rfc-editor.org/info/rfc6797>.
	[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
	Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
	<https://www.rfc-editor.org/info/rfc7034>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	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.CR-referrer-policy-20170126]		[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
	Eisinger, J. and E. Stark, "Referrer Policy", World Wide		RFC 7320, DOI 10.17487/RFC7320, July 2014,
	Web Consortium CR CR-referrer-policy-20170126, January		<https://www.rfc-editor.org/info/rfc7320>.
	2017,
	<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
	[W3C.REC-P3P-20020416]
	Marchiori, M., "The Platform for Privacy Preferences 1.0
	(P3P1.0) Specification", World Wide Web Consortium
	Recommendation REC-P3P-20020416, April 2002,
	<http://www.w3.org/TR/2002/REC-P3P-20020416>.
	[W3C.REC-webstorage-20160419]		[WEBSTORAGE]
	Hickson, I., "Web Storage (Second Edition)", World Wide		Hickson, I., "Web Storage (Second Edition)", World Wide
	Web Consortium Recommendation REC-webstorage-20160419,		Web Consortium Recommendation REC-webstorage-20160419,
	April 2016,		April 2016,
	<http://www.w3.org/TR/2016/REC-webstorage-20160419>.		<http://www.w3.org/TR/2016/REC-webstorage-20160419>.
	[W3C.WD-CSP3-20160913]
	West, M., "Content Security Policy Level 3", World Wide
	Web Consortium WD WD-CSP3-20160913, September 2016,
	<https://www.w3.org/TR/2016/WD-CSP3-20160913>.
	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/
	[5] http://www.robotstxt.org/		[5] http://www.robotstxt.org/
	Appendix A. Frequently Asked Questions		Appendix A. Frequently Asked Questions
	1. Aren't well-known locations bad for the Web?		Aren't well-known locations bad for the Web? They are, but for
			various reasons - both technical and social - they are sometimes
	They are, but for various reasons - both technical and social -		necessary. This memo defines a "sandbox" for them, to reduce the
	they are sometimes necessary. This memo defines a "sandbox" for		risks of collision and to minimise the impact upon pre-existing
	them, to reduce the risks of collision and to minimise the impact		URIs on sites.
	upon pre-existing URIs on sites.
	2. Why /.well-known?
	It's short, descriptive, and according to search indices, not
	widely used.
	3. What impact does this have on existing mechanisms, such as P3P
	and robots.txt?
	None, until they choose to use this mechanism.		Why /.well-known? It's short, descriptive, and according to search
			indices, not widely used.
	4. Why aren't per-directory well-known locations defined?		What impact does this have on existing mechanisms, such as P3P and
			robots.txt?
			None, until they choose to use this mechanism.
	Allowing every URI path segment to have a well-known location		Why aren't per-directory well-known locations defined? Allowing
	(e.g., "/images/.well-known/") would increase the risks of		every URI path segment to have a well-known location (e.g.,
	colliding with a pre-existing URI on a site, and generally these		"/images/.well-known/") would increase the risks of colliding with
	solutions are found not to scale well, because they're too		a pre-existing URI on a site, and generally these solutions are
	"chatty".		found not to scale well, because they're too "chatty".
	Appendix B. Changes from RFC5785		Appendix B. Changes from RFC5785
	o Allow non-Web well-known locations		o Allow non-Web well-known locations
	o Adjust IANA instructions		o Adjust IANA instructions
	o Update references		o Update references
	o Various other clarifications		o Various other clarifications
End of changes. 34 change blocks.
	104 lines changed or deleted		117 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/