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