Well-Known Uniform Resource Identifiers (URIs)
RFC 8615
Document | Type |
RFC - Proposed Standard
(May 2019; No errata)
Obsoletes RFC 5785
Was draft-nottingham-rfc5785bis (individual in art area)
|
|
---|---|---|---|
Author | Mark Nottingham | ||
Last updated | 2019-05-20 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | Martin Thomson | ||
Shepherd write-up | Show (last changed 2018-09-05) | ||
IESG | IESG state | RFC 8615 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Alexey Melnikov | ||
Send notices to | Martin Thomson <martin.thomson@gmail.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
Internet Engineering Task Force (IETF) M. Nottingham Request for Comments: 8615 May 2019 Obsoletes: 5785 Updates: 7230, 7595 Category: Standards Track ISSN: 2070-1721 Well-Known Uniform Resource Identifiers (URIs) Abstract This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8615. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Nottingham Standards Track [Page 1] RFC 8615 Well-Known URIs May 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Registering Well-Known URIs . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4.1. Protecting Well-Known Resources . . . . . . . . . . . . . 6 4.2. Interaction with Web Browsing . . . . . . . . . . . . . . 6 4.3. Scoping Applications . . . . . . . . . . . . . . . . . . 7 4.4. Hidden Capabilities . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 8 5.2. The Uniform Resource Identifier (URI) Schemes Registry . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 12 Appendix B. Changes from RFC 5785 . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Some applications on the Web require the discovery of information about an origin [RFC6454] (sometimes called "site-wide metadata") before making a request. For example, the Robots Exclusion Protocol (http://www.robotstxt.org) specifies a way for automated processes to obtain permission to access resources; likewise, the Platform for Privacy Preferences [P3P] tells user agents how to discover privacy policy before interacting with an origin server. While there are several ways to access per-resource metadata (e.g., HTTP header fields, PROPFIND in Web Distributed Authoring and Versioning (WebDAV) [RFC4918]), the perceived overhead (either in terms of client-perceived latency and/or deployment difficulties) associated with them often precludes their use in these 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 to designate a "well-known location" for data or services related to the origin overall, so that it can be easily located. However, this approach has the drawback of risking collisions, both with other such designated "well-known locations" and with resources that the origin has created (or wishes to create). Furthermore, defining well-known locations usurps the origin's control over its own URI space [RFC7320]. Nottingham Standards Track [Page 2]Show full document text