idnits 2.17.1 draft-nottingham-bcp56bis-00.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 draft header indicates that this document obsoletes RFC3205, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (May 11, 2017) is 2542 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) ** Obsolete normative reference: RFC 7321 (Obsoleted by RFC 8221) ** Downref: Normative reference to an Informational RFC: RFC 7322 ** Downref: Normative reference to an Informational RFC: RFC 7325 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft May 11, 2017 4 Obsoletes: 3205 (if approved) 5 Intended status: Best Current Practice 6 Expires: November 12, 2017 8 On the use of HTTP as a Substrate 9 draft-nottingham-bcp56bis-00 11 Abstract 13 HTTP is often used as a substrate for other application protocols. 14 This document specifies best practices for these protocols' use of 15 HTTP. 17 Note to Readers 19 The issues list for this draft can be found at 20 https://github.com/mnot/I-D/labels/bcp56bis . 22 The most recent (often, unpublished) draft is at 23 https://mnot.github.io/I-D/bcp56bis/ . 25 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 26 pages/bcp56bis . 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 12, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 64 2. Is HTTP Being Used? . . . . . . . . . . . . . . . . . . . . . 4 65 3. What's Important About HTTP . . . . . . . . . . . . . . . . . 5 66 3.1. Generic Semantics . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Getting Value from HTTP . . . . . . . . . . . . . . . . . 6 69 4. Best Practices for Using HTTP . . . . . . . . . . . . . . . . 7 70 4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 7 71 4.2. Defining HTTP Resources . . . . . . . . . . . . . . . . . 8 72 4.3. HTTP URLs . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.3.1. Initial URL Discovery . . . . . . . . . . . . . . . . 9 74 4.3.2. URL Schemes . . . . . . . . . . . . . . . . . . . . . 9 75 4.3.3. Transport Ports . . . . . . . . . . . . . . . . . . . 10 76 4.4. Authentication and Application State . . . . . . . . . . 10 77 4.5. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 10 78 4.6. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 11 79 4.7. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 12 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 7.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 HTTP [RFC7230] is often used as a substrate for other application 90 protocols. This is done for a variety of reasons, including: 92 o familiarity by implementers, specifiers, administrators, 93 developers and users, 95 o availability of a variety of client, server and proxy 96 implementations, 98 o ease of use, 100 o ubiquity of Web browsers, 102 o reuse of existing mechanisms like authentication and encryption, 104 o presence of HTTP servers and clients in target deployments, and 106 o its ability to traverse firewalls. 108 The Internet community has a long tradition of protocol reuse, dating 109 back to the use of Telnet [RFC0854] as a substrate for FTP [RFC0959] 110 and SMTP [RFC2821]. However, layering new protocols over HTTP brings 111 its own set of issues: 113 o Should an application using HTTP define a new URL scheme? Use new 114 ports? 116 o Should it use standard HTTP methods and status codes, or define 117 new ones? 119 o How can the maximum value be extracted from the use of HTTP? 121 o How does it coexist with other uses of HTTP - especially Web 122 browsing? 124 o How can interoperability problems and "protocol dead ends" be 125 avoided? 127 This document contains best current practices regarding the use of 128 HTTP by applications other than Web browsing. Section 2 defines what 129 applications it applies to; Section 3 surveys the properties of HTTP 130 that are important to preserve, and Section 4 conveys best practices 131 for those applications that do use HTTP. 133 It is written primarily to guide IETF efforts, but might be 134 applicable in other situations. Note that the requirements herein do 135 not necessarily apply to the development of generic HTTP extensions. 137 1.1. Notational Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2. Is HTTP Being Used? 145 Different applications have different goals when using HTTP. In this 146 document, we say an application is _using HTTP_ when any of the 147 following conditions are true: 149 o The transport port in use is 80 or 443, 151 o The URL scheme "http" or "https" is used, 153 o The ALPN protocol ID [RFC7301] "http/1.1", "h2" or "h2c" is used, 154 or 156 o The message formats described in [RFC7320] and/or [RFC7540] are 157 used in conjunction with the IANA registries defined for HTTP. 159 When an application is using HTTP, all of the requirements of the 160 HTTP protocol suite (including but not limited to [RFC7320], 161 [RFC7321], [RFC7322], [RFC7233], [RFC7234], [RFC7325] and [RFC7540]) 162 are in force. 164 An application might not be _using HTTP_ according to this 165 definition, but still relying upon the HTTP specifications in some 166 manner. For example, an application might wish to avoid re- 167 specifying parts of the message format, but change others; or, it 168 might want to use a different set of methods. 170 Such applications are referred to as _protocols based upon HTTP_ in 171 this document. These have more freedom to modify protocol operation, 172 but are also likely to lose at least a portion of the benefits 173 outlined above, as most HTTP implementations won't be easily 174 adaptable to these changes, and as the protocol diverges from HTTP, 175 the benefit of mindshare will be lost. 177 Protocols that are based upon HTTP MUST NOT reuse HTTP's URL schemes, 178 transport ports, ALPN protocol IDs or IANA registries; rather, they 179 are encouraged to establish their own. 181 3. What's Important About HTTP 183 There are many ways that HTTP applications are defined and deployed, 184 and sometimes they are brought to the IETF for standardisation. In 185 that process, what might be workable for deployment in a limited 186 fashion isn't appropriate for standardisation and the corresponding 187 broader deployment. 189 This section examines the facets of the protocol that are important 190 to preserve in these situations. 192 3.1. Generic Semantics 194 When writing an application's specification, it's often tempting to 195 specify exactly how HTTP is to be implemented, supported and used. 197 However, this can easily lead to an unintended profile of HTTP's 198 behaviour. For example, it's common to see specifications with 199 language like this: 201 A `200 OK` response means that the widget has successfully been updated. 203 This sort of specification is bad practice, because it is adding new 204 semantics to HTTP's status codes and methods, respectively; a 205 recipient - whether it's an origin server, client library, 206 intermediary or cache - now has to know these extra semantics to 207 understand the message. 209 Some applications even require specific behaviours, such as: 211 A `POST` request MUST result in a `201 Created` response. 213 This forms an expectation in the client that the response will always 214 be "201 Created", when in fact there are a number of reasons why the 215 status code might differ in a real deployment. If the client does 216 not anticipate this, the application's deployment is brittle. 218 Much of the value of HTTP is in its _generic semantics_ - that is, 219 the protocol elements defined by HTTP are potentially applicable to 220 every resource, not specific to a particular context. Application- 221 specific semantics are expressed in the payload; mostly, in the body, 222 but also in header fields. 224 This allows a HTTP message to be examined by generic HTTP software 225 (e.g., HTTP servers, intermediaries, client implementatiions), and 226 its handling to be correctly determined. It also allows people to 227 leverage their knowledge of HTTP semantics without special-casing 228 them for a particular application. 230 Therefore, applications that use HTTP MUST NOT re-define, refine or 231 overlay the semantics of defined protocol elements. Instead, they 232 SHOULD focus their specifications on protocol elements that are 233 specific to them; namely their HTTP resources. 235 See Section 4.2 for details. 237 3.2. Links 239 Another common practice is assuming that the HTTP server's name space 240 (or a portion thereof) is exclusively for the use of a single 241 application. This effectively overlays special, application-specific 242 semantics onto that space, precludes other applications from using 243 it. 245 As explained in [RFC7320], such "squatting" on a part of the URL 246 space by a standard usurps the server's authority over its own 247 resources, can cause deployment issues, and is therefore bad practice 248 in standards. 250 Instead of statically defining URL paths, it is RECOMMENDED that 251 applications using HTTP define links in payloads, to allow 252 flexibility in deployment. 254 Using runtime links in this fashion has a number of other benefits. 255 For example, navigating with a link allows a request to be routed to 256 a different server without the overhead of a redirection, thereby 257 supporting deployment across machines well. It becomes possible to 258 "mix" different applications on the same server, and offers a natural 259 path for extensibility, versioning and capability management. 261 3.3. Getting Value from HTTP 263 The simplest possible use of HTTP is to POST data to a single URL, 264 thereby effectively tunnelling through the protocol. 266 This "RPC" style of communication does get some benefit from using 267 HTTP - namely, message framing and the availability of 268 implementations - but fails to realise many others: 270 o Caching for server scalability, latency and bandwidth reduction, 271 and reliability; 273 o Authentication and access control; 275 o Automatic redirection; 277 o Partial content to selectively request part of a response; 278 o Natural support for extensions and versioning through protocol 279 extension; and 281 o The ability to interact with the application easily using a Web 282 browser. 284 Using such a high-level protocol to tunnel simple semantics has 285 downsides too; because of its more advanced capabilities, breadth of 286 deployment and age, HTTP's complexity can cause interoperability 287 problems that could be avoided by using a simpler substrate (e.g., 288 WebSockets [RFC6455], if browser support is necessary, or TCP 289 [RFC0793] if not), or making the application be _based upon HTTP_, 290 instead of using it (as defined in Section 2). 292 Applications that use HTTP are encouraged to accommodate the various 293 features that the protocol offers, so that their users receive the 294 maximum benefit from it. This document does not require specific 295 features to be used, since the appropriate design tradeoffs are 296 highly specific to a given situation. However, following the 297 practices in Section 4 will help make them available. 299 4. Best Practices for Using HTTP 301 This section contains best practices regarding the use of HTTP by 302 applications, including practices for specific HTTP protocol 303 elements. 305 4.1. Specifying the Use of HTTP 307 When specifying the use of HTTP, an application SHOULD use [RFC7230] 308 as the primary reference; it is not necessary to reference all of the 309 specifications in the HTTP suite unless there are specific reasons to 310 do so (e.g., a particular feature is called out). 312 Applications using HTTP MAY specify a minimum version to be supported 313 (HTTP/1.1 is suggested), and MUST NOT specify a maximum version. 315 Likewise, applications need not specify what HTTP mechanisms - such 316 as redirection, caching, authentication, proxy authentication, and so 317 on - are to be supported. Full featured support for HTTP SHOULD be 318 taken for granted in servers and clients, and the application's 319 function SHOULD degrade gracefully if they are not (although this 320 might be achieved by informing the user that their task cannot be 321 completed). 323 For example, an application can specify that it uses HTTP like this: 325 Foo Application uses HTTP {{RFC7230}}. Implementations MUST support 326 HTTP/1.1, and MAY support later versions. Support for common HTTP 327 mechanisms such as redirection and caching are assumed. 329 4.2. Defining HTTP Resources 331 HTTP Applications SHOULD focus on defining the following application- 332 specific protocol elements: 334 o Media types [RFC6838], often based upon a format convention such 335 as JSON [RFC7159], 337 o HTTP header fields, as per Section 4.7, and 339 o The behaviour of resources, as identified by link relations 340 [RFC5988]. 342 By composing these protocol elements, an application can define a set 343 of resources, identified by link relations, that implement specified 344 behaviours, including: 346 o Retrieval of their state using GET, in one or more formats 347 identified by media type; 349 o Resource creation or update using POST or PUT, with an 350 appropriately identified request body format; 352 o Data processing using POST and identified request and response 353 body format(s); and 355 o Resource deletion using DELETE. 357 For example, an application might specify: 359 Resources linked to with the "example-widget" link relation type are 360 Widgets. The state of a Widget can be fetched in the 361 "application/example-widget+json" format, and can be updated by PUT 362 to the same link. Widget resources can be deleted. 364 The "Example-Count" response header field on Widget representations 365 indicates how many Widgets are held by the sender. 367 The "application/example-widget+json" format is a JSON {{RFC7159}} 368 format representing the state of a Widget. It contains links to 369 related information in the link indicated by the Link header field 370 value with the "example-other-info" link relation type. 372 4.3. HTTP URLs 374 In HTTP, URLs are opaque identifiers under the control of the server. 375 As outlined in [RFC7320], standards cannot usurp this space, since it 376 might conflict with existing resources, and constrain implementation 377 and deployment. 379 In other words, applications that use HTTP MUST NOT associate 380 application semantics with specific URL paths. For example, 381 specifying that a "GET to the URL /foo retrieves a bar document" is 382 bad practice. Likewise, specifying "The widget API is at the path 383 /bar" violates [RFC7320]. 385 Instead, applications that use HTTP are encouraged to use typed links 386 [RFC5988] to convey the URIs that are in use, as well as the 387 semantics of the resources that they identify. See Section 4.2 for 388 details. 390 4.3.1. Initial URL Discovery 392 Generally, a client with begin interacting with a given application 393 server by requesting an initial document that contains information 394 about that particular deployment, potentially including links to 395 other relevant resources. 397 Applications that use HTTP SHOULD allow an arbitrary URL to be used 398 as that entry point. For example, rather than specifying "the 399 initial document is at "/foo/v1", they should allow a deployment to 400 use any URL as the entry point for the application. 402 In cases where doing so is impractical (e.g., it is not possible to 403 convey a whole URL, but only a hostname) applications that use HTTP 404 MAY define a well-known URL [RFC5785] as an entry point. 406 4.3.2. URL Schemes 408 Applications that use HTTP MUST allow use of the "https" URL scheme, 409 and SHOULD NOT allow use of the "http" URL scheme, unless 410 interoperability considerations with existing deployments require it. 411 They MUST NOT use other URL schemes. 413 "https" is preferred to mitigate pervasive monitoring attacks 414 [RFC7258]. 416 Using other schemes to denote an application using HTTP makes it more 417 difficult to use with existing implementations (e.g., Web browsers), 418 and is likely to fail to meet the requirements of [RFC7595]. 420 If it is necessary to advertise the application in use, this SHOULD 421 be done in message payloads, not the URL scheme. 423 4.3.3. Transport Ports 425 Applications that use HTTP SHOULD use the default port for the URL 426 scheme in use. If it is felt that networks might need to distinguish 427 the application's traffic for operational reasons, it MAY register a 428 separate port, but be aware that this has privacy implications for 429 that protocol's users. The impact of doing so MUST be documented in 430 Security Considerations. 432 4.4. Authentication and Application State 434 Applications that use HTTP MAY use stateful cookies [RFC6265] to 435 identify a client and/or store client-specific data to contextualise 436 requests. 438 If it is only necessary to identify clients, applications that use 439 HTTP MAY use HTTP authentication [RFC7235]; if the Basic 440 authentication scheme [RFC7617] is used, it MUST NOT be used with the 441 'http' URL scheme. 443 In either case, it is important to carefully specify the scoping and 444 use of these mechanisms; if they expose sensitive data or 445 capabilities (e.g., by acting as an ambiant authority), exploits are 446 possible. Mitigations include using a request-specific token to 447 assure the intent of the client. 449 4.5. HTTP Methods 451 Applications that use HTTP MUST confine themselves to using 452 registered HTTP methods such as GET, POST, PUT, DELETE, and PATCH. 454 New HTTP methods are rare; they are required to be registered with 455 IETF Review (see [RFC7232]), and are also required to be _generic_. 456 That means that they need to be potentially applicable to all 457 resources, not just those of one application. 459 While historically some applications (e.g., [RFC6352] and [RFC4791]) 460 have defined non-generic methods, [RFC7231] now forbids this. 462 When it is believed that a new method is required, authors are 463 encouraged to engage with the HTTP community early, and document 464 their proposal as a separate HTTP extension, rather than as part of 465 an application's specification. 467 4.6. HTTP Status Codes 469 Applications that use HTTP MUST only use registered HTTP status 470 codes. 472 As with methods, new HTTP status codes are rare, and required (by 473 [RFC7231]) to be registered with IETF review. Similarly, HTTP status 474 codes are generic; they are required (by [RFC7231]) to be potentially 475 applicable to all resources, not just to those of one application. 477 When it is believed that a new status code is required, authors are 478 encouraged to engage with the HTTP community early, and document 479 their proposal as a separate HTTP extension, rather than as part of 480 an application's specification. 482 Status codes' primary function is to convey HTTP semantics for the 483 benefit of generic HTTP software, not application-specific semantics. 484 Therefore, applications MUST NOT specify additional semantics or 485 refine existing semantics for status codes. 487 In particular, specifying that a particular status code has a 488 specific meaning in the context of an application is harmful, as 489 these are not generic semantics, since the consumer needs to be in 490 the context of the application to understand them. 492 Furthermore, applications using HTTP MUST NOT re-specify the 493 semantics of HTTP status codes, even if it is only by copying their 494 definition. They MUST NOT require specific status phrases to be 495 used; the status phrase has no function in HTTP, and is not 496 guaranteed to be preserved by implementations. 498 Typically, applications using HTTP will convey application-specific 499 information in the message body and/or HTTP header fields, not the 500 status code. 502 Specifications sometimes also create a "laundry list" of potential 503 status codes, in an effort to be helpful. The problem with doing so 504 is that such a list is never complete; for example, if a network 505 proxy is interposed, the client might encounter a "407 Proxy 506 Authentication Required" response; or, if the server is rate limiting 507 the client, it might receive a "429 Too Many Requests" response. 509 Since the list of HTTP status codes can be added to, it's safer to 510 refer to it directly, and point out that clients SHOULD be able to 511 handle all applicable protocol elements gracefully (i.e., falling 512 back to the generic "n00" semantics of a given status code; e.g., 513 "499" can be safely handled as "400" by clients that don't recognise 514 it). 516 4.7. HTTP Header Fields 518 Applications that use HTTP MAY define new HTTP header fields, 519 following the advice in [RFC7321], Section 8.3.1. 521 Typically, using HTTP header fields is appropriate in a few different 522 situations: 524 o Their content is useful to intermediaries (who often wish to avoid 525 parsing the body), and/or 527 o Their content is useful to generic HTTP software (e.g., clients, 528 servers), and/or 530 o It is not possible to include their content in the message body 531 (usually because a format does not allow it). 533 If none of these motivations apply, using a header field is NOT 534 RECOMMENDED. 536 New header fields MUST be registered, as per [RFC7231] and [RFC3864]. 538 It is RECOMMENDED that header field names be short (even when HTTP/2 539 header compression is in effect, there is an overhead) but 540 appropriately specific. In particular, if a header field is specific 541 to an application, an identifier for that application SHOULD form a 542 prefix to the header field name, separated by a "-". 544 The semantics of existing HTTP header fields MUST NOT be re-defined 545 without updating their registration or defining an extension to them 546 (if allowed). For example, an application using HTTP cannot specify 547 that the "Location" header has a special meaning in a certain 548 context. 550 See Section 4.4 for requirements regarding header fields that carry 551 application state (e.g,. Cookie). 553 5. IANA Considerations 555 This document has no requirements for IANA. 557 6. Security Considerations 559 Section 4.4 discusses the impact of using stateful mechanisms in the 560 protocol as ambiant authority, and suggests a mitigation. 562 Section 4.3.2 requires support for 'https' URLs, and discourages the 563 use of 'http' URLs, to mitigate pervasive monitoring attacks. 565 7. References 567 7.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 575 Procedures for Message Header Fields", BCP 90, RFC 3864, 576 DOI 10.17487/RFC3864, September 2004, 577 . 579 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 580 DOI 10.17487/RFC5988, October 2010, 581 . 583 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 584 Specifications and Registration Procedures", BCP 13, 585 RFC 6838, DOI 10.17487/RFC6838, January 2013, 586 . 588 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 589 Protocol (HTTP/1.1): Message Syntax and Routing", 590 RFC 7230, DOI 10.17487/RFC7230, June 2014, 591 . 593 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 594 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 595 DOI 10.17487/RFC7231, June 2014, 596 . 598 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 599 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 600 DOI 10.17487/RFC7232, June 2014, 601 . 603 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 604 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 605 RFC 7233, DOI 10.17487/RFC7233, June 2014, 606 . 608 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 609 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 610 RFC 7234, DOI 10.17487/RFC7234, June 2014, 611 . 613 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 614 "Transport Layer Security (TLS) Application-Layer Protocol 615 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 616 July 2014, . 618 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 619 RFC 7320, DOI 10.17487/RFC7320, July 2014, 620 . 622 [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm 623 Implementation Requirements and Usage Guidance for 624 Encapsulating Security Payload (ESP) and Authentication 625 Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, 626 . 628 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 629 DOI 10.17487/RFC7322, September 2014, 630 . 632 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 633 and C. Pignataro, "MPLS Forwarding Compliance and 634 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 635 August 2014, . 637 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 638 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 639 DOI 10.17487/RFC7540, May 2015, 640 . 642 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 643 and Registration Procedures for URI Schemes", BCP 35, 644 RFC 7595, DOI 10.17487/RFC7595, June 2015, 645 . 647 7.2. Informative References 649 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 650 RFC 793, DOI 10.17487/RFC0793, September 1981, 651 . 653 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 654 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 655 1983, . 657 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 658 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 659 . 661 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 662 RFC 2821, DOI 10.17487/RFC2821, April 2001, 663 . 665 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 666 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 667 DOI 10.17487/RFC4791, March 2007, 668 . 670 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 671 Uniform Resource Identifiers (URIs)", RFC 5785, 672 DOI 10.17487/RFC5785, April 2010, 673 . 675 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 676 DOI 10.17487/RFC6265, April 2011, 677 . 679 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 680 Authoring and Versioning (WebDAV)", RFC 6352, 681 DOI 10.17487/RFC6352, August 2011, 682 . 684 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 685 RFC 6455, DOI 10.17487/RFC6455, December 2011, 686 . 688 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 689 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 690 2014, . 692 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 693 Protocol (HTTP/1.1): Authentication", RFC 7235, 694 DOI 10.17487/RFC7235, June 2014, 695 . 697 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 698 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 699 2014, . 701 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 702 RFC 7617, DOI 10.17487/RFC7617, September 2015, 703 . 705 Author's Address 707 Mark Nottingham 709 Email: mnot@mnot.net 710 URI: https://www.mnot.net/