< draft-nottingham-rfc5785bis-08.txt   draft-nottingham-rfc5785bis-09.txt >
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft October 4, 2018 Internet-Draft February 26, 2019
Obsoletes: 5785, 8307 (if approved) Obsoletes: 5785, 8307 (if approved)
Updates: 7230, 6455 (if approved) Updates: 7230, 6455 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 7, 2019 Expires: August 30, 2019
Well-Known Uniform Resource Identifiers (URIs) Well-Known Uniform Resource Identifiers (URIs)
draft-nottingham-rfc5785bis-08 draft-nottingham-rfc5785bis-09
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.
In doing so, it obsoletes RFC 5785 and RFC 8307, and updates the URI
schemes defined in RFC 7230 and RFC 6455 to reserve that space.
Note to Readers Note to Readers
_RFC EDITOR: please remove this section before publication_ _RFC EDITOR: please remove this section before publication_
This draft is a proposed revision of RFC5875. This draft is a proposed revision of RFC5875.
The issues list for this draft can be found at The issues list for this draft can be found at
https://github.com/mnot/I-D/labels/rfc5785bis [1]. https://github.com/mnot/I-D/labels/rfc5785bis [1].
The most recent (often, unpublished) draft is at The most recent (often, unpublished) draft is at
skipping to change at page 2, line 4 skipping to change at page 2, line 9
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 April 7, 2019.
This Internet-Draft will expire on August 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4.1. Interaction with Web Browsing . . . . . . . . . . . . . . 6 4.1. Interaction with Web Browsing . . . . . . . . . . . . . . 6
4.2. Scoping Applications . . . . . . . . . . . . . . . . . . 7 4.2. Scoping Applications . . . . . . . . . . . . . . . . . . 7
4.3. Hidden Capabilities . . . . . . . . . . . . . . . . . . . 7 4.3. Hidden Capabilities . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 8 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9
6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 10 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 11
Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 11 Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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 [P3P] tells user-agents how to Platform for Privacy Preferences [P3P] tells user-agents how to
discover privacy policy before interacting with an origin server. discover privacy policy before interacting with an 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 header fields, WebDAV's PROPFIND [RFC4918]), the perceived
(either in terms of client-perceived latency and/or deployment overhead (either in terms of client-perceived latency and/or
difficulties) associated with them often precludes their use in these deployment difficulties) associated with them often precludes their
scenarios. use in these scenarios.
At the same time, it has become more popular to use HTTP as a At the same time, it has become more popular to use HTTP as a
substrate for non-Web protocols. Sometimes, such protocols need a substrate for non-Web protocols. Sometimes, such protocols need a
way to locate one or more resources on a given host. way to locate one or more resources on a given host.
When this happens, one solution is to designate a "well-known When this happens, one solution is to designate 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
skipping to change at page 3, line 35 skipping to change at page 3, line 38
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.
2. Notational Conventions 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Well-Known URIs 3. Well-Known URIs
A well-known URI is a URI [RFC3986] whose path component begins with A well-known URI is a URI [RFC3986] whose path component begins with
the characters "/.well-known/", and whose scheme is "http" [RFC7230], the characters "/.well-known/", and whose scheme is "http" [RFC7230],
"https" [RFC7230], "ws" [RFC6455], "wss" [RFC6455], or another scheme "https" [RFC7230], "ws" [RFC6455], "wss" [RFC6455], or another scheme
that has explicitly been specified to use well-known URIs. that has explicitly been specified to use well-known URIs.
Applications that wish to mint new well-known URIs MUST register
them, following the procedures in Section 5.1.
For example, if an application registers the name 'example', the For example, if an application registers the name 'example', the
corresponding well-known URI on 'http://www.example.com/' would be corresponding well-known URI on 'http://www.example.com/' would be
'http://www.example.com/.well-known/example'. 'http://www.example.com/.well-known/example'.
Applications that wish to mint new well-known URIs MUST register
them, following the procedures in Section 5.1, subject to the
following requirements.
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(s) 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.
Typically, applications will use the default port for the given Typically, applications will use the default port for the given
scheme; if an alternative port is used, it MUST be explicitly scheme; if an alternative port is used, it MUST be explicitly
specified by the application in question. specified by the application in question.
It MAY also contain additional information, such as the syntax of Registrations MAY also contain additional information, such as the
additional path components, query strings and/or fragment identifiers syntax of additional path components, query strings and/or fragment
to be appended to the well-known URI, or protocol-specific details identifiers to be appended to the well-known URI, or protocol-
(e.g., HTTP [RFC7231] method handling). specific details (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
hostname to use to find the well-known URI for a particular hostname to use to find the well-known URI for a particular
application, nor the scope of the metadata discovered by application, nor the scope of the metadata discovered by
dereferencing the well-known URI; both should be defined by the dereferencing the well-known URI; both should be defined by the
application itself. application itself.
Also, this specification does not define a format or media-type for Also, this specification does not define a format or media-type for
the resource located at "/.well-known/" and clients should not expect the resource located at "/.well-known/" and clients should not expect
a resource to exist at that location. a resource to exist at that location.
skipping to change at page 5, line 14 skipping to change at page 5, line 23
by sending an email to the "wellknown-uri-review@ietf.org" mailing by sending an email to the "wellknown-uri-review@ietf.org" mailing
list. list.
Registration requests consist of at least the following information: Registration requests consist of at least the following information:
URI suffix: The name requested for the well-known URI, relative to URI suffix: The name requested for the well-known URI, relative to
"/.well-known/"; e.g., "example". "/.well-known/"; e.g., "example".
Change controller: For Standards-Track RFCs, state "IETF". For Change controller: For Standards-Track RFCs, state "IETF". For
others, give the name of the responsible party. Other details others, give the name of the responsible party. Other details
(e.g., postal address, e-mail address, home page URI) may also be (e.g., e-mail address, home page URI) may also be included.
included.
Specification document(s): Reference to the document that specifies Specification document(s): Reference to the document that specifies
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.
Status: One of "permanent" or "provisional". See guidance below. Status: One of "permanent" or "provisional". See guidance below.
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 values are described in
Section 3. Section 3.
Standards-defined values have a status of "permanent". Other values Values defined by standards-track RFCs and other open standards (in
can also be registered as permanent, if the Experts find that they the sense of [RFC2026], Section 7.1.1) have a status of "permanent".
are in use, in consultation with the community. Other values should Other values can also be registered as permanent, if the Experts find
be registered as "provisional". that they are in use, in consultation with the community. Other
values should be registered as "provisional".
Provisional entries can be removed by the Experts if - in Provisional entries can be removed by the Experts if - in
consultation with the community - the Experts find that they are not consultation with the community - the Experts find that they are not
in use. The Experts can change a provisional entry's status to in use. The Experts can change a provisional entry's status to
permanent at any time. permanent at any time.
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
skipping to change at page 6, line 46 skipping to change at page 7, line 6
o Using the 'Path' parameter on Cookies to assure that they are not o Using the 'Path' parameter on Cookies to assure that they are not
available to other parts of the origin [RFC6265] available to other parts of the origin [RFC6265]
o Using X-Content-Type-Options: nosniff [FETCH] to assure that o Using X-Content-Type-Options: nosniff [FETCH] to assure that
content under attacker control can't be coaxed into a form that is content under attacker control can't be coaxed into a form that is
interpreted as active content by a Web browser interpreted as active content by a Web browser
Other good practices include: Other good practices include:
o Using an application-specific media type in the Content-Type o Using an application-specific media type in the Content-Type
header, and requiring clients to fail if it is not used header field, and requiring clients to fail if it is not used
o Using Content-Security-Policy [CSP] to constrain the capabilities o Using Content-Security-Policy [CSP] to constrain the capabilities
of active content (such as HTML [HTML5]), thereby mitigating of active content (such as HTML [HTML5]), thereby mitigating
Cross-Site Scripting attacks Cross-Site Scripting attacks
o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data
in URLs from being leaked in the Referer request header in URLs from being leaked in the Referer request header field
o Avoiding use of compression on any sensitive information (e.g., o Avoiding use of compression on any sensitive information (e.g.,
authentication tokens, passwords), as the scripting environment authentication tokens, passwords), as the scripting environment
offered by Web browsers allows an attacker to repeatedly probe the offered by Web browsers allows an attacker to repeatedly probe the
compression space; if the attacker has access to the path of the compression space; if the attacker has access to the path of the
communication, they can use this capability to recover that communication, they can use this capability to recover that
information. information.
4.2. Scoping Applications 4.2. Scoping Applications
skipping to change at page 8, line 12 skipping to change at page 8, line 21
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.
5. IANA Considerations 5. IANA Considerations
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 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: requests are:
o Conformance to the requirements in Section 3 o Conformance to the requirements in Section 3
o The availability and stability of the specifying document o The availability and stability of the specifying document
o The considerations outlined in Section 4 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.
Upon publication, IANA should: Upon publication, IANA should:
o Replace all references to RFC 5988 in that registry have been
replaced with references to this document.
o Update the status of all existing registrations to "permanent". o Update the status of all existing registrations to "permanent".
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 9, line 19 skipping to change at page 9, line 28
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References 6.2. Informative References
[CSP] West, M., "Content Security Policy Level 3", World Wide [CSP] West, M., "Content Security Policy Level 3", World Wide
Web Consortium WD WD-CSP3-20160913, September 2016, Web Consortium WD WD-CSP3-20160913, September 2016,
<https://www.w3.org/TR/2016/WD-CSP3-20160913>. <https://www.w3.org/TR/2016/WD-CSP3-20160913>.
[FETCH] WHATWG, "Fetch - Living Standard", n.d., [FETCH] WHATWG, "Fetch - Living Standard", n.d.,
<https://fetch.spec.whatwg.org>. <https://fetch.spec.whatwg.org>.
[HTML5] WHATWG, "HTML - Living Standard", n.d., [HTML5] WHATWG, "HTML - Living Standard", n.d.,
skipping to change at page 9, line 42 skipping to change at page 10, line 11
(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>.
[REFERRER-POLICY] [REFERRER-POLICY]
Eisinger, J. and E. Stark, "Referrer Policy", World Wide Eisinger, J. and E. Stark, "Referrer Policy", World Wide
Web Consortium CR CR-referrer-policy-20170126, January Web Consortium CR CR-referrer-policy-20170126, January
2017, 2017,
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>. <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
[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>.
 End of changes. 23 change blocks. 
37 lines changed or deleted 48 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/