idnits 2.17.1 draft-nottingham-rfc5785bis-03.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 7, 2018) is 2267 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 321 -- Looks like a reference, but probably isn't: '2' on line 323 -- Looks like a reference, but probably isn't: '3' on line 325 -- Looks like a reference, but probably isn't: '4' on line 327 -- Looks like a reference, but probably isn't: '5' on line 329 ** Obsolete normative reference: RFC 5741 (Obsoleted by RFC 7841) -- 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: 2 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 7, 2018 4 Obsoletes: 5785 (if approved) 5 Intended status: Standards Track 6 Expires: August 11, 2018 8 Defining Well-Known Uniform Resource Identifiers (URIs) 9 draft-nottingham-rfc5785bis-03 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 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 Some applications on the Web require the discovery of policy or other 86 information about an origin [RFC6454] (sometimes called "site-wide 87 metadata") before making a request. For example, the Robots 88 Exclusion Protocol (http://www.robotstxt.org/ [5]) specifies a way 89 for 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 before interacting 92 with an 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, so that it can 102 be easily located. However, this approach has the drawback of 103 risking collisions, both with other such designated "well-known 104 locations" and with pre-existing resources. 106 To address this, this memo defines a path prefix in HTTP(S) URIs for 107 these "well-known locations", "/.well-known/". Future specifications 108 that need to define a resource for such metadata can register their 109 use to avoid collisions and minimise impingement upon origins' URI 110 space. 112 Well-known URIs can also be used with other URI schemes, but only 113 when those schemes' definitions explicitly allow it. 115 1.1. Appropriate Use of Well-Known URIs 117 There are a number of possible ways that applications could use well- 118 known URIs. However, in keeping with the Architecture of the World- 119 Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended 120 for general information retrieval or establishment of large URI 121 namespaces. 123 Rather, they are designed to facilitate discovery of information 124 about an origin when it isn't practical to use other mechanisms; for 125 example, when discovering policy that needs to be evaluated before a 126 resource is accessed, or when the information applies to many (or 127 all) of the origin's resources. 129 As such, the well-known URI space was created with the expectation 130 that it will be used to make policy information and other metadata 131 about the origin available directly (if sufficiently concise), or 132 provide references to other URIs that provide it. In general, the 133 information it contains should be applicable to most Web origins 134 (while acknowledging that many will not use a particular well-known 135 location, for various reasons). 137 In particular, well-known URIs are not a "protocol registry" for 138 applications and protocols that wish to use HTTP as a substrate. 139 Even if a particular origin is dedicated to the protocol in question, 140 it is inappropriate to devote a URL on all origins to a specialist 141 protocol that has little or no potential benefit for them. 143 Instead, such applications and protocols are encouraged to used a URI 144 to bootstrap their operation, rather than using a hostname and a 145 well-known URI. 147 Exceptionally, the registry expert(s) may approve such a registration 148 for documents in the IETF Stream [RFC5741], in consultation with the 149 IESG, provided that the protocol in question cannot be bootstrapped 150 with a URI (e.g., the discovery mechanism can only carry a hostname). 151 However, merely making it easier to locate it is not a sufficient 152 reason. Likewise, future use unsupported by the specification in 153 question is not sufficient reason to register a well-known location. 155 Well-known locations are also not suited for information on topics 156 other than the origin that they are located upon; for example, 157 creating a well-known resource about a business entity or 158 organisational structure presumes that Internet hosts and 159 organisations share structure, and are likely to have significant 160 deployment issues in environments where this is not true. 162 2. Notational Conventions 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 3. Well-Known URIs 170 A well-known URI is a URI [RFC3986] whose path component begins with 171 the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS", 172 or another scheme that has explicitly been specified to use well- 173 known URIs. 175 Applications that wish to mint new well-known URIs MUST register 176 them, following the procedures in Section 5.1. 178 For example, if an application registers the name 'example', the 179 corresponding well-known URI on 'http://www.example.com/' would be 180 'http://www.example.com/.well-known/example'. 182 Registered names MUST conform to the segment-nz production in 183 [RFC3986]. This means they cannot contain the "/" character. 185 Note that this specification defines neither how to determine the 186 authority to use for a particular context, nor the scope of the 187 metadata discovered by dereferencing the well-known URI; both should 188 be defined by the application itself. 190 Typically, a registration will reference a specification that defines 191 the format and associated media type to be obtained by dereferencing 192 the well-known URI. 194 It MAY also contain additional information, such as the syntax of 195 additional path components, query strings and/or fragment identifiers 196 to be appended to the well-known URI, or protocol-specific details 197 (e.g., HTTP [RFC7231] method handling). 199 Note that this specification does not define a format or media-type 200 for the resource located at "/.well-known/" and clients should not 201 expect a resource to exist at that location. 203 Well-known URIs are only valid when rooted in the top of the path's 204 hierarchy; they MUST NOT be used in other parts of the path. For 205 example, "/.well-known/example" is a valid use, but "/foo/.well- 206 known/example" is not. 208 4. Security Considerations 210 This memo does not specify the scope of applicability of metadata or 211 policy obtained from a well-known URI, and does not specify how to 212 discover a well-known URI for a particular application. Individual 213 applications using this mechanism must define both aspects. 215 Applications minting new well-known URIs, as well as administrators 216 deploying them, will need to consider several security-related 217 issues, including (but not limited to) exposure of sensitive data, 218 denial-of-service attacks (in addition to normal load issues), server 219 and client authentication, vulnerability to DNS rebinding attacks, 220 and attacks where limited access to a server grants the ability to 221 affect how well-known URIs are served. 223 Security-sensitive applications using well-known locations should 224 consider that some server administrators might be unaware of its 225 existence (especially on operating systems that hide directories 226 whose names begin with "."). This means that if an attacker has 227 write access to the .well-known directory, they would be able to 228 control its contents, possibly without the administrator realising 229 it. 231 5. IANA Considerations 233 5.1. The Well-Known URI Registry 235 This document specifies procedures for the well-known URI registry, 236 first defined in [RFC5785]. 238 Well-known URIs are registered on the advice of one or more experts 239 (appointed by the IESG or their delegate), with a Specification 240 Required (using terminology from [RFC8126]). 242 To allow for the allocation of values prior to publication, the 243 expert(s) may approve registration once they are satisfied that such 244 a specification will be published. 246 Registration requests can be sent to the wellknown-uri- 247 review@ietf.org mailing list for review and comment, with an 248 appropriate subject (e.g., "Request for well-known URI: example"). 250 5.1.1. Registration Template 252 URI suffix: The name requested for the well-known URI, relative to 253 "/.well-known/"; e.g., "example". 255 Change controller: For Standards-Track RFCs, state "IETF". For 256 others, give the name of the responsible party. Other details 257 (e.g., postal address, e-mail address, home page URI) may also be 258 included. 260 Specification document(s): Reference to the document that specifies 261 the field, preferably including a URI that can be used to retrieve 262 a copy of the document. An indication of the relevant sections 263 may also be included, but is not required. 265 Related information: Optionally, citations to additional documents 266 containing further relevant information. 268 6. References 270 6.1. Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, 274 DOI 10.17487/RFC2119, March 1997, 275 . 277 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 278 Resource Identifier (URI): Generic Syntax", STD 66, 279 RFC 3986, DOI 10.17487/RFC3986, January 2005, 280 . 282 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 283 Headers, and Boilerplates", RFC 5741, 284 DOI 10.17487/RFC5741, December 2009, 285 . 287 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 288 DOI 10.17487/RFC6454, December 2011, 289 . 291 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 292 Writing an IANA Considerations Section in RFCs", BCP 26, 293 RFC 8126, DOI 10.17487/RFC8126, June 2017, 294 . 296 6.2. Informative References 298 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 299 Authoring and Versioning (WebDAV)", RFC 4918, 300 DOI 10.17487/RFC4918, June 2007, 301 . 303 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 304 Uniform Resource Identifiers (URIs)", RFC 5785, 305 DOI 10.17487/RFC5785, April 2010, 306 . 308 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 309 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 310 DOI 10.17487/RFC7231, June 2014, 311 . 313 [W3C.REC-P3P-20020416] 314 Marchiori, M., "The Platform for Privacy Preferences 1.0 315 (P3P1.0) Specification", World Wide Web Consortium 316 Recommendation REC-P3P-20020416, April 2002, 317 . 319 6.3. URIs 321 [1] https://github.com/mnot/I-D/labels/rfc5785bis 323 [2] https://mnot.github.io/I-D/rfc5785bis/ 325 [3] https://github.com/mnot/I-D/commits/gh-pages/rfc5785bis 327 [4] https://datatracker.ietf.org/doc/draft-nottingham-rfc5785bis/ 329 [5] http://www.robotstxt.org/ 331 Appendix A. Frequently Asked Questions 333 1. Aren't well-known locations bad for the Web? 335 They are, but for various reasons - both technical and social - 336 they are sometimes necessary. This memo defines a "sandbox" for 337 them, to reduce the risks of collision and to minimise the impact 338 upon pre-existing URIs on sites. 340 2. Why /.well-known? 342 It's short, descriptive, and according to search indices, not 343 widely used. 345 3. What impact does this have on existing mechanisms, such as P3P 346 and robots.txt? 348 None, until they choose to use this mechanism. 350 4. Why aren't per-directory well-known locations defined? 352 Allowing every URI path segment to have a well-known location 353 (e.g., "/images/.well-known/") would increase the risks of 354 colliding with a pre-existing URI on a site, and generally these 355 solutions are found not to scale well, because they're too 356 "chatty". 358 5. I want to use a well-known location to make it easy to configure 359 my protocol that uses HTTP. 361 This is not what well-known locations are for; see Section 1.1. 363 Appendix B. Changes from RFC5785 365 o Discuss appropriate and inappropriate uses more fully 367 o Adjust IANA instructions 369 o Update references 371 o Various other clarifications 373 Author's Address 375 Mark Nottingham 377 Email: mnot@mnot.net 378 URI: https://www.mnot.net/