idnits 2.17.1 draft-snell-http-prefer-15.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 (October 12, 2012) is 4213 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 641, 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 October 12, 2012 4 Intended status: Standards Track 5 Expires: April 15, 2013 7 Prefer Header for HTTP 8 draft-snell-http-prefer-15 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 April 15, 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 "return-asynch" 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 "strict" and "lenient" Processing Preferences . . . . 12 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 5.1. The Registry of Preferences . . . . . . . . . . . . . . . 13 63 5.2. Initial Registry Contents . . . . . . . . . . . . . . . . 14 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 1. Introduction 72 Within the course of processing an HTTP request there are typically a 73 range of required and optional behaviors that a server or 74 intermediary can employ. These often manifest in a variety of subtle 75 and not-so-subtle ways within the response. 77 For example, when using the HTTP PUT method to modify a resource -- 78 similar to that defined for the Atom Publishing Protocol [RFC5023] -- 79 the server is given the option of returning either a complete 80 representation of a modified resource or a minimal response that 81 indicates only the successful completion of the operation. The 82 selection of which type of response to return to the client generally 83 has no bearing on the successful processing of the request but could, 84 for instance, have an impact on what actions the client must take 85 after receiving the response. That is, returning a representation of 86 the modified resource within the response can allow the client to 87 avoid sending an additional subsequent GET request. 89 Similarly, servers that process requests are often faced with 90 decisions about how to process requests that may be technically 91 invalid or incorrect but are still understandable. It might be the 92 case that the server is able to overlook the technical errors in the 93 request but still successfully process the request. Depending on the 94 specific requirements of the application and the nature of the 95 request being made, the client might or might not consider such 96 lenient processing of its request to be appropriate. 98 While the decision of exactly which behaviors to apply in these cases 99 lies with the server processing the request, the server might wish to 100 defer to the client to specify which optional behavior is preferred. 102 Currently, HTTP offers no explicitly defined means of expressing the 103 client's preferences regarding the optional aspects of handling of a 104 given request. While HTTP does provide the Expect header -- which 105 can be used to identify mandatory expectations for the processing of 106 a request -- use of the field to communicate optional preferences is 107 problematic: 108 1. The semantics of the Expect header field are such that 109 intermediaries and servers are required to reject any request 110 that states unrecognized or unsupported expectations. 111 2. While the Expect header field is end-to-end, the HTTP 112 specification requires that the header be processed hop-by-hop. 113 That is, every interceding intermediary that handles a request 114 between the client and the origin server is required to process 115 an expectation and determine whether it is capable of 116 appropriately handling it. 118 The rigid, must-understand semantics of the Expect header, therefore, 119 make it a poor choice for the general expression of optional 120 preferences that may be specific to an individual application and are 121 therefore unknown to an intermediary or are otherwise irrelevant to 122 the intermediaries successful handling of the request and response. 124 Another option available to clients is to utilize Request URI query- 125 string parameters to express preferences. Doing so, however, results 126 in a variety of issues affecting the cacheability of responses. 128 As an alternative, this specification defines a new HTTP request 129 header field that can be used by clients to request that optional 130 behaviors be applied by a server during the processing the request. 131 Additionally, a handful of initial preference tokens for use with the 132 new header are defined. 134 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 135 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 136 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 138 1.1. Syntax Notation 140 This specification uses the Augmented Backus-Naur Form (ABNF) 141 notation of [RFC5234] and includes, by reference, the "token", 142 "word", "OWS", "BWS" rules and the #rule extension as defined within 143 Sections 3.2.1 and 3.2.4 of [I-D.ietf-httpbis-p1-messaging]. 145 2. The Prefer Request Header Field 147 The Prefer request header field is used to indicate that particular 148 server behaviors are preferred by the client, but not required for 149 successful completion of the request. Prefer is similar in nature to 150 the Expect header field defined by Section 6.1.2 of 151 [I-D.ietf-httpbis-p2-semantics] with the exception that servers are 152 allowed to ignore stated preferences. 154 ABNF: 156 Prefer = "Prefer" ":" 1#preference 157 preference = token [ BWS "=" BWS word ] 158 *( OWS ";" [ OWS parameter ] ) 159 parameter = token [ BWS "=" BWS word ] 161 This header field is defined with an extensible syntax to allow for 162 future values included in the Registry of Preferences (Section 5.1). 163 A server that does not recognize or is unable to comply with 164 particular preference tokens in the Prefer header field of a request 165 MUST ignore those tokens and continue processing instead of 166 signalling an error. 168 A preference token can contain a value. Empty, or zero length values 169 on both the preference token and within parameters are equivalent to 170 no value being specified at all. The following, then, are 171 equivalent: 173 Prefer: foo; bar 174 Prefer: foo; bar="" 175 Prefer: foo=""; bar 177 An optional set of parameters can be specified for any preference 178 token. The meaning and application of such parameters is dependent 179 on the definition of each preference token and the server's 180 implementation thereof. 182 Comparison of preference token names is case-insensitive while values 183 are case-sensitive regardless of whether token or quoted-string 184 values are used. 186 The Prefer header field is end-to-end and SHOULD be forwarded by a 187 proxy if the request is forwarded unless Prefer is explicitly 188 identified as being hop-by-hop using the Connection header field 189 defined by [I-D.ietf-httpbis-p1-messaging], Section 6.1. 191 In various situations, a proxy might determine that it is capable of 192 honoring a preference independently of the server to which the 193 request has been directed. For instance, an intervening proxy might 194 be capable of providing asynchronous handling of a request using 202 195 Accepted responses independently of the origin server. Such proxies 196 can choose to honor the "return-asynch" preference on their own 197 despite whether the origin is capable or willing to do so. 199 Individual preference tokens MAY define their own requirements and 200 restrictions as to whether and how intermediaries can apply the 201 preference to a request independently of the origin server. 203 Implementations MUST support multiple instances of the Prefer header 204 field in a single message, as well as multiple preference tokens 205 separated by commas in a single Prefer header field. The following 206 examples are equivalent: 208 Multiple Prefer Header Fields: 210 POST /foo HTTP/1.1 211 Host: example.org 212 Prefer: return-asynch 213 Prefer: wait=100 214 Date: Tue, 20 Dec 2011 12:34:56 GMT 216 Single Prefer Header Field: 218 POST /foo HTTP/1.1 219 Host: example.org 220 Prefer: wait=100, return-asynch 221 Date: Tue, 20 Dec 2011 12:34:56 GMT 223 To avoid possible ambiguity, individual preference tokens SHOULD NOT 224 appear multiple times within a single request. If any preference is 225 specified more than once, only the first instance is to be 226 considered. All subsequent occurrences SHOULD be ignored without 227 signaling an error or otherwise altering the processing of the 228 request. This is the only case in which the ordering of preferences 229 within a request is considered to be significant. 231 Due to the inherent complexities involved with properly implementing 232 server-driven content negotiation, effective caching, and the 233 application of optional preferences, implementors are urged to 234 exercise caution when using preferences in a way that impacts the 235 caching of a response and SHOULD NOT use the Prefer header mechanism 236 for content negotiation. If a server supports the optional 237 application of a preference that might result in a variance to a 238 cache's handling of a response entity, a Vary header field MUST be 239 included with the response listing the Prefer header field regardless 240 of whether the client actually used Prefer in the request. 242 2.1. Examples 244 The following examples illustrate the use of various preferences 245 defined by this specification, as well as undefined extensions for 246 strictly illustrative purposes: 248 1. Return a "202 Accepted" response for asynchronous processing if 249 the response cannot be processed within 10 seconds. An undefined 250 "priority" preference is also specified: 252 Prefer: return-asynch, wait=10; 253 Prefer: priority=5; 255 2. Use lenient processing: 257 Prefer: Lenient 259 3. Use of an optional, undefined parameter on the return-minimal 260 preference: 262 Prefer: return-minimal; foo="some parameter" 264 3. The Preference-Applied Response Header Field 266 The Preference-Applied response header MAY be included within a 267 response message as an indication as to which Prefer tokens were 268 honored by the server and applied to the processing of a request. 270 ABNF: 272 Preference-Applied = "Preference-Applied" ":" 1#token 274 The syntax of the Preference-Applied header differs from that of the 275 Prefer header in that token values and parameters are not included. 277 Use of the Preference-Applied header is only necessary when it is not 278 readily and obviously apparent that a server applied a given 279 preference and such ambiguity might have an impact on the client's 280 handling of the response. For instance, when using either the 281 "return-representation" or "return-minimal" preferences, a client 282 application might not be capable of reliably determining that the 283 preference was applied simply by examining the payload of the 284 response. In such case the Preference-Applied header field can be 285 used. 287 Request: 289 PATCH /my-document HTTP/1.1 290 Host: example.org 291 Content-Type: application/json-patch 292 Prefer: return-representation 294 [{"op": "add", "path": "/a", "value": 1}] 296 Response: 298 HTTP/1.1 200 OK 299 Content-Type: application/json 300 Preference-Applied: return-representation 301 Content-Location: /my-document 303 {"a": 1} 305 4. Preference Definitions 307 The following subsections define an initial set of preferences. 308 Additional preferences can be registered for convenience and/or to 309 promote reuse by other applications. This specification establishes 310 an IANA registry of such relation types (see Section 5.1). 312 Registered preference names MUST conform to the token rule, and MUST 313 be compared character-by-character in a case-insensitive fashion. 314 They SHOULD be appropriate to the specificity of the preference; 315 i.e., if the semantics are highly specific to a particular 316 application, the name should reflect that, so that more general names 317 remain available for less specific use. 319 Registered preferences MUST NOT constrain servers, clients or any 320 intermediaries involved in the exchange and processing of a request 321 to any behavior required for successful processing. The use and 322 application of a preference within a given request MUST be optional 323 on the part of all participants. 325 4.1. The "return-asynch" Preference 327 The "return-asynch" preference indicates that the client prefers the 328 server to respond asynchronously to a response. For instance, in the 329 case when the length of time it takes to generate a response will 330 exceed some arbitrary threshold established by the server, the server 331 can honor the return-asynch preference by returning a "202 Accepted" 332 response. 334 ABNF: 336 return-asynch = "return-asynch" 338 The key motivation for the "return-asynch" preference is to 339 facilitate the operation of asynchronous request handling by allowing 340 the client to indicate to a server its capability and preference for 341 handling asynchronous responses. 343 An example request specifying the "return-asynch" preference: 345 POST /collection HTTP/1.1 346 Host: example.org 347 Content-Type: text/plain 348 Prefer: return-asynch 350 {Data} 352 An example asynchronous response using "202 Accepted": 354 HTTP/1.1 202 Accepted 355 Location: http://example.org/collection/123 357 While the "202 Accepted" response status is defined by 358 [I-D.ietf-httpbis-p2-semantics], little guidance is given on how and 359 when to use the response code and the process for determining the 360 subsequent final result of the operation is left entirely undefined. 361 Therefore, whether and how any given server supports asynchronous 362 responses is an implementation specific detail that is considered to 363 be out of the scope of this specification. 365 4.2. The "return-representation" and "return-minimal" Preferences 367 The "return-representation" preference indicates that the client 368 prefers that the server include an entity representing the current 369 state of the resource in the response to a successful request. 371 The "return-minimal" preference, on the other hand, indicates that 372 the client wishes the server to return only a minimal response to a 373 successful request. Typically, such responses would utilize the "204 374 No Content" status, but other codes MAY be used as appropriate, such 375 as a "200" status with a zero-length response entity. The 376 determination of what constitutes an appropriate minimal response is 377 solely at the discretion of the server. 379 ABNF: 381 return-representation = "return-representation" 382 return-minimal = "return-minimal" 384 When honoring the "return-representation" preference, the returned 385 representation might not be a representation of the effective request 386 URI when the request is affecting another resource. In such cases, 387 the Content-Location header can be used to identify the URI of the 388 returned representation. 390 The "return-representation" preference is intended to provide a means 391 of optimizing communication between the client and server by 392 eliminating the need for a subsequent GET request to retrieve the 393 current representation of the resource following a modification. 395 Currently, after successfully processing a modification request such 396 as a POST or PUT, a server can choose to return either an entity 397 describing the status of the operation or a representation of the 398 modified resource itself. While the selection of which type of 399 entity to return, if any at all, is solely at the discretion of the 400 server, the "return-representation" preference -- along with the 401 "return-minimal" preference defined below -- allow the server to take 402 the client's preferences into consideration while constructing the 403 response. 405 An example request specifying the "return-representation" preference: 407 PATCH /item/123 HTTP/1.1 408 Host: example.org 409 Content-Type: text/patch 410 Prefer: return-representation 412 1c1 413 < ABCDEFGHIJKLMNOPQRSTUVWXYZ 414 --- 415 > BCDFGHJKLMNPQRSTVWXYZ 417 An example response containing the resource representation: 419 HTTP/1.1 200 OK 420 Content-Location: http://example.org/item/123 421 Preference-Applied: return-representation 422 Content-Type: text/plain 423 ETag: "d3b07384d113edec49eaa6238ad5ff00" 425 BCDFGHJKLMNPQRSTVWXYZ 427 In contrast, the "return-minimal" preference can reduce the amount of 428 data the server is required to return to the client following a 429 request. This can be particularly useful, for instance, when 430 communicating with limited-bandwidth mobile devices or when the 431 client simply does not require any further information about the 432 result of a request beyond knowing if it was successfully processed. 434 An example request specifying the "return-minimal" preference: 436 POST /collection HTTP/1.1 437 Host: example.org 438 Content-Type: text/plain 439 Prefer: return-minimal 441 {Data} 443 An example minimal response: 445 HTTP/1.1 201 Created 446 Location: http://example.org/collection/123 448 The "return-minimal" and "return-representation" preferences are 449 mutually exclusive directives. A request that contains both 450 preferences can be treated as though neither were specified. 452 4.3. The "wait" Preference 454 The "wait" preference can be used to establish an upper bound on the 455 length of time, in seconds, the client expects it will take the 456 server to process the request once it has been received. In the case 457 that generating a response will take longer than the time specified, 458 the server, or proxy, can choose to utilize an asynchronous 459 processing model by returning -- for example -- a "202 Accepted" 460 response. 462 ABNF: 464 wait = "wait" BWS "=" BWS delta-seconds 466 It is important to consider that HTTP messages spend some time 467 traversing the network and being processed by intermediaries. This 468 increases the length of time that a client will wait for a response 469 in addition to the time the server takes to process the request. A 470 client that has strict timing requirements can estimate these factors 471 and adjust the wait value accordingly. 473 As with other preferences, the "wait" preference could be ignored. 474 Clients can abandon requests that take longer than they are prepared 475 to wait. 477 For example, a server receiving the following request might choose to 478 respond asynchronously if processing the request will take longer 479 than 10 seconds: 481 POST /collection HTTP/1.1 482 Host: example.org 483 Content-Type: text/plain 484 Prefer: return-asynch, wait=10 486 {Data} 488 4.4. The "strict" and "lenient" Processing Preferences 490 The "strict" and "lenient" preferences are mutually-exclusive 491 directives indicating, at the server's discretion, how the client 492 wishes the server to handle potential error conditions that can arise 493 in the processing of a request. For instance, if the payload of a 494 request contains various minor syntactical or semantic errors, but 495 the server is still capable of comprehending and successfully 496 processing the request, a decision must be made to either reject the 497 request with an appropriate "4xx" error response or go ahead with 498 processing. The "strict" preference can be used to indicate that, 499 while any particular error may be recoverable, the client would 500 prefer that the server reject the request. The "lenient" preference, 501 on the other hand, indicates that the client wishes the server to 502 attempt to process the request. 504 ABNF: 506 handling = "strict" / "lenient" 508 An example request specifying the "strict" preference: 510 POST /collection HTTP/1.1 511 Host: example.org 512 Content-Type: text/plain 513 Prefer: strict 515 5. IANA Considerations 517 The 'Prefer' and 'Preference-Applied' header fields should be added 518 to the Permanent Message Header Fields registry defined in [RFC3864] 519 (http://www.iana.org/assignments/message-headers/perm-headers.html). 521 Header field name: Prefer 522 Applicable Protocol: HTTP 523 Status: Standard 524 Author: James M Snell 525 Change controller: IETF 526 Specification document: this specification 528 Header field name: Preference-Applied 529 Applicable Protocol: HTTP 530 Status: Standard 531 Author: James M Snell 532 Change controller: IETF 533 Specification document: this specification 535 5.1. The Registry of Preferences 537 IANA is asked to create a new registry, "HTTP Preferences", under the 538 Hypertext Transfer Protocol (HTTP) Parameters group. New 539 registrations will use the Specification Required policy [RFC5226]. 540 The requirements for registered preferences are described in 541 Section 4. 543 Registration requests consist of the completed registration template 544 below, typically published in the required specification. However, 545 to allow for the allocation of values prior to publication, the 546 Designated Expert can approve registration based on a separately 547 submitted template once they are satisfied that a specification will 548 be published. Preferences can be registered by third parties if the 549 Designated Expert determines that an unregistered preference is 550 widely deployed and not likely to be registered in a timely manner. 552 The registration template is: 554 o Preference: (A value for the Prefer request header field that 555 conforms to the syntax rule given in Section 2) 556 o Description: 557 o Reference: 558 o Notes: [optional] 560 Registration requests should be sent to the ietf-http-wg@w3.org 561 mailing list, marked clearly in the subject line (e.g., "NEW 562 PREFERENCE - example" to register an "example" preference). Within 563 at most 14 days of the request, the Designated Expert(s) will either 564 approve or deny the registration request, communicating this decision 565 to the review list and IANA. Denials should include an explanation 566 and, if applicable, suggestions as to how to make the request 567 successful. 569 5.2. Initial Registry Contents 571 The Preferences Registry's initial contents are: 573 o Preference: return-asynch 574 o Description: Indicates that the client prefers the server to 575 respond asynchronously to a request. 576 o Reference: [this specification], Section 4.1 578 o Preference: return-minimal 579 o Description: Indicates that the client prefers the server return a 580 minimal response to a request. 581 o Reference: [this specification], Section 4.2 583 o Preference: return-representation 584 o Description: Indicates that the client prefers the server to 585 include a representation of the current state of the resource in 586 response to a request. 587 o Reference: [this specification], Section 4.2 589 o Preference: wait 590 o Description: Indicates an upper bound to the length of time the 591 client expects it will take the server to process the request once 592 it has been received. 593 o Reference: [this specification], Section 4.3 595 o Preference: strict 596 o Description: Indicates that the client wishes the server to apply 597 strict validation and error handling to the processing of a 598 request. 599 o Reference: [this specification], Section 4.4 601 o Preference: lenient 602 o Description: Indicates that the client wishes the server to apply 603 lenient validation and error handling to the processing of a 604 request. 605 o Reference: [this specification], Section 4.4 607 6. Security Considerations 609 Specific preferences requested by a client can introduce security 610 considerations and concerns beyond those discussed within HTTP/1.1 611 [I-D.ietf-httpbis-p1-messaging] and it's additional associated 612 specification documents. Implementers need to refer to the 613 specifications and descriptions of each preference to determine the 614 security considerations relevant to each. 616 A server could incur greater costs in attempting to comply with a 617 particular preference (for instance, the cost of providing a 618 representation in a response that would not ordinarily contain one; 619 or the commitment of resources necessary to track state for an 620 asynchronous response). Unconditional compliance from a server could 621 allow the use of preferences for denial of service. A server can 622 ignore an expressed preference to avoid expending resources that it 623 does not wish to commit. 625 7. References 627 7.1. Normative References 629 [I-D.ietf-httpbis-p1-messaging] 630 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 631 (HTTP/1.1): Message Syntax and Routing", 632 draft-ietf-httpbis-p1-messaging-21 (work in progress), 633 October 2012. 635 [I-D.ietf-httpbis-p2-semantics] 636 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 637 (HTTP/1.1): Semantics and Content", 638 draft-ietf-httpbis-p2-semantics-21 (work in progress), 639 October 2012. 641 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 642 3", BCP 9, RFC 2026, October 1996. 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, March 1997. 647 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 648 Procedures for Message Header Fields", BCP 90, RFC 3864, 649 September 2004. 651 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 652 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 653 May 2008. 655 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 656 Specifications: ABNF", STD 68, RFC 5234, January 2008. 658 7.2. Informative References 660 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 661 Protocol", RFC 5023, October 2007. 663 Author's Address 665 James M Snell 667 Email: jasnell@gmail.com