7 Internet Engineering Task Force (IETF) M. Nottingham
8 Request for Comments: 5785 E. Hammer-Lahav
9 Updates: 2616, 2818 April 2010
10 Category: Standards Track
14 Defining Well-Known Uniform Resource Identifiers (URIs)
18 This memo defines a path prefix for "well-known locations",
19 "/.well-known/", in selected Uniform Resource Identifier (URI)
24 This is an Internet Standards Track document.
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 5741.
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 http://www.rfc-editor.org/info/rfc5785.
38 Copyright (c) 2010 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
58 Nottingham & Hammer-Lahav Standards Track [Page 1]
60 RFC 5785 Defining Well-Known URIs April 2010
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 1.1. Appropriate Use of Well-Known URIs . . . . . . . . . . . . 3
67 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
68 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
69 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
71 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
72 5.1.1. Registration Template . . . . . . . . . . . . . . . . . 5
73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
74 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
75 6.2. Informative References . . . . . . . . . . . . . . . . . . 5
76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
77 Appendix B. Frequently Asked Questions . . . . . . . . . . . . . . 7
81 It is increasingly common for Web-based protocols to require the
82 discovery of policy or other information about a host ("site-wide
83 metadata") before making a request. For example, the Robots
84 Exclusion Protocol <http://www.robotstxt.org/> specifies a way for
85 automated processes to obtain permission to access resources;
86 likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416]
87 tells user-agents how to discover privacy policy beforehand.
89 While there are several ways to access per-resource metadata (e.g.,
90 HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
91 (either in terms of client-perceived latency and/or deployment
92 difficulties) associated with them often precludes their use in these
95 When this happens, it is common to designate a "well-known location"
96 for such data, so that it can be easily located. However, this
97 approach has the drawback of risking collisions, both with other such
98 designated "well-known locations" and with pre-existing resources.
100 To address this, this memo defines a path prefix in HTTP(S) URIs for
101 these "well-known locations", "/.well-known/". Future specifications
102 that need to define a resource for such site-wide metadata can
103 register their use to avoid collisions and minimise impingement upon
114 Nottingham & Hammer-Lahav Standards Track [Page 2]
116 RFC 5785 Defining Well-Known URIs April 2010
119 1.1. Appropriate Use of Well-Known URIs
121 There are a number of possible ways that applications could use Well-
122 known URIs. However, in keeping with the Architecture of the World-
123 Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
124 for general information retrieval or establishment of large URI
125 namespaces on the Web. Rather, they are designed to facilitate
126 discovery of information on a site when it isn't practical to use
127 other mechanisms; for example, when discovering policy that needs to
128 be evaluated before a resource is accessed, or when using multiple
129 round-trips is judged detrimental to performance.
131 As such, the well-known URI space was created with the expectation
132 that it will be used to make site-wide policy information and other
133 metadata available directly (if sufficiently concise), or provide
134 references to other URIs that provide such metadata.
136 2. Notational Conventions
138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
140 document are to be interpreted as described in RFC 2119 [RFC2119].
144 A well-known URI is a URI [RFC3986] whose path component begins with
145 the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS",
146 or another scheme that has explicitly been specified to use well-
149 Applications that wish to mint new well-known URIs MUST register
150 them, following the procedures in Section 5.1.
152 For example, if an application registers the name 'example', the
153 corresponding well-known URI on 'http://www.example.com/' would be
154 'http://www.example.com/.well-known/example'.
156 Registered names MUST conform to the segment-nz production in
159 Note that this specification defines neither how to determine the
160 authority to use for a particular context, nor the scope of the
161 metadata discovered by dereferencing the well-known URI; both should
162 be defined by the application itself.
164 Typically, a registration will reference a specification that defines
165 the format and associated media type to be obtained by dereferencing
170 Nottingham & Hammer-Lahav Standards Track [Page 3]
172 RFC 5785 Defining Well-Known URIs April 2010
175 It MAY also contain additional information, such as the syntax of
176 additional path components, query strings and/or fragment identifiers
177 to be appended to the well-known URI, or protocol-specific details
178 (e.g., HTTP [RFC2616] method handling).
180 Note that this specification does not define a format or media-type
181 for the resource located at "/.well-known/" and clients should not
182 expect a resource to exist at that location.
184 4. Security Considerations
186 This memo does not specify the scope of applicability of metadata or
187 policy obtained from a well-known URI, and does not specify how to
188 discover a well-known URI for a particular application. Individual
189 applications using this mechanism must define both aspects.
191 Applications minting new well-known URIs, as well as administrators
192 deploying them, will need to consider several security-related
193 issues, including (but not limited to) exposure of sensitive data,
194 denial-of-service attacks (in addition to normal load issues), server
195 and client authentication, vulnerability to DNS rebinding attacks,
196 and attacks where limited access to a server grants the ability to
197 affect how well-known URIs are served.
199 5. IANA Considerations
201 5.1. The Well-Known URI Registry
203 This document establishes the well-known URI registry.
205 Well-known URIs are registered on the advice of one or more
206 Designated Experts (appointed by the IESG or their delegate), with a
207 Specification Required (using terminology from [RFC5226]). However,
208 to allow for the allocation of values prior to publication, the
209 Designated Expert(s) may approve registration once they are satisfied
210 that such a specification will be published.
212 Registration requests should be sent to the
213 wellknown-uri-review@ietf.org mailing list for review and comment,
214 with an appropriate subject (e.g., "Request for well-known URI:
217 Before a period of 14 days has passed, the Designated Expert(s) will
218 either approve or deny the registration request, communicating this
219 decision both to the review list and to IANA. Denials should include
220 an explanation and, if applicable, suggestions as to how to make the
226 Nottingham & Hammer-Lahav Standards Track [Page 4]
228 RFC 5785 Defining Well-Known URIs April 2010
231 request successful. Registration requests that are undetermined for
232 a period longer than 21 days can be brought to the IESG's attention
233 (using the iesg@iesg.org mailing list) for resolution.
235 5.1.1. Registration Template
237 URI suffix: The name requested for the well-known URI, relative to
238 "/.well-known/"; e.g., "example".
240 Change controller: For Standards-Track RFCs, state "IETF". For
241 others, give the name of the responsible party. Other details
242 (e.g., postal address, e-mail address, home page URI) may also be
245 Specification document(s): Reference to the document that specifies
246 the field, preferably including a URI that can be used to retrieve
247 a copy of the document. An indication of the relevant sections
248 may also be included, but is not required.
250 Related information: Optionally, citations to additional documents
251 containing further relevant information.
255 6.1. Normative References
257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
258 Requirement Levels", BCP 14, RFC 2119, March 1997.
260 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
261 Resource Identifier (URI): Generic Syntax", STD 66,
262 RFC 3986, January 2005.
264 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
265 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
268 6.2. Informative References
270 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
271 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer
272 Protocol -- HTTP/1.1", RFC 2616, June 1999.
274 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
275 Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
282 Nottingham & Hammer-Lahav Standards Track [Page 5]
284 RFC 5785 Defining Well-Known URIs April 2010
287 [W3C.REC-P3P-20020416]
288 Marchiori, M., "The Platform for Privacy Preferences 1.0
289 (P3P1.0) Specification", World Wide Web Consortium
290 Recommendation REC-P3P-20020416, April 2002,
291 <http://www.w3.org/TR/2002/ REC-P3P-20020416>.
293 [W3C.REC-webarch-20041215]
294 Jacobs, I. and N. Walsh, "Architecture of the World Wide
295 Web, Volume One", World Wide Web Consortium
296 Recommendation REC- webarch-20041215, December 2004,
297 <http:// www.w3.org/TR/2004/REC-webarch-20041215>.
338 Nottingham & Hammer-Lahav Standards Track [Page 6]
340 RFC 5785 Defining Well-Known URIs April 2010
343 Appendix A. Acknowledgements
345 We would like to acknowledge the contributions of everyone who
346 provided feedback and use cases for this document; in particular,
347 Phil Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad
348 Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra,
349 Breno de Medeiros, John Panzer, and Drummond Reed. However, they are
350 not responsible for errors and omissions.
352 Appendix B. Frequently Asked Questions
354 1. Aren't well-known locations bad for the Web?
356 They are, but for various reasons -- both technical and social --
357 they are commonly used and their use is increasing. This memo
358 defines a "sandbox" for them, to reduce the risks of collision and
359 to minimise the impact upon pre-existing URIs on sites.
363 It's short, descriptive, and according to search indices, not
366 3. What impact does this have on existing mechanisms, such as P3P and
369 None, until they choose to use this mechanism.
371 4. Why aren't per-directory well-known locations defined?
373 Allowing every URI path segment to have a well-known location
374 (e.g., "/images/.well-known/") would increase the risks of
375 colliding with a pre-existing URI on a site, and generally these
376 solutions are found not to scale well, because they're too
394 Nottingham & Hammer-Lahav Standards Track [Page 7]
396 RFC 5785 Defining Well-Known URIs April 2010
404 URI: http://www.mnot.net/
409 EMail: eran@hueniverse.com
410 URI: http://hueniverse.com/
450 Nottingham & Hammer-Lahav Standards Track [Page 8]