idnits 2.17.1 draft-snell-http-prefer-06.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 (December 7, 2011) is 4524 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-17 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-17 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission J. Snell 3 Internet-Draft December 7, 2011 4 Intended status: Informational 5 Expires: June 9, 2012 7 Prefer Header for HTTP 8 draft-snell-http-prefer-06 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 June 9, 2012. 33 Copyright Notice 35 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . 3 53 2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. The Preference-Applied Response Header . . . . . . . . . . . . 5 55 4. The "return-accepted" Preference . . . . . . . . . . . . . . . 7 56 5. The "return-representation" Preference . . . . . . . . . . . . 7 57 6. The "return-status" Preference . . . . . . . . . . . . . . . . 8 58 7. The "return-minimal" Preference . . . . . . . . . . . . . . . 8 59 8. The "wait" Preference . . . . . . . . . . . . . . . . . . . . 8 60 9. The "strict" and "lenient" Processing Preferences . . . . . . 9 61 10. The "detail" Preference . . . . . . . . . . . . . . . . . . . 9 62 11. Registered Preferences . . . . . . . . . . . . . . . . . . . . 10 63 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 12.1. The Registry of Preferences . . . . . . . . . . . . . . . 10 65 12.1.1. Initial Registry Contents . . . . . . . . . . . . . . 11 66 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 14. Normative References . . . . . . . . . . . . . . . . . . . . . 13 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 1. Introduction 72 This specification defines a new HTTP request header field that may 73 be used by clients to request optional behaviors be applied by a 74 server during the processing the request. 76 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 77 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 78 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 80 1.1. Syntax Notation 82 This specification uses the Augmented Backus-Naur Form (ABNF) 83 notation of [RFC5234] and includes, by reference, the "token", 84 "quoted-string", "OWS", "BWS" rules and the #rule extension as 85 defined within [I-D.ietf-httpbis-p1-messaging] Section 1.2. 87 2. The Prefer Request Header 89 The Prefer request-header field is used to indicate that particular 90 server behaviors are preferred by the client, but not required for 91 successful completion of the request. Prefer is similar in nature to 92 the Expect header field defined by [I-D.ietf-httpbis-p2-semantics] 93 Section 9.3 with the exception that servers are allowed to ignore 94 stated preferences. 96 Prefer = "Prefer" ":" 1#preference 97 preference = token [ BWS "=" BWS value ] 98 *( OWS ";" [ OWS parameter ] ) 99 parameter = token [ BWS "=" BWS value ] 100 value = token / quoted-string 102 This header field is defined with an extensible syntax to allow for 103 future values included in the Registry of Preferences 104 (Section 12.1)). A server that does not recognize or is unable to 105 comply with particular preference tokens in the Prefer header field 106 of a request MUST ignore those tokens and MUST NOT stop processing or 107 signal an error. 109 A preference token MAY specify a value. Empty, or zero length values 110 on both the preference token and within parameters are equivalent to 111 no value being specified at all. The following, then, are 112 equivalent: 114 Prefer: foo; bar="" 115 Prefer: foo=; bar 116 Prefer: foo=""; bar= 118 An optional, arbitrary collection of parameters MAY be specified for 119 any preference token. The meaning and application of such parameters 120 is dependent on the definition of each preference token and the 121 server's implementation thereof. 123 If a particular preference token or parameter is specified multiple 124 times, repeated occurrences MUST be ignored without signaling an 125 error or otherwise altering the processing of the request. 127 Comparison of preference token names is case-insensitive while values 128 are case-sensitive regardless of whether token or quoted-string 129 values are used. 131 Note that the application of a preference by the server MAY affect 132 the caching characteristics of the response. Specifically, should 133 the application of a preference result in a variance to the 134 representation returned by a cacheable response, a Vary header field 135 MUST be included listing the Prefer header field as one of the 136 selecting header fields. 138 The Prefer request header field MUST be forwarded by the proxy if the 139 request is forwarded. In various situations, A proxy may determine 140 that it is capable of honoring a preference independently of the 141 server to which the request is directed. For instance, an 142 intervening proxy may be capable of transparently providing 143 asynchronous handling of a request using a 202 Accepted responses 144 independently of the origin server. Such proxies could choose to 145 honor the "return-accepted" preference. Individual preference tokens 146 MAY define their own requirements and restrictions as to whether and 147 how proxies may apply the preference to a request independently of 148 the origin server. 150 As per [I-D.ietf-httpbis-p1-messaging], Section 3.2, Implementations 151 MUST be capable of supporting either multiple instances of the Prefer 152 header field in a single message as well as multiple preference 153 tokens separated by commas in a single Prefer header, for instance, 154 the following examples are equivalent: 156 # Multiple Prefer Header Fields 157 POST /foo HTTP/1.1 158 Host: example.org 159 Prefer: return-accepted 160 Prefer: wait=100 162 # Single Prefer Header Field 163 POST /foo HTTP/1.1 164 Host: example.org 165 Prefer: return-accepted, wait=100 167 2.1. Examples 169 The following examples illustrate the use of various Preferences 170 defined by this specification, as well as undefined extensions for 171 strictly illustrative purposes: 173 # Return a 202 Accepted response for asynchronous processing 174 # if the response cannot be processed within 10 seconds. 175 # An undefined "priority" preference is also specified. 177 Prefer: return-accepted; 178 Prefer: wait=10; 179 Prefer: priority=5; 181 # Use lenient processing, a reporting detail level of 10, 182 # and return an entity describing the status of the request 183 # rather than a representation of the resource 185 Prefer: Lenient, Detail=10, Return-Status 187 # Use of an optional, undefined parameter on the 188 # return-minimal preference requesting a response 189 # status code of 204 for a successful response. 191 Prefer: return-minimal; status=204 193 3. The Preference-Applied Response Header 195 The Preference-Applied response header MAY be included within a 196 response message as an indication as to which Prefer tokens were 197 honored by the server and applied to the processing of the request. 199 Preference-Applied = "Preference-Applied" ":" 1#token 201 Note that the syntax of the Preference-Applied header differs from 202 that of the Prefer header in that token values and parameters are not 203 included. 205 Use of the Preference-Applied header is not required in all cases. 206 For instance, when using the return-accepted, return-minimal or wait 207 preferences, as defined below, the application of the preference will 208 be apparent based on the context and nature of the response. 209 However, there are cases in which the application of a preference 210 cannot be easily determined by the client. For instance, when 211 posting a resource to a server using either the return-representation 212 or return-status preferences, a client cannot be certain in all cases 213 whether the returned entity is a representation of the modified 214 resource or a representation of the request status. In such 215 situations, where the nature of the response is ambiguous and a clear 216 preference has been stated by the client using the Prefer request 217 header field, the Preference-Applied response header field SHOULD be 218 used. 220 For example, here a request is sent to the server requesting the 221 return of the resource representation. 223 #Request 224 POST /collection HTTP/1.1 225 Host: example.org 226 Content-Type: application/json 227 Prefer: return-representation 229 {...} 231 # Response 232 HTTP/1.1 201 Created 233 Content-Type: application/json 234 Preference-Applied: return-representation 235 Location: /collection/1 237 {...} 239 Whereas in this example, the request is sent asking for the return of 240 a status representation. 242 #Request 243 POST /collection HTTP/1.1 244 Host: example.org 245 Content-Type: application/json 246 Prefer: return-status 248 {...} 250 # Response 251 HTTP/1.1 201 Created 252 Content-Type: application/json 253 Preference-Applied: return-status 254 Location: /collection/1 256 {...} 258 Use of the Preference-Applied response header allows the client to 259 unambiguously determine whether the requested preference was applied. 261 4. The "return-accepted" Preference 263 The "return-accepted" preference indicates that the client prefers 264 the server to respond with a 202 Accepted status in the case where 265 the length of time it takes to generate a response will exceed some 266 arbitrary threshold established by the server. 268 return-accepted = "return-accepted" 270 The key motivation for the "return-accepted" preference is to 271 facilitate the operation of asynchronous request handling by allowing 272 the client to indicate to a server it's capability and preference for 273 handling 202 Accepted responses. 275 5. The "return-representation" Preference 277 The "return-representation" preference indicates that the client 278 prefers that the server include an entity representing the current 279 state of the resource in the response to a successful request. 281 return-representation = "return-representation" 283 When honoring the "return-representation" preference, the server MUST 284 include a Content-Location header field specifying the URI of the 285 resource representation being returned. Per section 6.1 of 286 [I-D.ietf-httpbis-p2-semantics], the presence of the Content-Location 287 header field in the response asserts that the payload is a 288 representation of the resource identified by the Content-Location 289 URI. 291 The "return-representation" preference is intended primarily to 292 provide a means of optimizing communication between the client and 293 server by eliminating the need for a subsequent GET request to 294 retrieve the current representation of the resource following a 295 modification. 297 Currently, after successfully processing a modification request such 298 as a POST or PUT, a server may choose to return either an entity 299 describing the status of the operation or a representation of the 300 modified resource itself. While the selection of which type of 301 entity to return, if any at all, is solely at the discretion of the 302 server, the "return-representation" preference -- along with the 303 "return-status" and "return-minimal" directives defined below -- 304 allow the server to take the client's preferences into consideration 305 while constructing the response. 307 6. The "return-status" Preference 309 The "return-status" preference indicates that the client prefers the 310 server to include an entity describing the status of the request in 311 the response as opposed to returning a representation of the current 312 state of the resource. 314 return-status = "return-status" 316 When honoring the "return-status" preference, the server SHOULD NOT 317 include a Content-Location header field in the response. 319 7. The "return-minimal" Preference 321 The "return-minimal" preference indicates that the client wishes the 322 server to return a minimal response to a successful request. 323 Typically, such responses would utilize the 204 No Content status, 324 but other codes MAY be used as appropriate, such as a 200 status with 325 a zero-length response entity. The determination of what constitutes 326 an appropriate minimal response is solely at the discretion of the 327 server. 329 return-minimal = "return-minimal" 331 The "return-minimal" preference is intended to provide a means of 332 optimizing communication between the client and server by reducing 333 the amount of data the server is required to return to the client 334 following a request. This can be particularly useful, for instance, 335 when communicating with limited-bandwidth mobile devices or when the 336 client simply does not require any further information about the 337 result of a request beyond knowing if it was successfully processed. 339 8. The "wait" Preference 341 The "wait" preference can be used to establish an upper bound on the 342 length of time, in seconds, the client is willing to wait for a 343 response, after which the client may choose to abandon the request. 344 In the case generating a response will take longer than the time 345 specified, the server, or proxy, can choose to either return a 202 346 Accepted response, cancel processing, or continue attempting to 347 complete the request. 349 wait = "wait" BWS "=" BWS delta-seconds 351 Clients specifying the "wait" Preference SHOULD also use the Date 352 header field, as specified in [I-D.ietf-httpbis-p2-semantics] Section 353 9.2, within the request to establish the time at which the client 354 began waiting for the completion of the request. Failing to include 355 a Date header field in the request would require the server to use 356 the instant it received and began processing the request as the 357 baseline for determining how long the client has been waiting which 358 could yield unintended results depending on how out of synch the 359 client and server clocks are. 361 9. The "strict" and "lenient" Processing Preferences 363 The "strict" and "lenient" preferences are mutually-exclusive 364 directives indicating, at the servers discretion, how the client 365 wishes the server to handle potential error conditions that may arise 366 in the processing of a request. For instance, if the payload of a 367 request contains various minor syntactical or semantic errors, but 368 the server is still capable of comprehending and successfully 369 processing the request, a decision must be made to either reject the 370 request with an appropriate 4xx error response or to go ahead with 371 processing. The "strict" preference can be used by the client to 372 indicate that, in such conditions, it would prefer that the server 373 reject the request, while the "lenient" preference indicates that the 374 client would prefer the server to attempt to process the request. 375 The specific meaning and application of the "strict" and "lenient" 376 directives is specific to each type of resource, the request method 377 and the operation of the server. 379 handling = "strict" / "lenient" 381 10. The "detail" Preference 383 The "detail" preference specifies the level of detail the client 384 wishes the server to provide within a response to an operation. This 385 preference is akin to specifying the level of verbose output an 386 operation should generate or to specifying the trace level within a 387 debug log. The detail level is specified as a non-negative integer 388 in the range 0-100, where the value 0 indicates a server-determined 389 default detail level and all other integer values specify a strictly 390 decreasing level of detail as the integer value increases. 392 detail = "detail" BWS "=" BWS ("100" / 1*2DIGIT ) 394 Implementations are free to apply additional constraints on the range 395 of acceptable values for this directive but MUST NOT signal an error 396 or fail to process the request should the client provide a value 397 outside the acceptable range. In such cases, the server SHOULD 398 either ignore the preference or apply a reasonable default value. 400 One example of a potential use for the application of the "detail" 401 preference would be in deciding the amount of detailed error 402 information a server includes in the payload of a 4xx or 5xx 403 response. Solely at the discretion of the server, an error response 404 to a request specifying a higher detail level (e.g., detail=1) may 405 included significantly more detailed information about the error 406 condition than an error response specifying a much lower detail level 407 (e.g., detail=10). 409 11. Registered Preferences 411 Well-defined preferences can be registered for convenience and/or to 412 promote reuse by other applications. This specification establishes 413 an IANA registry of such relation types see Section Section 12.1. 415 Registered preference names MUST conform to the token rule, and MUST 416 be compared character-by-character in a case-insensitive fashion. 417 They SHOULD be appropriate to the specificity of the preference; 418 i.e., if the semantics are highly specific to a particular 419 application, the name should reflect that, so that more general names 420 are available for less specific use. 422 Registered preferences MUST NOT constrain servers, clients or any 423 intermediaries involved in the exchange and processing of a request 424 to any behavior required for successful processing. The use and 425 application of a preference within a given request MUST be optional 426 on the part of all participants. 428 12. IANA Considerations 430 The 'Prefer' header field should be added to the permanent registry 431 (see [RFC3864]). 433 Header field name: Prefer 434 Applicable Protocol: HTTP 435 Status: 436 Author/Change controller: IETF 437 Specification document: this specification 439 12.1. The Registry of Preferences 441 Preferences are registered on the advice of a Designated Expert 442 (appointed by the IESG or their delegate), with a Specification 443 Required (using terminology from [RFC5226]). 445 The requirements for registered preferences are described in 446 Section 11 448 Registration requests consist of the completed registration template 449 below, typically published in an RFC or Open Standard (in the sense 450 described by [RFC2026], Section 7). However, to allow for the 451 allocation of values prior to publication, the Designated Expert may 452 approve registration once they are satisfied that a specification 453 will be published. 455 Note that relation types can be registered by third parties, if the 456 Designated Expert determines that an unregistered relation type is 457 widely deployed and not likely to be registered in a timely manner. 459 The registration template is: 461 o Preference: (A value for the Prefer request header field that 462 conforms to the syntax rule given in Section 2) 463 o Description: 464 o Reference: 465 o Notes: [optional] 466 o Application Data: [optional] 468 Registration requests should be sent to the preferences@ietf.org 469 mailing list, marked clearly in the subject line (e.g., "NEW 470 PREFERENCE - example" to register an "example" preference). 472 Within at most 14 days of the request, the Designated Expert(s) will 473 either approve or deny the registration request, communicating this 474 decision to the review list and IANA. Denials should include an 475 explanation and, if applicable, suggestions as to how to make the 476 request successful. 478 Decisions (or lack thereof) made by the Designated Expert can be 479 first appealed to Application Area Directors (contactable using 480 app-ads@tools.ietf.org email address or directly by looking up their 481 email addresses on http://www.iesg.org/ website) and, if the 482 appellant is not satisfied with the response, to the full IESG (using 483 the iesg@iesg.org mailing list). 485 IANA should only accept registry updates from the Designated 486 Expert(s), and should direct all requests for registration to the 487 review mailing list. 489 12.1.1. Initial Registry Contents 491 The Preferences Registry's initial contents are: 493 o Preference: return-accepted 494 o Description: Indicates that the client prefers the server to 495 respond with a 202 Accepted status as described by Section 4 496 o Reference: [this specification] 498 o Preference: return-minimal 499 o Description: Indicates that the client prefers the server return a 500 minimal response to a request as described by Section 7 501 o Reference: [this specification] 503 o Preference: return-representation 504 o Description: Indicates that the client prefers the server to 505 include a representation of the current state of the resource in 506 response to a request as described by Section 5 507 o Reference: [this specification] 509 o Preference: return-status 510 o Description: Indicates that the client prefers the server to 511 return an entity describing the current state of a resource in 512 response to a request as described by Section 6 513 o Reference: [this specification] 515 o Preference: wait 516 o Description: Indicates an upper bound to the lenght of time the 517 client is willing to wait for a response, after which the request 518 may be aborted. 519 o Reference: [this specification] 521 o Preference: strict 522 o Description: Indicates that the client wishes the server to apply 523 strict validation and error handling to the processing of a 524 request. 525 o Reference: [this specification] 527 o Preference: lenient 528 o Description: Indicates that the client wishes the server to apply 529 lenient validation and error handling to the processing of a 530 request. 531 o Reference: [this specification] 533 o Preference: detail 534 o Description: Indicates the client's preference as to the amount of 535 detail the server should include in responses to a request. 536 o Reference: [this specification] 538 13. Security Considerations 540 Specific preferences requested by a client can introduce security 541 considerations and concerns beyond those discussed in HTTP/1.1 Parts 542 1 [I-D.ietf-httpbis-p1-messaging], 2 [I-D.ietf-httpbis-p2-semantics], 543 3 [I-D.ietf-httpbis-p3-payload], 4 [I-D.ietf-httpbis-p4-conditional], 544 5 [I-D.ietf-httpbis-p5-range], 6 [I-D.ietf-httpbis-p6-cache], and 7 545 [I-D.ietf-httpbis-p7-auth]. Implementors must refer to the 546 specifications and descriptions of each preference to determine the 547 security considerations relevant to each. 549 14. Normative References 551 [I-D.ietf-httpbis-p1-messaging] 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 1: URIs, Connections, and 555 Message Parsing", draft-ietf-httpbis-p1-messaging-17 (work 556 in progress), October 2011. 558 [I-D.ietf-httpbis-p2-semantics] 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 2: Message Semantics", 562 draft-ietf-httpbis-p2-semantics-17 (work in progress), 563 October 2011. 565 [I-D.ietf-httpbis-p3-payload] 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 3: Message Payload and Content 569 Negotiation", draft-ietf-httpbis-p3-payload-17 (work in 570 progress), October 2011. 572 [I-D.ietf-httpbis-p4-conditional] 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 4: Conditional Requests", 576 draft-ietf-httpbis-p4-conditional-17 (work in progress), 577 October 2011. 579 [I-D.ietf-httpbis-p5-range] 580 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 581 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 582 J. Reschke, "HTTP/1.1, part 5: Range Requests and Partial 583 Responses", draft-ietf-httpbis-p5-range-17 (work in 584 progress), October 2011. 586 [I-D.ietf-httpbis-p6-cache] 587 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 588 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 589 Nottingham, M., and J. Reschke, "HTTP/1.1, part 6: 590 Caching", draft-ietf-httpbis-p6-cache-17 (work in 591 progress), October 2011. 593 [I-D.ietf-httpbis-p7-auth] 594 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 595 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 596 J. Reschke, "HTTP/1.1, part 7: Authentication", 597 draft-ietf-httpbis-p7-auth-17 (work in progress), 598 October 2011. 600 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 601 3", BCP 9, RFC 2026, October 1996. 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 607 Procedures for Message Header Fields", BCP 90, RFC 3864, 608 September 2004. 610 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 611 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 612 May 2008. 614 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 615 Specifications: ABNF", STD 68, RFC 5234, January 2008. 617 Author's Address 619 James M Snell 621 Phone: 622 Email: jasnell@gmail.com 623 URI: