idnits 2.17.1 draft-snell-http-prefer-17.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 : ---------------------------------------------------------------------------- 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 5, 2012) is 4190 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) == Unused Reference: 'RFC2026' is defined on line 691, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-21 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft November 5, 2012 4 Intended status: Standards Track 5 Expires: May 9, 2013 7 Prefer Header for HTTP 8 draft-snell-http-prefer-17 10 Abstract 12 This specification defines an HTTP header field that can be used by a 13 client to request that certain behaviors be employed by a server 14 while processing a request. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 9, 2013. 33 Copyright Notice 35 Copyright (c) 2012 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 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 52 2. The Prefer Request Header Field . . . . . . . . . . . . . . . 4 53 2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3. The Preference-Applied Response Header Field . . . . . . . . . 7 55 4. Preference Definitions . . . . . . . . . . . . . . . . . . . . 8 56 4.1. The "respond-async" Preference . . . . . . . . . . . . . . 8 57 4.2. The "return=representation" and "return=minimal" 58 Preferences . . . . . . . . . . . . . . . . . . . . . . . 9 59 4.3. The "wait" Preference . . . . . . . . . . . . . . . . . . 11 60 4.4. The "handling=strict" and "handling=lenient" 61 Processing Preferences . . . . . . . . . . . . . . . . . . 12 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 63 5.1. The Registry of Preferences . . . . . . . . . . . . . . . 13 64 5.2. Initial Registry Contents . . . . . . . . . . . . . . . . 14 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 Within the course of processing an HTTP request there are typically a 74 range of required and optional behaviors that a server or 75 intermediary can employ. These often manifest in a variety of subtle 76 and not-so-subtle ways within the response. 78 For example, when using the HTTP PUT method to modify a resource -- 79 similar to that defined for the Atom Publishing Protocol [RFC5023] -- 80 the server is given the option of returning either a complete 81 representation of a modified resource or a minimal response that 82 indicates only the successful completion of the operation. The 83 selection of which type of response to return to the client generally 84 has no bearing on the successful processing of the request but could, 85 for instance, have an impact on what actions the client must take 86 after receiving the response. That is, returning a representation of 87 the modified resource within the response can allow the client to 88 avoid sending an additional subsequent GET request. 90 Similarly, servers that process requests are often faced with 91 decisions about how to process requests that may be technically 92 invalid or incorrect but are still understandable. It might be the 93 case that the server is able to overlook the technical errors in the 94 request but still successfully process the request. Depending on the 95 specific requirements of the application and the nature of the 96 request being made, the client might or might not consider such 97 lenient processing of its request to be appropriate. 99 While the decision of exactly which behaviors to apply in these cases 100 lies with the server processing the request, the server might wish to 101 defer to the client to specify which optional behavior is preferred. 103 Currently, HTTP offers no explicitly defined means of expressing the 104 client's preferences regarding the optional aspects of handling of a 105 given request. While HTTP does provide the Expect header -- which 106 can be used to identify mandatory expectations for the processing of 107 a request -- use of the field to communicate optional preferences is 108 problematic: 109 1. The semantics of the Expect header field are such that 110 intermediaries and servers are required to reject any request 111 that states unrecognized or unsupported expectations. 112 2. While the Expect header field is end-to-end, the HTTP 113 specification requires that the header be processed hop-by-hop. 114 That is, every interceding intermediary that handles a request 115 between the client and the origin server is required to process 116 an expectation and determine whether it is capable of 117 appropriately handling it. 119 The rigid, must-understand semantics of the Expect header, therefore, 120 make it a poor choice for the general expression of optional 121 preferences that may be specific to an individual application and are 122 therefore unknown to an intermediary or are otherwise irrelevant to 123 the intermediaries successful handling of the request and response. 125 Another option available to clients is to utilize Request URI query- 126 string parameters to express preferences. Doing so, however, results 127 in a variety of issues affecting the cacheability of responses. 129 As an alternative, this specification defines a new HTTP request 130 header field that can be used by clients to request that optional 131 behaviors be applied by a server during the processing the request. 132 Additionally, a handful of initial preference tokens for use with the 133 new header are defined. 135 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 136 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 137 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 139 1.1. Syntax Notation 141 This specification uses the Augmented Backus-Naur Form (ABNF) 142 notation of [RFC5234] and includes, by reference, the "token", 143 "word", "OWS", "BWS" rules and the #rule extension as defined within 144 Sections 3.2.1 and 3.2.4 of [I-D.ietf-httpbis-p1-messaging]; as well 145 as the "delta-seconds" rule defined in Section 8.3.1 of 146 [I-D.ietf-httpbis-p2-semantics]. 148 2. The Prefer Request Header Field 150 The Prefer request header field is used to indicate that particular 151 server behaviors are preferred by the client, but not required for 152 successful completion of the request. Prefer is similar in nature to 153 the Expect header field defined by Section 6.1.2 of 154 [I-D.ietf-httpbis-p2-semantics] with the exception that servers are 155 allowed to ignore stated preferences. 157 ABNF: 159 Prefer = "Prefer" ":" 1#preference 160 preference = token [ BWS "=" BWS word ] 161 *( OWS ";" [ OWS parameter ] ) 162 parameter = token [ BWS "=" BWS word ] 164 This header field is defined with an extensible syntax to allow for 165 future values included in the Registry of Preferences (Section 5.1). 167 A server that does not recognize or is unable to comply with 168 particular preference tokens in the Prefer header field of a request 169 MUST ignore those tokens and continue processing instead of 170 signalling an error. 172 A preference token can contain a value. Empty, or zero length values 173 on both the preference token and within parameters are equivalent to 174 no value being specified at all. The following, then, are equivalent 175 examples of a "foo" preference with a single "bar" parameter. 177 Prefer: foo; bar 178 Prefer: foo; bar="" 179 Prefer: foo=""; bar 181 An optional set of parameters can be specified for any preference 182 token. The meaning and application of such parameters is dependent 183 on the definition of each preference token and the server's 184 implementation thereof. There is no significance given to the 185 ordering of parameters on any given preference. 187 For both preference token names and parameter names, comparison is 188 case-insensitive while values are case-sensitive regardless of 189 whether token or quoted-string values are used. 191 The Prefer header field is end-to-end and MUST be forwarded by a 192 proxy if the request is forwarded unless Prefer is explicitly 193 identified as being hop-by-hop using the Connection header field 194 defined by [I-D.ietf-httpbis-p1-messaging], Section 6.1. 196 In various situations, a proxy might determine that it is capable of 197 honoring a preference independently of the server to which the 198 request has been directed. For instance, an intervening proxy might 199 be capable of providing asynchronous handling of a request using 202 200 Accepted responses independently of the origin server. Such proxies 201 can choose to honor the "respond-async" preference on their own 202 despite whether the origin is capable or willing to do so. 204 Individual preference tokens MAY define their own requirements and 205 restrictions as to whether and how intermediaries can apply the 206 preference to a request independently of the origin server. 208 A client MAY use multiple instances of the Prefer header field in a 209 single message, or it MAY use a single Prefer header field with 210 multiple comma-separated preference tokens. If multiple Prefer 211 header fields are used, it is equivalent to a single Prefer header 212 filed with the comma-separated concatentation of all of the tokens. 213 For example, the following are equivalent: 215 Multiple Prefer header fields defining three distinct preference 216 tokens: 218 POST /foo HTTP/1.1 219 Host: example.org 220 Prefer: respond-async, wait=100 221 Prefer: handling=lenient 222 Date: Tue, 20 Dec 2011 12:34:56 GMT 224 A single Prefer header field defining the same three preference 225 tokens: 227 POST /foo HTTP/1.1 228 Host: example.org 229 Prefer: handling=lenient, wait=100, respond-async 230 Date: Tue, 20 Dec 2011 12:34:56 GMT 232 To avoid any possible ambiguity, individual preference tokens SHOULD 233 NOT appear multiple times within a single request. If any preference 234 is specified more than once, only the first instance is to be 235 considered. All subsequent occurrences SHOULD be ignored without 236 signaling an error or otherwise altering the processing of the 237 request. This is the only case in which the ordering of preferences 238 within a request is considered to be significant. 240 Due to the inherent complexities involved with properly implementing 241 server-driven content negotiation, effective caching, and the 242 application of optional preferences, implementors are urged to 243 exercise caution when using preferences in a way that impacts the 244 caching of a response and SHOULD NOT use the Prefer header mechanism 245 for content negotiation. If a server supports the optional 246 application of a preference that might result in a variance to a 247 cache's handling of a response entity, a Vary header field MUST be 248 included in the response listing the Prefer header field regardless 249 of whether the client actually used Prefer in the request. 250 Alternatively, the server MAY include a Vary header with the special 251 value "*" as defined by [I-D.ietf-httpbis-p2-semantics], Section 252 8.2.1. Note, however, that use of the "Vary: *" header will make it 253 impossible for a proxy to cache the response. 255 Note that while Preference tokens are similar in structure to HTTP 256 Expect tokens, the Prefer and Expect header fields serve very 257 distinct purposes and preferences cannot be used as expectations. 259 2.1. Examples 261 The following examples illustrate the use of various preferences 262 defined by this specification, as well as undefined extensions for 263 strictly illustrative purposes: 265 1. Return a "202 Accepted" response for asynchronous processing if 266 the request cannot be processed within 10 seconds. An undefined 267 "priority" preference is also specified: 269 POST /some-resource HTTP/1.1 270 Host: example.org 271 Content-Type: text/plain 272 Prefer: respond-async, wait=10 273 Prefer: priority=5 275 {...} 277 2. Use lenient processing: 279 POST /some-resource HTTP/1.1 280 Host: example.org 281 Content-Type: text/plain 282 Prefer: Lenient 284 {...} 286 3. Use of an optional, undefined parameter on the return=minimal 287 preference: 289 POST /some-resource HTTP/1.1 290 Host: example.org 291 Content-Type: text/plain 292 Prefer: return=minimal; foo="some parameter" 294 {...} 296 3. The Preference-Applied Response Header Field 298 The Preference-Applied response header MAY be included within a 299 response message as an indication as to which Prefer tokens were 300 honored by the server and applied to the processing of a request. 302 ABNF: 304 Preference-Applied = "Preference-Applied" ":" 1#applied-pref 305 applied-pref = token [ BWS "=" BWS word ] 307 The syntax of the Preference-Applied header differs from that of the 308 Prefer header in that parameters are not included. 310 Use of the Preference-Applied header is only necessary when it is not 311 readily and obviously apparent that a server applied a given 312 preference and such ambiguity might have an impact on the client's 313 handling of the response. For instance, when using either the 314 "return=representation" or "return=minimal" preferences, a client 315 application might not be capable of reliably determining if the 316 preference was (or was not) applied simply by examining the payload 317 of the response. In such case the Preference-Applied header field 318 can be used. 320 Request: 322 PATCH /my-document HTTP/1.1 323 Host: example.org 324 Content-Type: application/json-patch 325 Prefer: return=representation 327 [{"op": "add", "path": "/a", "value": 1}] 329 Response: 331 HTTP/1.1 200 OK 332 Content-Type: application/json 333 Preference-Applied: return=representation 334 Content-Location: /my-document 336 {"a": 1} 338 4. Preference Definitions 340 The following subsections define an initial set of preferences. 341 Additional preferences can be registered for convenience and/or to 342 promote reuse by other applications. This specification establishes 343 an IANA registry of preferences (see Section 5.1). 345 4.1. The "respond-async" Preference 347 The "respond-async" preference indicates that the client prefers the 348 server to respond asynchronously to a response. For instance, in the 349 case when the length of time it takes to generate a response will 350 exceed some arbitrary threshold established by the server, the server 351 can honor the respond-async preference by returning a "202 Accepted" 352 response. 354 ABNF: 356 respond-async = "respond-async" 358 The key motivation for the "respond-async" preference is to 359 facilitate the operation of asynchronous request handling by allowing 360 the client to indicate to a server its capability and preference for 361 handling asynchronous responses. 363 An example request specifying the "respond-async" preference: 365 POST /collection HTTP/1.1 366 Host: example.org 367 Content-Type: text/plain 368 Prefer: respond-async 370 {Data} 372 An example asynchronous response using "202 Accepted": 374 HTTP/1.1 202 Accepted 375 Location: http://example.org/collection/123 377 While the "202 Accepted" response status is defined by 378 [I-D.ietf-httpbis-p2-semantics], little guidance is given on how and 379 when to use the response code and the process for determining the 380 subsequent final result of the operation is left entirely undefined. 381 Therefore, whether and how any given server supports asynchronous 382 responses is an implementation specific detail that is considered to 383 be out of the scope of this specification. 385 4.2. The "return=representation" and "return=minimal" Preferences 387 The "return=representation" preference indicates that the client 388 prefers that the server include an entity representing the current 389 state of the resource in the response to a successful request. 391 The "return=minimal" preference, on the other hand, indicates that 392 the client wishes the server to return only a minimal response to a 393 successful request. Typically, such responses would utilize the "204 394 No Content" status, but other codes MAY be used as appropriate, such 395 as a "200" status with a zero-length response entity. The 396 determination of what constitutes an appropriate minimal response is 397 solely at the discretion of the server. 399 ABNF: 401 return = "return" BWS "=" BWS ("representation" / "minimal") 403 When honoring the "return=representation" preference, the returned 404 representation might not be a representation of the effective request 405 URI when the request is affecting another resource. In such cases, 406 the Content-Location header can be used to identify the URI of the 407 returned representation. 409 The "return=representation" preference is intended to provide a means 410 of optimizing communication between the client and server by 411 eliminating the need for a subsequent GET request to retrieve the 412 current representation of the resource following a modification. 414 After successfully processing a modification request such as a POST 415 or PUT, a server can choose to return either an entity describing the 416 status of the operation or a representation of the modified resource 417 itself. While the selection of which type of entity to return, if 418 any at all, is solely at the discretion of the server, the 419 "return=representation" preference -- along with the "return=minimal" 420 preference defined below -- allow the server to take the client's 421 preferences into consideration while constructing the response. 423 An example request specifying the "return=representation" preference: 425 PATCH /item/123 HTTP/1.1 426 Host: example.org 427 Content-Type: text/patch 428 Prefer: return=representation 430 1c1 431 < ABCDEFGHIJKLMNOPQRSTUVWXYZ 432 --- 433 > BCDFGHJKLMNPQRSTVWXYZ 435 An example response containing the resource representation: 437 HTTP/1.1 200 OK 438 Content-Location: http://example.org/item/123 439 Content-Type: text/plain 440 ETag: "d3b07384d113edec49eaa6238ad5ff00" 442 BCDFGHJKLMNPQRSTVWXYZ 444 In contrast, the "return=minimal" preference can reduce the amount of 445 data the server is required to return to the client following a 446 request. This can be particularly useful, for instance, when 447 communicating with limited-bandwidth mobile devices or when the 448 client simply does not require any further information about the 449 result of a request beyond knowing if it was successfully processed. 451 An example request specifying the "return=minimal" preference: 453 POST /collection HTTP/1.1 454 Host: example.org 455 Content-Type: text/plain 456 Prefer: return=minimal 458 {Data} 460 An example minimal response: 462 HTTP/1.1 201 Created 463 Location: http://example.org/collection/123 465 The "return=minimal" and "return=representation" preferences are 466 mutually exclusive directives. It is anticipated that there will 467 never be a situation where it will make sense for a single request to 468 include both preferences. Any such requests will likely be the 469 result of a coding error within the client. As such, a request 470 containing both preferences can be treated as though neither were 471 specified. 473 4.3. The "wait" Preference 475 The "wait" preference can be used to establish an upper bound on the 476 length of time, in seconds, the client expects it will take the 477 server to process the request once it has been received. In the case 478 that generating a response will take longer than the time specified, 479 the server, or proxy, can choose to utilize an asynchronous 480 processing model by returning -- for example -- a "202 Accepted" 481 response. 483 ABNF: 485 wait = "wait" BWS "=" BWS delta-seconds 487 It is important to consider that HTTP messages spend some time 488 traversing the network and being processed by intermediaries. This 489 increases the length of time that a client will wait for a response 490 in addition to the time the server takes to process the request. A 491 client that has strict timing requirements can estimate these factors 492 and adjust the wait value accordingly. 494 As with other preferences, the "wait" preference could be ignored. 495 Clients can abandon requests that take longer than they are prepared 496 to wait. 498 For example, a server receiving the following request might choose to 499 respond asynchronously if processing the request will take longer 500 than 10 seconds: 502 POST /collection HTTP/1.1 503 Host: example.org 504 Content-Type: text/plain 505 Prefer: respond-async, wait=10 507 {Data} 509 4.4. The "handling=strict" and "handling=lenient" Processing 510 Preferences 512 The "handling=strict" and "handling=lenient" preferences indicate, at 513 the server's discretion, how the client wishes the server to handle 514 potential error conditions that can arise in the processing of a 515 request. For instance, if the payload of a request contains various 516 minor syntactical or semantic errors, but the server is still capable 517 of comprehending and successfully processing the request, a decision 518 must be made to either reject the request with an appropriate "4xx" 519 error response or go ahead with processing. The "handling=strict" 520 preference can be used to indicate that, while any particular error 521 may be recoverable, the client would prefer that the server reject 522 the request. The "handling=lenient" preference, on the other hand, 523 indicates that the client wishes the server to attempt to process the 524 request. 526 ABNF: 528 handling = "handling" BWS "=" BWS ("strict" / "lenient") 530 An example request specifying the "strict" preference: 532 POST /collection HTTP/1.1 533 Host: example.org 534 Content-Type: text/plain 535 Prefer: handling=strict 537 The "handling=strict" and "handling=lenient" preferences are mutually 538 exclusive directives. It is anticipated that there will never be a 539 situation where it will make sense for a single request to include 540 both preferences. Any such requests will likely be the result of a 541 coding error within the client. As such, a request containing both 542 preferences can be treated as though neither were specified. 544 5. IANA Considerations 546 The 'Prefer' and 'Preference-Applied' header fields should be added 547 to the Permanent Message Header Fields registry defined in [RFC3864] 548 (http://www.iana.org/assignments/message-headers/perm-headers.html). 550 Header field name: Prefer 551 Applicable Protocol: HTTP 552 Status: Standard 553 Author: James M Snell 554 Change controller: IETF 555 Specification document: this specification, Section 2 557 Header field name: Preference-Applied 558 Applicable Protocol: HTTP 559 Status: Standard 560 Author: James M Snell 561 Change controller: IETF 562 Specification document: this specification, Section 3 564 5.1. The Registry of Preferences 566 IANA is asked to create a new registry, "HTTP Preferences", under the 567 Hypertext Transfer Protocol (HTTP) Parameters group. New 568 registrations will use the Specification Required policy [RFC5226]. 569 The requirements for registered preferences are described in 570 Section 4. 572 Registration requests consist of the completed registration template 573 below, typically published in the required specification. However, 574 to allow for the allocation of values prior to publication, the 575 Designated Expert can approve registration based on a separately 576 submitted template once they are satisfied that a specification will 577 be published. Preferences can be registered by third parties if the 578 Designated Expert determines that an unregistered preference is 579 widely deployed and not likely to be registered in a timely manner. 581 The registration template is: 583 o Preference: (A value for the Prefer request header field that 584 conforms to the syntax rule given in Section 2) 585 o Value: (An enumeration or description of possible values for the 586 preference token). 587 o Optional Parameters: (An enumeration of optional parameters, and 588 their values, associated with the the preference token). 589 o Description: 591 o Reference: 592 o Notes: [optional] 594 The "Value" and "Optional Parameters" fields MAY be omitted from the 595 registration template if the specific preference token definition 596 does not define either. 598 Registration requests should be sent to the ietf-http-wg@w3.org 599 mailing list, marked clearly in the subject line (e.g., "NEW 600 PREFERENCE - example" to register an "example" preference). Within 601 at most 14 days of the request, the Designated Expert(s) will either 602 approve or deny the registration request, communicating this decision 603 to the review list and IANA. Denials should include an explanation 604 and, if applicable, suggestions as to how to make the request 605 successful. 607 The Expert Reviewer shall ensure: 608 o That the requested preference name conforms to the token rule in 609 Section 2 and that it is not identical to any other registered 610 preference name; 611 o That any associated value, parameter names, and values conform to 612 the relevant ABNF grammar specifications in Section 2; 613 o That the name is appropriate to the specificity of the preference; 614 i.e., if the semantics are highly specific to a particular 615 application, the name should reflect that, so that more general 616 names remain available for less specific use. 617 o That requested preferences do not constrain servers, clients or 618 any intermediaries to any behavior required for successful 619 processing; and 620 o That the specification document defining the preference includes a 621 proper and complete discussion of any security considerations 622 relevant to the use of the preference. 624 5.2. Initial Registry Contents 626 The Preferences Registry's initial contents are: 628 o Preference: respond-async 629 o Description: Indicates that the client prefers the server to 630 respond asynchronously to a request. 631 o Reference: [this specification], Section 4.1 633 o Preference: return 634 o Value: One of either "minimal" or "representation" 635 o Description: When value is "minimal", indicates that the client 636 prefers the server return a minimal response to a request. When 637 value is "representation", indicates that the client prefers the 638 server to include a representation of the current state of the 639 resource in response to a request. 640 o Reference: [this specification], Section 4.2 642 o Preference: wait 643 o Description: Indicates an upper bound to the length of time the 644 client expects it will take the server to process the request once 645 it has been received. 646 o Reference: [this specification], Section 4.3 648 o Preference: handling 649 o Value: One of either "strict" or "lenient" 650 o Description: When value is "strict", indicates that the client 651 wishes the server to apply strict validation and error handling to 652 the processing of a request. When value is "lenient", indicates 653 that the client wishes the server to apply lenient validation and 654 error handling to the processing of the request. 655 o Reference: [this specification], Section 4.4 657 6. Security Considerations 659 Specific preferences requested by a client can introduce security 660 considerations and concerns beyond those discussed within HTTP/1.1 661 [I-D.ietf-httpbis-p1-messaging] and it's additional associated 662 specification documents. Implementers need to refer to the 663 specifications and descriptions of each preference to determine the 664 security considerations relevant to each. 666 A server could incur greater costs in attempting to comply with a 667 particular preference (for instance, the cost of providing a 668 representation in a response that would not ordinarily contain one; 669 or the commitment of resources necessary to track state for an 670 asynchronous response). Unconditional compliance from a server could 671 allow the use of preferences for denial of service. A server can 672 ignore an expressed preference to avoid expending resources that it 673 does not wish to commit. 675 7. References 677 7.1. Normative References 679 [I-D.ietf-httpbis-p1-messaging] 680 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 681 (HTTP/1.1): Message Syntax and Routing", 682 draft-ietf-httpbis-p1-messaging-21 (work in progress), 683 October 2012. 685 [I-D.ietf-httpbis-p2-semantics] 686 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 687 (HTTP/1.1): Semantics and Content", 688 draft-ietf-httpbis-p2-semantics-21 (work in progress), 689 October 2012. 691 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 692 3", BCP 9, RFC 2026, October 1996. 694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 695 Requirement Levels", BCP 14, RFC 2119, March 1997. 697 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 698 Procedures for Message Header Fields", BCP 90, RFC 3864, 699 September 2004. 701 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 702 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 703 May 2008. 705 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 706 Specifications: ABNF", STD 68, RFC 5234, January 2008. 708 7.2. Informative References 710 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 711 Protocol", RFC 5023, October 2007. 713 Author's Address 715 James M Snell 717 Email: jasnell@gmail.com