idnits 2.17.1 draft-nottingham-site-meta-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 17, 2009) is 5334 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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: 2 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 E. Hammer-Lahav 4 Intended status: Informational September 17, 2009 5 Expires: March 21, 2010 7 Defining Well-Known URIs 8 draft-nottingham-site-meta-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 21, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo defines a path prefix for "well-known locations" in URIs. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 52 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . . 4 56 5.1.1. Registration Template . . . . . . . . . . . . . . . . . 5 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 61 Appendix B. Frequently Asked Questions . . . . . . . . . . . . . . 6 62 B.1. Aren't well-known locations bad for the Web? . . . . . . . 6 63 B.2. Why /.well-known? . . . . . . . . . . . . . . . . . . . . . 6 64 B.3. Is this just for HTTP URIs? . . . . . . . . . . . . . . . . 7 65 B.4. What impact does this have on existing mechanisms, 66 such as P3P and robots.txt? . . . . . . . . . . . . . . . . 7 67 B.5. Why aren't per-directory well-known locations defined? . . 7 68 Appendix C. Document History . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 It is increasingly common for Web-based protocols to require the 74 discovery of policy or metadata before making a request. For 75 example, the Robots Exclusion Protocol specifies a way for automated 76 processes to obtain permission to access resources; likewise, the 77 Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user- 78 agents how to discover privacy policy beforehand. 80 While there are several ways to access per-resource metadata (e.g., 81 HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead 82 associated with them often precludes their use in these scenarios. 84 When this happens, it is common to designate a "well-known location" 85 for such metadata, so that it can be easily located. However, this 86 approach has the drawback of risking collisions, both with other such 87 designated "well-known locations" and with pre-existing resources. 89 To address this, this memo defines a path prefix for these "well- 90 known locations", "/.well-known/". Future specifications that need 91 to define a resource for such site-wide metadata can register their 92 use to avoid collisions and minimise impingement upon sites' URI 93 space. 95 Please discuss this draft on the apps-discuss@ietf.org [1] mailing 96 list. 98 2. Notational Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 3. Well-Known URIs 106 A well-known URI is a URI [RFC3986] whose path component begins with 107 the characters "/.well-known/". 109 Applications that wish to mint new well-known URIs MUST register 110 them, following the procedures in Section 5.1. 112 For example, if an application registers the value 'example', the 113 corresponding well-known URI on 'http://www.example.com/' would be 114 'http://www.example.com/.well-known/example'. 116 Note that this specification defines neither how to determine the 117 authority to use for a particular context, nor the scope of the 118 metadata discovered by dereferencing the well-known URI; both should 119 be defined by the application itself. 121 Typically, a registration will reference a specification that defines 122 the format and associated media type to be obtained by dereferencing 123 the well-known URI. 125 It MAY also contain additional information, such as the syntax of 126 additional path components, query strings and/or fragment identifiers 127 to be appended to the well-known URI, or protocol-specific details 128 (e.g., HTTP [RFC2616] method handling). 130 Note that this specification also does not define a format or media- 131 type for the resource at located at "/.well-known/" and clients 132 should not expect a resource to exist at that location. 134 4. Security Considerations 136 This memo does not specify the scope of applicability of metadata or 137 policy obtained from a well-known URI, and does not specify how to 138 discover a well-known URI for a particular application. Individual 139 applications using this mechanism must define both aspects. 141 An attacker with certain types of limited access to a server may be 142 able to affect how well-known URIs are served; for example, they may 143 be able to upload a file at that location, or they may be able to 144 cause a server to redirect a well-known URI to a URI that they 145 control. 147 Because most URI schemes rely on DNS to resolve names, they are 148 vulnerable to "DNS rebinding" attacks, whereby a request can be 149 directed to a server under the control of an attacker. 151 5. IANA Considerations 153 5.1. The Well-Known URI Registry 155 This document establishes the well-known URI registry as the name 156 space of URIs that have a path beginning with "/.well-known/". 158 Well-known URIs are registered on the advice of a Designated Expert 159 (appointed by the IESG or their delegate), with a Specification 160 Required (using terminology from [RFC5226]). 162 Registration requests consist of the completed registration template 163 (see Section 5.1.1), typically published in an RFC or Open Standard 164 (in the sense described by [RFC2026], section 7). However, to allow 165 for the allocation of values prior to publication, the Designated 166 Expert may approve registration once they are satisfied that an RFC 167 (or other Open Standard) will be published. 169 Upon receiving a registration request (usually via IANA), the 170 Designated Expert should request review and comment from the apps- 171 discuss mailing list (or a successor designated by the APPS Area 172 Directors). Before a period of 30 days has passed, the Designated 173 Expert will either approve or deny the registration request, 174 communicating this decision both to the review list and to IANA. 175 Denials should include an explanation and, if applicable, suggestions 176 as to how to make the request successful. 178 5.1.1. Registration Template 180 URI suffix: The name requested for the well-known URI, relative to 181 "/.well-known/"; e.g., "example". MUST conform to the segment-nz 182 production in [RFC3986]. 183 Change controller: For standards-track RFCs, state "IETF". For 184 other open standards, give the name of the publishing body (e.g., 185 ANSI, ISO, ITU, W3C, etc.). A postal address, home page URI, 186 telephone and fax numbers may also be included. 187 Specification document(s): Reference to document that specifies the 188 field, preferably including a URI that can be used to retrieve a 189 copy of the document. An indication of the relevant sections may 190 also be included, but is not required. 191 Related information: Optionally, citations to additional documents 192 containing further relevant information. 194 6. References 196 6.1. Normative References 198 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 199 3", BCP 9, RFC 2026, October 1996. 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, March 1997. 204 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 205 Resource Identifier (URI): Generic Syntax", STD 66, 206 RFC 3986, January 2005. 208 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 209 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 210 May 2008. 212 6.2. Informative References 214 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 215 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 216 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 218 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 219 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 221 [W3C.REC-P3P-20020416] 222 Marchiori, M., "The Platform for Privacy Preferences 1.0 223 (P3P1.0) Specification", W3C REC REC-P3P-20020416, 224 April 2002. 226 URIs 228 [1] 230 Appendix A. Acknowledgements 232 We would like to acknowledge the contributions of everyone who 233 provided feedback and use cases for this draft; in particular, Phil 234 Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad 235 Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra, 236 Breno de Medeiros, John Panzer, and Drummond Reed. However, they are 237 not responsible for errors and omissions. 239 Appendix B. Frequently Asked Questions 241 B.1. Aren't well-known locations bad for the Web? 243 They are, but for various reasons -- both technical and social -- 244 they are commonly used, and their use is increasing. This memo 245 defines a "sandbox" for them, to reduce the risks of collision and to 246 minimise the impact upon pre-existing URIs on sites. 248 B.2. Why /.well-known? 250 It's short, descriptive and according to search indices, not widely 251 used. 253 B.3. Is this just for HTTP URIs? 255 No; although HTTP is the most typical use case, applications can 256 define well-known URIs for any URI scheme that allows path segments. 258 B.4. What impact does this have on existing mechanisms, such as P3P and 259 robots.txt? 261 None, until they choose to use this mechanism. 263 B.5. Why aren't per-directory well-known locations defined? 265 Allowing every URI path segment to have a well-known location (e.g., 266 "/images/.well-known/") would increase the risks of colliding with a 267 pre-existing URI on a site, and generally these solutions are found 268 not to scale well, because they're too "chatty". 270 Appendix C. Document History 272 [[RFC Editor: please remove this section before publication.]] 274 o -03 275 * Add fragment identifiers to list of things an application might 276 define. 277 * Note that the /.well-known/ URI doesn't have anything there. 278 o -02 279 * Rewrote to just define a namespace for well-known URIs. 280 * Changed discussion forum to apps-discuss. 281 o -01 282 * Changed "site-meta" to "host-meta" after feedback. 283 * Changed from XML to text-based header-like format. 284 * Remove capability for generic inline content. 285 * Added registry for host-meta fields. 286 * Clarified scope of metadata application. 287 * Added security consideration about HTTP vs. HTTPS, expanding 288 scope. 290 Authors' Addresses 292 Mark Nottingham 294 Email: mnot@mnot.net 295 URI: http://www.mnot.net/ 296 Eran Hammer-Lahav 298 Email: eran@hueniverse.com 299 URI: http://hueniverse.com/