idnits 2.17.1 draft-snell-http-prefer-13.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 (August 21, 2012) is 4263 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) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-18 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-18 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 9 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 August 21, 2012 4 Intended status: Standards Track 5 Expires: February 22, 2013 7 Prefer Header for HTTP 8 draft-snell-http-prefer-13 10 Abstract 12 This specification defines an HTTP header field that can be used by a 13 client to request that certain behaviors be implemented 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 February 22, 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 . . . . . . . . . . . . . . . . . . . . . 3 52 2. The Prefer Request Header Field . . . . . . . . . . . . . . . 3 53 2.1. Content Negotiation and Cache Considerations . . . . . . . 5 54 2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. The "return-asynch" Preference . . . . . . . . . . . . . . . . 5 56 4. The "return-representation" Preference . . . . . . . . . . . . 6 57 5. The "return-minimal" Preference . . . . . . . . . . . . . . . 7 58 6. The "wait" Preference . . . . . . . . . . . . . . . . . . . . 8 59 7. The "strict" and "lenient" Processing Preferences . . . . . . 9 60 8. Registered Preferences . . . . . . . . . . . . . . . . . . . . 10 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 9.1. The Registry of Preferences . . . . . . . . . . . . . . . 11 63 9.1.1. Initial Registry Contents . . . . . . . . . . . . . . 12 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 11. Normative References . . . . . . . . . . . . . . . . . . . . . 13 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 1. Introduction 70 This specification defines a new HTTP request header field that can 71 be used by clients to request optional behaviors be applied by a 72 server during the processing the request. 74 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 75 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 76 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 78 1.1. Syntax Notation 80 This specification uses the Augmented Backus-Naur Form (ABNF) 81 notation of [RFC5234] and includes, by reference, the "word", "OWS", 82 "BWS" rules and the #rule extension as defined within Sections 1.2 83 and 3.2.4 of [I-D.ietf-httpbis-p1-messaging]. 85 2. The Prefer Request Header Field 87 The Prefer request-header field is used to indicate that particular 88 server behaviors are preferred by the client, but not required for 89 successful completion of the request. Prefer is similar in nature to 90 the Expect header field defined by Section 9.3 of 91 [I-D.ietf-httpbis-p2-semantics] with the exception that servers are 92 allowed to ignore stated preferences. 94 Prefer = "Prefer" ":" 1#preference 95 preference = token [ BWS "=" BWS word ] 96 *( OWS ";" [ OWS parameter ] ) 97 parameter = token [ BWS "=" BWS word ] 99 This header field is defined with an extensible syntax to allow for 100 future values included in the Registry of Preferences (Section 9.1). 101 A server that does not recognize or is unable to comply with 102 particular preference tokens in the Prefer header field of a request 103 MUST ignore those tokens and MUST NOT stop processing or signal an 104 error. 106 A preference token MAY specify a value. Empty, or zero length values 107 on both the preference token and within parameters are equivalent to 108 no value being specified at all. The following, then, are 109 equivalent: 111 Prefer: foo; bar 112 Prefer: foo; bar="" 113 Prefer: foo=""; bar 115 An optional, arbitrary collection of parameters MAY be specified for 116 any preference token. The meaning and application of such parameters 117 is dependent on the definition of each preference token and the 118 server's implementation thereof. 120 If a particular preference token or parameter is specified multiple 121 times, repeated occurrences MUST be ignored without signaling an 122 error or otherwise altering the processing of the request. 124 Comparison of preference token names is case-insensitive while values 125 are case-sensitive regardless of whether token or quoted-string 126 values are used. 128 The Prefer request header field MUST be forwarded by a proxy if the 129 request is forwarded. In various situations, a proxy can determine 130 that it is capable of honoring a preference independently of the 131 server to which the request is directed. For instance, an 132 intervening proxy can be capable of transparently providing 133 asynchronous handling of a request using a 202 Accepted responses 134 independently of the origin server. Such proxies could choose to 135 honor the "return-asynch" preference. Individual preference tokens 136 MAY define their own requirements and restrictions as to whether and 137 how proxies can apply the preference to a request independently of 138 the origin server. 140 As per Section 3.2 of [I-D.ietf-httpbis-p1-messaging], 141 Implementations MUST be capable of supporting either multiple 142 instances of the Prefer header field in a single message as well as 143 multiple preference tokens separated by commas in a single Prefer 144 header, for instance, the following examples are equivalent: 146 Multiple Prefer Header Fields: 148 POST /foo HTTP/1.1 149 Host: example.org 150 Prefer: return-asynch 151 Prefer: wait=100 152 Date: Tue, 20 Dec 2011 12:34:56 GMT 154 Single Prefer Header Field: 156 POST /foo HTTP/1.1 157 Host: example.org 158 Prefer: return-asynch, wait=100 159 Date: Tue, 20 Dec 2011 12:34:56 GMT 161 2.1. Content Negotiation and Cache Considerations 163 Note that while the Prefer header field is not intended to be used as 164 content negotiation mechanism, the application of a preference 165 potentially could affect the caching characteristics of a response. 166 Specifically, if a server supports the optional application of a 167 preference that could even potentially result in a variance to a 168 cache's handling of a response entity, a Vary header field MUST be 169 included with the response listing the Prefer header field regardless 170 of whether the client actually uses Prefer in the request. 172 Because of the inherent complexities involved with properly 173 implementing server-driven content negotiation, effective caching, 174 and the application of optional preferences, implementors must 175 exercise caution when utilizing preferences in such a way as to 176 impact the caching of a response and SHOULD avoid using the Prefer 177 header mechanism for content negotiation. 179 2.2. Examples 181 The following examples illustrate the use of various Preferences 182 defined by this specification, as well as undefined extensions for 183 strictly illustrative purposes: 185 Return a 202 Accepted response for asynchronous processing if the 186 response cannot be processed within 10 seconds. An undefined 187 "priority" preference is also specified: 189 Prefer: return-asynch, wait=10; 190 Prefer: priority=5; 192 Use lenient processing: 194 Prefer: Lenient 196 Use of an optional, undefined parameter on the return-minimal 197 preference requesting a response status code of 204 for a successful 198 response: 200 Prefer: return-minimal; status=204 202 3. The "return-asynch" Preference 204 The "return-asynch" preference indicates that the client prefers the 205 server to respond asynchronously to a response. For instance, in the 206 case when the length of time it takes to generate a response will 207 exceed some arbitrary threshold established by the server, the server 208 can honor the return-asynch preference by returning either a 202 209 Accepted or 303 See Other response. 211 return-asynch = "return-asynch" 213 The key motivation for the "return-asynch" preference is to 214 facilitate the operation of asynchronous request handling by allowing 215 the client to indicate to a server it's capability and preference for 216 handling asynchronous responses. 218 An example request specifying the "return-asynch" preference: 220 POST /collection HTTP/1.1 221 Host: example.org 222 Content-Type: text/plain 223 Prefer: return-asynch 225 {Data} 227 An example asynchronous response using 202 Accepted: 229 HTTP/1.1 202 Accepted 230 Location: http://example.org/collection/123 232 An alternative asynchronous response using 303 See Other: 234 HTTP/1.1 303 See Other 235 Location: http://example.org/collection/123 236 Retry-After: 10 238 4. The "return-representation" Preference 240 The "return-representation" preference indicates that the client 241 prefers that the server include an entity representing the current 242 state of the resource in the response to a successful request. 244 return-representation = "return-representation" 246 When honoring the "return-representation" preference, the server MUST 247 include a Content-Location header field specifying the URI of the 248 resource representation being returned. Per section 6.1 of 249 [I-D.ietf-httpbis-p2-semantics], the presence of the Content-Location 250 header field in the response asserts that the payload is a 251 representation of the resource identified by the Content-Location 252 URI. 254 The "return-representation" preference is intended primarily to 255 provide a means of optimizing communication between the client and 256 server by eliminating the need for a subsequent GET request to 257 retrieve the current representation of the resource following a 258 modification. 260 Currently, after successfully processing a modification request such 261 as a POST or PUT, a server can choose to return either an entity 262 describing the status of the operation or a representation of the 263 modified resource itself. While the selection of which type of 264 entity to return, if any at all, is solely at the discretion of the 265 server, the "return-representation" preference -- along with the 266 "return-minimal" preference defined below -- allow the server to take 267 the client's preferences into consideration while constructing the 268 response. 270 An example request specifying the "return-representation" preference: 272 PUT /collection/123 HTTP/1.1 273 Host: example.org 274 Content-Type: text/plain 275 Prefer: return-representation 277 {Data} 279 An example response containing the resource representation: 281 HTTP/1.1 200 OK 282 Content-Location: http://example.org/collection/123 283 Content-Type: text/plain 284 ETag: "d3b07384d113edec49eaa6238ad5ff00" 286 {Data} 288 5. The "return-minimal" Preference 290 The "return-minimal" preference indicates that the client wishes the 291 server to return a minimal response to a successful request. 292 Typically, such responses would utilize the 204 No Content status, 293 but other codes MAY be used as appropriate, such as a 200 status with 294 a zero-length response entity. The determination of what constitutes 295 an appropriate minimal response is solely at the discretion of the 296 server. 298 return-minimal = "return-minimal" 300 The "return-minimal" preference is intended to provide a means of 301 optimizing communication between the client and server by reducing 302 the amount of data the server is required to return to the client 303 following a request. This can be particularly useful, for instance, 304 when communicating with limited-bandwidth mobile devices or when the 305 client simply does not require any further information about the 306 result of a request beyond knowing if it was successfully processed. 308 An example request specifying the "return-minimal" preference: 310 POST /collection HTTP/1.1 311 Host: example.org 312 Content-Type: text/plain 313 Prefer: return-minimal 315 {Data} 317 An example minimal response: 319 HTTP/1.1 201 Created 320 Location: http://example.org/collection/123 321 Content-Length: 0 323 The "return-minimal" and "return-representation" preferences are 324 mutually exclusive directives that SHOULD NOT be used in combination 325 within a single request. 327 6. The "wait" Preference 329 The "wait" preference can be used to establish an upper bound on the 330 length of time, in seconds, the client is willing to wait for a 331 response, after which the client can choose to abandon the request. 332 In the case generating a response will take longer than the time 333 specified, the server, or proxy, MAY choose to utilize an 334 asynchronous processing model by returning, for example, 202 Accepted 335 or 303 See Other responses. 337 wait = "wait" BWS "=" BWS delta-seconds 339 Clients specifying the "wait" Preference SHOULD also use the Date 340 header field, as specified in Section 9.2 of 341 [I-D.ietf-httpbis-p2-semantics], within the request to establish the 342 time at which the client began waiting for the completion of the 343 request. Failing to include a Date header field in the request would 344 require the server to use the instant it received or began processing 345 the request as the baseline for determining how long the client has 346 been waiting which could yield unintended results. 348 The lack of a Date header in the request, or poor clock 349 synchronization between the client and server makes it impossible to 350 determine the exact length of time the client has already been 351 waiting when the request is received by the server. The only 352 reliable information conveyed by the wait preference is that the 353 client is not expecting the server to spend more than the specified 354 time on request processing and can terminate the transaction at any 355 time. 357 An example request specifying the "wait" and "return-asynch" 358 preferences to indicate that the client wishes the server to respond 359 asynchronously if processing of the request will take longer than 10 360 seconds: 362 POST /collection HTTP/1.1 363 Host: example.org 364 Content-Type: text/plain 365 Prefer: return-asynch, wait=10 366 Date: Tue, 20 Dec 2011 12:34:56 GMT 368 {Data} 370 7. The "strict" and "lenient" Processing Preferences 372 The "strict" and "lenient" preferences are mutually-exclusive 373 directives indicating, at the servers discretion, how the client 374 wishes the server to handle potential error conditions that can arise 375 in the processing of a request. For instance, if the payload of a 376 request contains various minor syntactical or semantic errors, but 377 the server is still capable of comprehending and successfully 378 processing the request, a decision must be made to either reject the 379 request with an appropriate 4xx error response or to go ahead with 380 processing. The "strict" preference can be used by the client to 381 indicate that, in such conditions, it would prefer that the server 382 reject the request, while the "lenient" preference indicates that the 383 client would prefer the server to attempt to process the request. 384 The specific meaning and application of the "strict" and "lenient" 385 directives is specific to each type of resource, the request method 386 and the operation of the server. 388 handling = "strict" / "lenient" 390 An example request specifying the "strict" preference: 392 POST /collection HTTP/1.1 393 Host: example.org 394 Content-Type: text/plain 395 Prefer: strict 397 An example request specifying the "lenient" preference: 399 POST /collection HTTP/1.1 400 Host: example.org 401 Content-Type: text/plain 402 Prefer: lenient 404 8. Registered Preferences 406 Well-defined preferences can be registered for convenience and/or to 407 promote reuse by other applications. This specification establishes 408 an IANA registry of such relation types (see Section 9.1). 410 Registered preference names MUST conform to the token rule, and MUST 411 be compared character-by-character in a case-insensitive fashion. 412 They SHOULD be appropriate to the specificity of the preference; 413 i.e., if the semantics are highly specific to a particular 414 application, the name should reflect that, so that more general names 415 are available for less specific use. 417 Registered preferences MUST NOT constrain servers, clients or any 418 intermediaries involved in the exchange and processing of a request 419 to any behavior required for successful processing. The use and 420 application of a preference within a given request MUST be optional 421 on the part of all participants. 423 9. IANA Considerations 425 The 'Prefer' header field should be added to the permanent registry 426 (see [RFC3864]). 428 Header field name: Prefer 429 Applicable Protocol: HTTP 430 Status: 431 Author: James M Snell 432 Change controller: IETF 433 Specification document: this specification 435 9.1. The Registry of Preferences 437 Preferences are registered on the advice of a Designated Expert 438 (appointed by the IESG or their delegate), with a Specification 439 Required (using terminology from [RFC5226]). 441 The requirements for registered preferences are described in 442 Section 8. 444 Registration requests consist of the completed registration template 445 below, typically published in an RFC or Open Standard (in the sense 446 described by Section 7 of [RFC2026]). However, to allow for the 447 allocation of values prior to publication, the Designated Expert can 448 approve registration once they are satisfied that a specification 449 will be published. 451 Note that preferences can be registered by third parties, if the 452 Designated Expert determines that an unregistered preference is 453 widely deployed and not likely to be registered in a timely manner. 455 The registration template is: 457 o Preference: (A value for the Prefer request header field that 458 conforms to the syntax rule given in Section 2) 459 o Description: 460 o Reference: 461 o Notes: [optional] 463 Registration requests should be sent to the preferences@ietf.org 464 mailing list, marked clearly in the subject line (e.g., "NEW 465 PREFERENCE - example" to register an "example" preference). 467 Within at most 14 days of the request, the Designated Expert(s) will 468 either approve or deny the registration request, communicating this 469 decision to the review list and IANA. Denials should include an 470 explanation and, if applicable, suggestions as to how to make the 471 request successful. 473 Decisions (or lack thereof) made by the Designated Expert can be 474 first appealed to Application Area Directors (contactable using 475 app-ads@tools.ietf.org email address or directly by looking up their 476 email addresses on http://www.iesg.org/ website) and, if the 477 appellant is not satisfied with the response, to the full IESG (using 478 the iesg@iesg.org mailing list). 480 IANA should only accept registry updates from the Designated 481 Expert(s), and should direct all requests for registration to the 482 review mailing list. 484 9.1.1. Initial Registry Contents 486 The Preferences Registry's initial contents are: 488 o Preference: return-asynch 489 o Description: Indicates that the client prefers the server to 490 respond asynchronously to a request as described by Section 3 491 o Reference: [this specification] 493 o Preference: return-minimal 494 o Description: Indicates that the client prefers the server return a 495 minimal response to a request as described by Section 5 496 o Reference: [this specification] 498 o Preference: return-representation 499 o Description: Indicates that the client prefers the server to 500 include a representation of the current state of the resource in 501 response to a request as described by Section 4 502 o Reference: [this specification] 504 o Preference: wait 505 o Description: Indicates an upper bound to the lenght of time the 506 client is willing to wait for a response, after which the request 507 can be aborted. 508 o Reference: [this specification] 510 o Preference: strict 511 o Description: Indicates that the client wishes the server to apply 512 strict validation and error handling to the processing of a 513 request. 514 o Reference: [this specification] 516 o Preference: lenient 517 o Description: Indicates that the client wishes the server to apply 518 lenient validation and error handling to the processing of a 519 request. 520 o Reference: [this specification] 522 10. Security Considerations 524 Specific preferences requested by a client can introduce security 525 considerations and concerns beyond those discussed in HTTP/1.1 Parts 526 1 [I-D.ietf-httpbis-p1-messaging], 2 [I-D.ietf-httpbis-p2-semantics], 527 3 [I-D.ietf-httpbis-p3-payload], 4 [I-D.ietf-httpbis-p4-conditional], 528 5 [I-D.ietf-httpbis-p5-range], 6 [I-D.ietf-httpbis-p6-cache], and 7 529 [I-D.ietf-httpbis-p7-auth]. Implementors must refer to the 530 specifications and descriptions of each preference to determine the 531 security considerations relevant to each. 533 A server could incur greater costs in attempting to comply with a 534 particular preference (for instance, the cost of providing a 535 representation in a response that would not ordinarily contain one; 536 or the commitment of resources necessary to track state for an 537 asynchronous response). Unconditional compliance from a server could 538 allow the use of preferences for denial of service. A server can 539 ignore an expressed preference to avoid expending resources that it 540 does not wish to commit. 542 11. Normative References 544 [I-D.ietf-httpbis-p1-messaging] 545 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 546 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 547 J. Reschke, "HTTP/1.1, part 1: URIs, Connections, and 548 Message Parsing", draft-ietf-httpbis-p1-messaging-18 (work 549 in progress), January 2012. 551 [I-D.ietf-httpbis-p2-semantics] 552 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 553 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 554 J. Reschke, "HTTP/1.1, part 2: Message Semantics", 555 draft-ietf-httpbis-p2-semantics-18 (work in progress), 556 January 2012. 558 [I-D.ietf-httpbis-p3-payload] 559 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 560 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 561 J. Reschke, "HTTP/1.1, part 3: Message Payload and Content 562 Negotiation", draft-ietf-httpbis-p3-payload-18 (work in 563 progress), January 2012. 565 [I-D.ietf-httpbis-p4-conditional] 566 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 567 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 568 J. Reschke, "HTTP/1.1, part 4: Conditional Requests", 569 draft-ietf-httpbis-p4-conditional-18 (work in progress), 570 January 2012. 572 [I-D.ietf-httpbis-p5-range] 573 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 574 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 575 J. Reschke, "HTTP/1.1, part 5: Range Requests and Partial 576 Responses", draft-ietf-httpbis-p5-range-18 (work in 577 progress), January 2012. 579 [I-D.ietf-httpbis-p6-cache] 580 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 581 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 582 Nottingham, M., and J. Reschke, "HTTP/1.1, part 6: 583 Caching", draft-ietf-httpbis-p6-cache-18 (work in 584 progress), January 2012. 586 [I-D.ietf-httpbis-p7-auth] 587 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 588 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 589 J. Reschke, "HTTP/1.1, part 7: Authentication", 590 draft-ietf-httpbis-p7-auth-18 (work in progress), 591 January 2012. 593 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 594 3", BCP 9, RFC 2026, October 1996. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 600 Procedures for Message Header Fields", BCP 90, RFC 3864, 601 September 2004. 603 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 604 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 605 May 2008. 607 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 608 Specifications: ABNF", STD 68, RFC 5234, January 2008. 610 Author's Address 612 James M Snell 614 Email: jasnell@gmail.com