idnits 2.17.1 draft-nottingham-rfc5785bis-00.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 2355 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 normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 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-00 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. Version -00 is a copy 21 of the original RFC. 23 The issues list for this draft can be found at 24 https://github.com/mnot/I-D/labels/5785bis . 26 The most recent (often, unpublished) draft is at 27 https://mnot.github.io/I-D/5785bis/ . 29 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 30 pages/5785bis . 32 See also the draft's current status in the IETF datatracker, at 33 https://datatracker.ietf.org/doc/draft-nottingham-5785bis/ . 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 17, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Appropriate Use of Well-Known URIs . . . . . . . . . . . 3 70 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 71 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 3 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 74 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 4 75 5.1.1. Registration Template . . . . . . . . . . . . . . . . 5 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 78 6.2. Informative References . . . . . . . . . . . . . . . . . 6 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 80 Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 6 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 It is increasingly common for Web-based protocols to require the 86 discovery of policy or other information about a host ("site-wide 87 metadata") before making a request. For example, the Robots 88 Exclusion Protocol (http://www.robotstxt.org/ ) specifies a way for 89 automated processes to obtain permission to access resources; 90 likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416] 91 tells user-agents how to discover privacy policy beforehand. 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, it is common to designate a "well-known location" 100 for such data, so that it can be easily located. However, this 101 approach has the drawback of risking collisions, both with other such 102 designated "well-known locations" and with pre-existing resources. 104 To address this, this memo defines a path prefix in HTTP(S) URIs for 105 these "well-known locations", "/.well-known/". Future specifications 106 that need to define a resource for such site-wide metadata can 107 register their use to avoid collisions and minimise impingement upon 108 sites' URI space. 110 1.1. Appropriate Use of Well-Known URIs 112 There are a number of possible ways that applications could use Well- 113 known URIs. However, in keeping with the Architecture of the World- 114 Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended 115 for general information retrieval or establishment of large URI 116 namespaces on the Web. Rather, they are designed to facilitate 117 discovery of information on a site when it isn't practical to use 118 other mechanisms; for example, when discovering policy that needs to 119 be evaluated before a resource is accessed, or when using multiple 120 round-trips is judged detrimental to performance. 122 As such, the well-known URI space was created with the expectation 123 that it will be used to make site-wide policy information and other 124 metadata available directly (if sufficiently concise), or provide 125 references to other URIs that provide such metadata. 127 2. Notational Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 3. Well-Known URIs 135 A well-known URI is a URI [RFC3986] whose path component begins with 136 the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS", 137 or another scheme that has explicitly been specified to use well- 138 known URIs. 140 Applications that wish to mint new well-known URIs MUST register 141 them, following the procedures in Section 5.1. 143 For example, if an application registers the name 'example', the 144 corresponding well-known URI on 'http://www.example.com/' would be 145 'http://www.example.com/.well-known/example'. 147 Registered names MUST conform to the segment-nz production in 148 [RFC3986]. 150 Note that this specification defines neither how to determine the 151 authority to use for a particular context, nor the scope of the 152 metadata discovered by dereferencing the well-known URI; both should 153 be defined by the application itself. 155 Typically, a registration will reference a specification that defines 156 the format and associated media type to be obtained by dereferencing 157 the well-known URI. 159 It MAY also contain additional information, such as the syntax of 160 additional path components, query strings and/or fragment identifiers 161 to be appended to the well-known URI, or protocol-specific details 162 (e.g., HTTP [RFC2616] method handling). 164 Note that this specification does not define a format or media-type 165 for the resource located at "/.well-known/" and clients should not 166 expect a resource to exist at that location. 168 4. Security Considerations 170 This memo does not specify the scope of applicability of metadata or 171 policy obtained from a well-known URI, and does not specify how to 172 discover a well-known URI for a particular application. Individual 173 applications using this mechanism must define both aspects. 175 Applications minting new well-known URIs, as well as administrators 176 deploying them, will need to consider several security-related 177 issues, including (but not limited to) exposure of sensitive data, 178 denial-of-service attacks (in addition to normal load issues), server 179 and client authentication, vulnerability to DNS rebinding attacks, 180 and attacks where limited access to a server grants the ability to 181 affect how well-known URIs are served. 183 5. IANA Considerations 185 5.1. The Well-Known URI Registry 187 This document establishes the well-known URI registry. 189 Well-known URIs are registered on the advice of one or more 190 Designated Experts (appointed by the IESG or their delegate), with a 191 Specification Required (using terminology from [RFC5226]). However, 192 to allow for the allocation of values prior to publication, the 193 Designated Expert(s) may approve registration once they are satisfied 194 that such a specification will be published. 196 Registration requests should be sent to the wellknown-uri- 197 review@ietf.org mailing list for review and comment, with an 198 appropriate subject (e.g., "Request for well-known URI: example"). 200 Before a period of 14 days has passed, the Designated Expert(s) will 201 either approve or deny the registration request, communicating this 202 decision both to the review list and to IANA. Denials should include 203 an explanation and, if applicable, suggestions as to how to make the 205 request successful. Registration requests that are undetermined for 206 a period longer than 21 days can be brought to the IESG's attention 207 (using the iesg@iesg.org mailing list) for resolution. 209 5.1.1. Registration Template 211 URI suffix: The name requested for the well-known URI, relative to 212 "/.well-known/"; e.g., "example". 214 Change controller: For Standards-Track RFCs, state "IETF". For 215 others, give the name of the responsible party. Other details 216 (e.g., postal address, e-mail address, home page URI) may also be 217 included. 219 Specification document(s): Reference to the document that specifies 220 the field, preferably including a URI that can be used to retrieve 221 a copy of the document. An indication of the relevant sections 222 may also be included, but is not required. 224 Related information: Optionally, citations to additional documents 225 containing further relevant information. 227 6. References 229 6.1. Normative References 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 233 RFC2119, March 1997, . 236 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 237 Resource Identifier (URI): Generic Syntax", STD 66, RFC 238 3986, DOI 10.17487/RFC3986, January 2005, 239 . 241 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 242 IANA Considerations Section in RFCs", RFC 5226, DOI 243 10.17487/RFC5226, May 2008, . 246 6.2. Informative References 248 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 249 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 250 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 251 RFC2616, June 1999, . 254 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 255 Authoring and Versioning (WebDAV)", RFC 4918, DOI 256 10.17487/RFC4918, June 2007, . 259 [W3C.REC-P3P-20020416] 260 Marchiori, M., "The Platform for Privacy Preferences 1.0 261 (P3P1.0) Specification", World Wide Web Consortium 262 Recommendation REC-P3P-20020416, April 2002, 263 . 265 Appendix A. Acknowledgements 267 We would like to acknowledge the contributions of everyone who 268 provided feedback and use cases for this document; in particular, 269 Phil Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad 270 Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra, 271 Breno de Medeiros, John Panzer, and Drummond Reed. However, they are 272 not responsible for errors and omissions. 274 Appendix B. Frequently Asked Questions 276 1. Aren't well-known locations bad for the Web? 278 They are, but for various reasons - both technical and social - 279 they are commonly used and their use is increasing. This memo 280 defines a "sandbox" for them, to reduce the risks of collision 281 and to minimise the impact upon pre-existing URIs on sites. 283 2. Why /.well-known? 284 It's short, descriptive, and according to search indices, not 285 widely used. 287 3. What impact does this have on existing mechanisms, such as P3P 288 and robots.txt? 290 None, until they choose to use this mechanism. 292 4. Why aren't per-directory well-known locations defined? 294 Allowing every URI path segment to have a well-known location 295 (e.g., "/images/.well-known/") would increase the risks of 296 colliding with a pre-existing URI on a site, and generally these 297 solutions are found not to scale well, because they're too 298 "chatty". 300 Author's Address 302 Mark Nottingham 304 Email: mnot@mnot.net 305 URI: https://www.mnot.net/