dav/SabreDAV/docs/rfc5785.txt

   1
   2
   3
   4
   5
   6
   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
  11 ISSN: 2070-1721
  12
  13
  14         Defining Well-Known Uniform Resource Identifiers (URIs)
  15
  16 Abstract
  17
  18    This memo defines a path prefix for "well-known locations",
  19    "/.well-known/", in selected Uniform Resource Identifier (URI)
  20    schemes.
  21
  22 Status of This Memo
  23
  24    This is an Internet Standards Track document.
  25
  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.
  31
  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.
  35
  36 Copyright Notice
  37
  38    Copyright (c) 2010 IETF Trust and the persons identified as the
  39    document authors.  All rights reserved.
  40
  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.
  50
  51
  52
  53
  54
  55
  56
  57
  58 Nottingham & Hammer-Lahav    Standards Track                    [Page 1]
  59 \f
  60 RFC 5785                Defining Well-Known URIs              April 2010
  61
  62
  63 Table of Contents
  64
  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
  78
  79 1.  Introduction
  80
  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.
  88
  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
  93    scenarios.
  94
  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.
  99
 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
 104    sites' URI space.
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Nottingham & Hammer-Lahav    Standards Track                    [Page 2]
 115 \f
 116 RFC 5785                Defining Well-Known URIs              April 2010
 117
 118
 119 1.1.  Appropriate Use of Well-Known URIs
 120
 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.
 130
 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.
 135
 136 2.  Notational Conventions
 137
 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].
 141
 142 3.  Well-Known URIs
 143
 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-
 147    known URIs.
 148
 149    Applications that wish to mint new well-known URIs MUST register
 150    them, following the procedures in Section 5.1.
 151
 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'.
 155
 156    Registered names MUST conform to the segment-nz production in
 157    [RFC3986].
 158
 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.
 163
 164    Typically, a registration will reference a specification that defines
 165    the format and associated media type to be obtained by dereferencing
 166    the well-known URI.
 167
 168
 169
 170 Nottingham & Hammer-Lahav    Standards Track                    [Page 3]
 171 \f
 172 RFC 5785                Defining Well-Known URIs              April 2010
 173
 174
 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).
 179
 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.
 183
 184 4.  Security Considerations
 185
 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.
 190
 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.
 198
 199 5.  IANA Considerations
 200
 201 5.1.  The Well-Known URI Registry
 202
 203    This document establishes the well-known URI registry.
 204
 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.
 211
 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:
 215    example").
 216
 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
 221
 222
 223
 224
 225
 226 Nottingham & Hammer-Lahav    Standards Track                    [Page 4]
 227 \f
 228 RFC 5785                Defining Well-Known URIs              April 2010
 229
 230
 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.
 234
 235 5.1.1.  Registration Template
 236
 237    URI suffix:  The name requested for the well-known URI, relative to
 238       "/.well-known/"; e.g., "example".
 239
 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
 243       included.
 244
 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.
 249
 250    Related information:  Optionally, citations to additional documents
 251       containing further relevant information.
 252
 253 6.  References
 254
 255 6.1.  Normative References
 256
 257    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 258              Requirement Levels", BCP 14, RFC 2119, March 1997.
 259
 260    [RFC3986] Berners-Lee, T., Fielding, R., and L.  Masinter, "Uniform
 261              Resource Identifier (URI): Generic Syntax", STD 66,
 262              RFC 3986, January 2005.
 263
 264    [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
 265              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
 266              May 2008.
 267
 268 6.2.  Informative References
 269
 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.
 273
 274    [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
 275              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
 276
 277
 278
 279
 280
 281
 282 Nottingham & Hammer-Lahav    Standards Track                    [Page 5]
 283 \f
 284 RFC 5785                Defining Well-Known URIs              April 2010
 285
 286
 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>.
 292
 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>.
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Nottingham & Hammer-Lahav    Standards Track                    [Page 6]
 339 \f
 340 RFC 5785                Defining Well-Known URIs              April 2010
 341
 342
 343 Appendix A.  Acknowledgements
 344
 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.
 351
 352 Appendix B.  Frequently Asked Questions
 353
 354    1. Aren't well-known locations bad for the Web?
 355
 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.
 360
 361    2. Why /.well-known?
 362
 363       It's short, descriptive, and according to search indices, not
 364       widely used.
 365
 366    3. What impact does this have on existing mechanisms, such as P3P and
 367       robots.txt?
 368
 369       None, until they choose to use this mechanism.
 370
 371    4. Why aren't per-directory well-known locations defined?
 372
 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
 377       "chatty".
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Nottingham & Hammer-Lahav    Standards Track                    [Page 7]
 395 \f
 396 RFC 5785                Defining Well-Known URIs              April 2010
 397
 398
 399 Authors' Addresses
 400
 401    Mark Nottingham
 402
 403    EMail: mnot@mnot.net
 404    URI:   http://www.mnot.net/
 405
 406
 407    Eran Hammer-Lahav
 408
 409    EMail: eran@hueniverse.com
 410    URI:   http://hueniverse.com/
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Nottingham & Hammer-Lahav    Standards Track                    [Page 8]
 451 \f