idnits 2.17.00 (12 Aug 2021) /tmp/idnits49805/draft-nottingham-rfc5785bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5785, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2017) is 1649 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft November 13, 2017 4 Obsoletes: 5785 (if approved) 5 Intended status: Standards Track 6 Expires: May 17, 2018 8 Defining Well-Known Uniform Resource Identifiers (URIs) 9 draft-nottingham-rfc5785bis-01 11 Abstract 13 This memo defines a path prefix for "well-known locations", "/.well- 14 known/", in selected Uniform Resource Identifier (URI) schemes. 16 Note to Readers 18 _RFC EDITOR: please remove this section before publication_ 20 This draft is a proposed revision of RFC5875. 22 The issues list for this draft can be found at 23 https://github.com/mnot/I-D/labels/5785bis . 25 The most recent (often, unpublished) draft is at 26 https://mnot.github.io/I-D/5785bis/ . 28 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 29 pages/5785bis . 31 See also the draft's current status in the IETF datatracker, at 32 https://datatracker.ietf.org/doc/draft-nottingham-5785bis/ . 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 17, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Appropriate Use of Well-Known URIs . . . . . . . . . . . 3 69 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 70 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 5 74 5.1.1. Registration Template . . . . . . . . . . . . . . . . 5 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 77 6.2. Informative References . . . . . . . . . . . . . . . . . 6 78 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 6 79 Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 7 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 Some applications on the Web require the discovery of policy or other 85 information about an origin [RFC6454] (sometimes called "site-wide 86 metadata") before making a request. For example, the Robots 87 Exclusion Protocol (http://www.robotstxt.org/ ) specifies a way for 88 automated processes to obtain permission to access resources; 89 likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416] 90 tells user-agents how to discover privacy policy before interacting 91 with a site. 93 While there are several ways to access per-resource metadata (e.g., 94 HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead 95 (either in terms of client-perceived latency and/or deployment 96 difficulties) associated with them often precludes their use in these 97 scenarios. 99 When this happens, one solution is designating a "well-known 100 location" for data or services related to the origin, so that it can 101 be easily located. However, this approach has the drawback of 102 risking collisions, both with other such designated "well-known 103 locations" and with pre-existing resources. 105 To address this, this memo defines a path prefix in HTTP(S) URIs for 106 these "well-known locations", "/.well-known/". Future specifications 107 that need to define a resource for such site-wide metadata can 108 register their use to avoid collisions and minimise impingement upon 109 sites' URI space. 111 Well-known URIs can also be used with other URI schemes, but only 112 when those schemes' definitions explicitly allow it. 114 1.1. Appropriate Use of Well-Known URIs 116 There are a number of possible ways that applications could use well- 117 known URIs. However, in keeping with the Architecture of the World- 118 Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended 119 for general information retrieval or establishment of large URI 120 namespaces on the Web. Rather, they are designed to facilitate 121 discovery of information on a site when it isn't practical to use 122 other mechanisms; for example, when discovering policy that needs to 123 be evaluated before a resource is accessed, or when using multiple 124 round-trips is judged detrimental to performance. 126 As such, the well-known URI space was created with the expectation 127 that it will be used to make policy information and other metadata 128 about the origin available directly (if sufficiently concise), or 129 provide references to other URIs that provide it. 131 Therefore, it is inappropriate to use well-known URIs as a means of 132 identifying or locating a new protocol built on top of HTTP, since 133 they are intended for metadata about their origin. 135 In particular, locating information using a hostname instead of a URI 136 is, on its own, insufficient reason to register a well-known URI. 138 2. Notational Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 3. Well-Known URIs 146 A well-known URI is a URI [RFC3986] whose path component begins with 147 the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS", 148 or another scheme that has explicitly been specified to use well- 149 known URIs. 151 Applications that wish to mint new well-known URIs MUST register 152 them, following the procedures in Section 5.1. 154 For example, if an application registers the name 'example', the 155 corresponding well-known URI on 'http://www.example.com/' would be 156 'http://www.example.com/.well-known/example'. 158 Registered names MUST conform to the segment-nz production in 159 [RFC3986]. This means they cannot contain the "/" character. 161 Note that this specification defines neither how to determine the 162 authority to use for a particular context, nor the scope of the 163 metadata discovered by dereferencing the well-known URI; both should 164 be defined by the application itself. 166 Typically, a registration will reference a specification that defines 167 the format and associated media type to be obtained by dereferencing 168 the well-known URI. 170 It MAY also contain additional information, such as the syntax of 171 additional path components, query strings and/or fragment identifiers 172 to be appended to the well-known URI, or protocol-specific details 173 (e.g., HTTP [RFC7231] method handling). 175 Note that this specification does not define a format or media-type 176 for the resource located at "/.well-known/" and clients should not 177 expect a resource to exist at that location. 179 4. Security Considerations 181 This memo does not specify the scope of applicability of metadata or 182 policy obtained from a well-known URI, and does not specify how to 183 discover a well-known URI for a particular application. Individual 184 applications using this mechanism must define both aspects. 186 Applications minting new well-known URIs, as well as administrators 187 deploying them, will need to consider several security-related 188 issues, including (but not limited to) exposure of sensitive data, 189 denial-of-service attacks (in addition to normal load issues), server 190 and client authentication, vulnerability to DNS rebinding attacks, 191 and attacks where limited access to a server grants the ability to 192 affect how well-known URIs are served. 194 5. IANA Considerations 196 5.1. The Well-Known URI Registry 198 This document specifies procedures for the well-known URI registry, 199 first defined in [RFC5785]. 201 Well-known URIs are registered on the advice of one or more experts 202 (appointed by the IESG or their delegate), with a Specification 203 Required (using terminology from [RFC8126]). However, to allow for 204 the allocation of values prior to publication, the expert(s) may 205 approve registration once they are satisfied that such a 206 specification will be published. 208 Registration requests can be sent to the wellknown-uri- 209 review@ietf.org mailing list for review and comment, with an 210 appropriate subject (e.g., "Request for well-known URI: example"). 212 5.1.1. Registration Template 214 URI suffix: The name requested for the well-known URI, relative to 215 "/.well-known/"; e.g., "example". 217 Change controller: For Standards-Track RFCs, state "IETF". For 218 others, give the name of the responsible party. Other details 219 (e.g., postal address, e-mail address, home page URI) may also be 220 included. 222 Specification document(s): Reference to the document that specifies 223 the field, preferably including a URI that can be used to retrieve 224 a copy of the document. An indication of the relevant sections 225 may also be included, but is not required. 227 Related information: Optionally, citations to additional documents 228 containing further relevant information. 230 6. References 232 6.1. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 236 RFC2119, March 1997, . 239 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 240 Resource Identifier (URI): Generic Syntax", STD 66, RFC 241 3986, DOI 10.17487/RFC3986, January 2005, 242 . 244 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 245 10.17487/RFC6454, December 2011, . 248 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 249 Writing an IANA Considerations Section in RFCs", BCP 26, 250 RFC 8126, DOI 10.17487/RFC8126, June 2017, 251 . 253 6.2. Informative References 255 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 256 Authoring and Versioning (WebDAV)", RFC 4918, DOI 257 10.17487/RFC4918, June 2007, . 260 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 261 Uniform Resource Identifiers (URIs)", RFC 5785, DOI 262 10.17487/RFC5785, April 2010, . 265 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 266 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 267 10.17487/RFC7231, June 2014, . 270 [W3C.REC-P3P-20020416] 271 Marchiori, M., "The Platform for Privacy Preferences 1.0 272 (P3P1.0) Specification", World Wide Web Consortium 273 Recommendation REC-P3P-20020416, April 2002, 274 . 276 Appendix A. Frequently Asked Questions 278 1. Aren't well-known locations bad for the Web? 280 They are, but for various reasons - both technical and social - 281 they are sometimes necessary. This memo defines a "sandbox" for 282 them, to reduce the risks of collision and to minimise the impact 283 upon pre-existing URIs on sites. 285 2. Why /.well-known? 286 It's short, descriptive, and according to search indices, not 287 widely used. 289 3. What impact does this have on existing mechanisms, such as P3P 290 and robots.txt? 292 None, until they choose to use this mechanism. 294 4. Why aren't per-directory well-known locations defined? 296 Allowing every URI path segment to have a well-known location 297 (e.g., "/images/.well-known/") would increase the risks of 298 colliding with a pre-existing URI on a site, and generally these 299 solutions are found not to scale well, because they're too 300 "chatty". 302 Appendix B. Changes from RFC5785 304 o Discuss inappropriate uses more fully 306 o Adjusted IANA instructions 308 o Updated references 310 o Various other clarifications 312 Author's Address 314 Mark Nottingham 316 Email: mnot@mnot.net 317 URI: https://www.mnot.net/