idnits 2.17.1 draft-nottingham-rfc5785bis-04.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 abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC5785, but the abstract doesn't seem to directly say this. It does mention RFC5785 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2018) is 2260 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) -- Looks like a reference, but probably isn't: '1' on line 333 -- Looks like a reference, but probably isn't: '2' on line 335 -- Looks like a reference, but probably isn't: '3' on line 337 -- Looks like a reference, but probably isn't: '4' on line 339 -- Looks like a reference, but probably isn't: '5' on line 341 ** Obsolete normative reference: RFC 5741 (Obsoleted by RFC 7841) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft February 15, 2018 4 Obsoletes: 5785 (if approved) 5 Intended status: Standards Track 6 Expires: August 19, 2018 8 Defining Well-Known Uniform Resource Identifiers (URIs) 9 draft-nottingham-rfc5785bis-04 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/rfc5785bis [1]. 25 The most recent (often, unpublished) draft is at 26 https://mnot.github.io/I-D/rfc5785bis/ [2]. 28 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 29 pages/rfc5785bis [3]. 31 See also the draft's current status in the IETF datatracker, at 32 https://datatracker.ietf.org/doc/draft-nottingham-rfc5785bis/ [4]. 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 https://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 August 19, 2018. 50 Copyright Notice 52 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . 4 70 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 5 74 5.1.1. Registration Template . . . . . . . . . . . . . . . . 6 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 6.2. Informative References . . . . . . . . . . . . . . . . . 7 78 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 8 80 Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 8 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 Some applications on the Web require the discovery of information 86 about an origin [RFC6454] (sometimes called "site-wide metadata") 87 before making a request. For example, the Robots Exclusion Protocol 88 (http://www.robotstxt.org/ [5]) specifies a way for automated 89 processes to obtain permission to access resources; likewise, the 90 Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user- 91 agents how to discover privacy policy before interacting with an 92 origin server. 94 While there are several ways to access per-resource metadata (e.g., 95 HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead 96 (either in terms of client-perceived latency and/or deployment 97 difficulties) associated with them often precludes their use in these 98 scenarios. 100 When this happens, one solution is designating a "well-known 101 location" for data or services related to the origin overall, so that 102 it can be easily located. However, this approach has the drawback of 103 risking collisions, both with other such designated "well-known 104 locations" and with resources that the origin has created (or wishes 105 to create). 107 To address this, this memo defines a path prefix in HTTP(S) URIs for 108 these "well-known locations", "/.well-known/". Future specifications 109 that need to define a resource for such metadata can register their 110 use to avoid collisions and minimise impingement upon origins' URI 111 space. 113 Well-known URIs can also be used with other URI schemes, but only 114 when those schemes' definitions explicitly allow it. 116 1.1. Appropriate Use of Well-Known URIs 118 As per [RFC7320], "publishing independent standards that mandate 119 particular forms of URI substructure is inappropriate, because that 120 essentially usurps ownership." Well-known URIs are not an escape 121 hatch from the requirements therein; they are a very limited carve- 122 out of the path name space owned by the authority, ceded to standard 123 use for a designated purpose. 125 That purpose is to facilitate discovery of information about an 126 origin when it isn't practical to use other mechanisms; for example, 127 when discovering policy that needs to be evaluated before a resource 128 is accessed, or when the information applies to many (or all) of the 129 origin's resources. 131 Typically, the resource(s) identified by a well-known URI will make 132 information about the origin (e.g., policy) available directly, or 133 provide references to other URIs that provide it. In general, that 134 information should be applicable to most origins (i.e., Web sites - 135 while acknowledging that some origins might not use a particular 136 well-known location, for various reasons). 138 In keeping with the Architecture of the World-Wide Web 139 [W3C.REC-webarch-20041215], well-known URIs are not intended for 140 general information retrieval or establishment of large URI 141 namespaces. 143 Specifically, well-known URIs are not a "protocol registry" for 144 applications and protocols that wish to use HTTP as a substrate. 145 Instead, such applications and protocols are encouraged to used an 146 absolute URI to bootstrap their operation, rather than using a 147 hostname and a well-known URI. 149 Exceptionally, the registry expert(s) may approve such a registration 150 for documents in the IETF Stream [RFC5741], in consultation with the 151 IESG, provided that the protocol in question cannot be bootstrapped 152 with a URI (e.g., the discovery mechanism can only carry a hostname). 153 However, merely making it easier to locate it is not a sufficient 154 reason. Likewise, future use unsupported by the specification in 155 question is not sufficient reason to register a well-known location. 157 Well-known locations are also not suited for information on topics 158 other than the origin that they are located upon; for example, 159 creating a well-known resource about a business entity or 160 organisational structure presumes that Internet hosts and 161 organisations share structure, and are likely to have significant 162 deployment issues in environments where this is not true. 164 2. Notational Conventions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 3. Well-Known URIs 172 A well-known URI is a URI [RFC3986] whose path component begins with 173 the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS", 174 or another scheme that has explicitly been specified to use well- 175 known URIs. 177 Applications that wish to mint new well-known URIs MUST register 178 them, following the procedures in Section 5.1. 180 For example, if an application registers the name 'example', the 181 corresponding well-known URI on 'http://www.example.com/' would be 182 'http://www.example.com/.well-known/example'. 184 Registered names MUST conform to the segment-nz production in 185 [RFC3986]. This means they cannot contain the "/" character. 187 Note that this specification defines neither how to determine the 188 authority to use for a particular context, nor the scope of the 189 metadata discovered by dereferencing the well-known URI; both should 190 be defined by the application itself. 192 Typically, a registration will reference a specification that defines 193 the format and associated media type to be obtained by dereferencing 194 the well-known URI. 196 It MAY also contain additional information, such as the syntax of 197 additional path components, query strings and/or fragment identifiers 198 to be appended to the well-known URI, or protocol-specific details 199 (e.g., HTTP [RFC7231] method handling). 201 Note that this specification does not define a format or media-type 202 for the resource located at "/.well-known/" and clients should not 203 expect a resource to exist at that location. 205 Well-known URIs are only valid when rooted in the top of the path's 206 hierarchy; they MUST NOT be used in other parts of the path. For 207 example, "/.well-known/example" is a valid use, but "/foo/.well- 208 known/example" is not. 210 4. Security Considerations 212 This memo does not specify the scope of applicability of metadata or 213 policy obtained from a well-known URI, and does not specify how to 214 discover a well-known URI for a particular application. Individual 215 applications using this mechanism must define both aspects. 217 Applications minting new well-known URIs, as well as administrators 218 deploying them, will need to consider several security-related 219 issues, including (but not limited to) exposure of sensitive data, 220 denial-of-service attacks (in addition to normal load issues), server 221 and client authentication, vulnerability to DNS rebinding attacks, 222 and attacks where limited access to a server grants the ability to 223 affect how well-known URIs are served. 225 Security-sensitive applications using well-known locations should 226 consider that some server administrators might be unaware of its 227 existence (especially on operating systems that hide directories 228 whose names begin with "."). This means that if an attacker has 229 write access to the .well-known directory, they would be able to 230 control its contents, possibly without the administrator realising 231 it. 233 5. IANA Considerations 235 5.1. The Well-Known URI Registry 237 This document specifies procedures for the well-known URI registry, 238 first defined in [RFC5785]. 240 Well-known URIs are registered on the advice of one or more experts 241 (appointed by the IESG or their delegate), with a Specification 242 Required (using terminology from [RFC8126]). 244 To allow for the allocation of values prior to publication, the 245 expert(s) may approve registration once they are satisfied that such 246 a specification will be published. 248 Registration requests can be sent to the wellknown-uri- 249 review@ietf.org mailing list for review and comment, with an 250 appropriate subject (e.g., "Request for well-known URI: example"). 252 5.1.1. Registration Template 254 URI suffix: The name requested for the well-known URI, relative to 255 "/.well-known/"; e.g., "example". 257 Change controller: For Standards-Track RFCs, state "IETF". For 258 others, give the name of the responsible party. Other details 259 (e.g., postal address, e-mail address, home page URI) may also be 260 included. 262 Specification document(s): Reference to the document that specifies 263 the field, preferably including a URI that can be used to retrieve 264 a copy of the document. An indication of the relevant sections 265 may also be included, but is not required. 267 Related information: Optionally, citations to additional documents 268 containing further relevant information. 270 6. References 272 6.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 280 Resource Identifier (URI): Generic Syntax", STD 66, 281 RFC 3986, DOI 10.17487/RFC3986, January 2005, 282 . 284 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 285 Headers, and Boilerplates", RFC 5741, 286 DOI 10.17487/RFC5741, December 2009, 287 . 289 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 290 DOI 10.17487/RFC6454, December 2011, 291 . 293 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 294 RFC 7320, DOI 10.17487/RFC7320, July 2014, 295 . 297 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 298 Writing an IANA Considerations Section in RFCs", BCP 26, 299 RFC 8126, DOI 10.17487/RFC8126, June 2017, 300 . 302 6.2. Informative References 304 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 305 Authoring and Versioning (WebDAV)", RFC 4918, 306 DOI 10.17487/RFC4918, June 2007, 307 . 309 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 310 Uniform Resource Identifiers (URIs)", RFC 5785, 311 DOI 10.17487/RFC5785, April 2010, 312 . 314 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 315 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 316 DOI 10.17487/RFC7231, June 2014, 317 . 319 [W3C.REC-P3P-20020416] 320 Marchiori, M., "The Platform for Privacy Preferences 1.0 321 (P3P1.0) Specification", World Wide Web Consortium 322 Recommendation REC-P3P-20020416, April 2002, 323 . 325 [W3C.REC-webarch-20041215] 326 Jacobs, I. and N. Walsh, "Architecture of the World Wide 327 Web, Volume One", World Wide Web Consortium 328 Recommendation REC-webarch-20041215, December 2004, 329 . 331 6.3. URIs 333 [1] https://github.com/mnot/I-D/labels/rfc5785bis 335 [2] https://mnot.github.io/I-D/rfc5785bis/ 337 [3] https://github.com/mnot/I-D/commits/gh-pages/rfc5785bis 339 [4] https://datatracker.ietf.org/doc/draft-nottingham-rfc5785bis/ 341 [5] http://www.robotstxt.org/ 343 Appendix A. Frequently Asked Questions 345 1. Aren't well-known locations bad for the Web? 347 They are, but for various reasons - both technical and social - 348 they are sometimes necessary. This memo defines a "sandbox" for 349 them, to reduce the risks of collision and to minimise the impact 350 upon pre-existing URIs on sites. 352 2. Why /.well-known? 354 It's short, descriptive, and according to search indices, not 355 widely used. 357 3. What impact does this have on existing mechanisms, such as P3P 358 and robots.txt? 360 None, until they choose to use this mechanism. 362 4. Why aren't per-directory well-known locations defined? 364 Allowing every URI path segment to have a well-known location 365 (e.g., "/images/.well-known/") would increase the risks of 366 colliding with a pre-existing URI on a site, and generally these 367 solutions are found not to scale well, because they're too 368 "chatty". 370 5. I want to use a well-known location to make it easy to configure 371 my protocol that uses HTTP. 373 This is not what well-known locations are for; see Section 1.1. 375 Appendix B. Changes from RFC5785 377 o Discuss appropriate and inappropriate uses more fully 379 o Adjust IANA instructions 381 o Update references 383 o Various other clarifications 385 Author's Address 387 Mark Nottingham 389 Email: mnot@mnot.net 390 URI: https://www.mnot.net/