idnits 2.17.1 draft-reschke-rfc5987bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC5987, but the abstract doesn't seem to directly say this. It does mention RFC5987 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 21, 2011) is 4533 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Duplicate reference: RFC2978, mentioned in 'Err1912', was also mentioned in 'RFC2978'. -- Obsolete informational reference (is this intentional?): RFC 2388 (Obsoleted by RFC 7578) -- Obsolete informational reference (is this intentional?): RFC 5987 (Obsoleted by RFC 8187) -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Reschke 3 Internet-Draft greenbytes 4 Obsoletes: 5987 (if approved) November 21, 2011 5 Intended status: Standards Track 6 Expires: May 24, 2012 8 Indicating Character Encoding and Language for HTTP Header Field 9 Parameters 10 draft-reschke-rfc5987bis-02 12 Abstract 14 By default, message header field parameters in Hypertext Transfer 15 Protocol (HTTP) messages cannot carry characters outside the ISO- 16 8859-1 character set. RFC 2231 defines an encoding mechanism for use 17 in Multipurpose Internet Mail Extensions (MIME) headers. This 18 document specifies an encoding suitable for use in HTTP header fields 19 that is compatible with a profile of the encoding defined in RFC 20 2231. 22 Editorial Note (To be removed by RFC Editor before publication) 24 Distribution of this document is unlimited. Although this is not a 25 work item of the HTTPbis Working Group, comments should be sent to 26 the Hypertext Transfer Protocol (HTTP) mailing list at 27 ietf-http-wg@w3.org [1], which may be joined by sending a message 28 with subject "subscribe" to ietf-http-wg-request@w3.org [2]. 30 Discussions of the HTTPbis Working Group are archived at 31 . 33 XML versions, latest edits and the issues list for this document are 34 available from 35 . A 36 collection of test cases is available at 37 . 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 24, 2012. 56 Copyright Notice 58 Copyright (c) 2011 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 75 3. Comparison to RFC 2231 and Definition of the Encoding . . . . 4 76 3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 5 77 3.2. Parameter Value Character Set and Language Information . . 5 78 3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 5 79 3.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.3. Language Specification in Encoded Words . . . . . . . . . 8 81 4. Guidelines for Usage in HTTP Header Field Definitions . . . . 8 82 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 9 83 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 88 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 89 Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . . 12 90 Appendix B. Implementation Report . . . . . . . . . . . . . . . . 12 91 Appendix C. Change Log (to be removed by RFC Editor before 92 publication) . . . . . . . . . . . . . . . . . . . . 13 93 C.1. Since RFC5987 . . . . . . . . . . . . . . . . . . . . . . 13 94 C.2. Since draft-reschke-rfc5987bis-00 . . . . . . . . . . . . 13 95 C.3. Since draft-reschke-rfc5987bis-01 . . . . . . . . . . . . 13 96 Appendix D. Resolved issues (to be removed by RFC Editor 97 before publication) . . . . . . . . . . . . . . . . . 13 98 D.1. impls . . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 Appendix E. Open issues (to be removed by RFC Editor prior to 100 publication) . . . . . . . . . . . . . . . . . . . . 13 101 E.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 E.2. terminology . . . . . . . . . . . . . . . . . . . . . . . 13 103 E.3. parmsyntax . . . . . . . . . . . . . . . . . . . . . . . . 14 104 E.4. valuesyntax . . . . . . . . . . . . . . . . . . . . . . . 14 105 E.5. httpbis . . . . . . . . . . . . . . . . . . . . . . . . . 14 107 1. Introduction 109 By default, message header field parameters in HTTP ([RFC2616]) 110 messages cannot carry characters outside the ISO-8859-1 character set 111 ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an encoding mechanism 112 for use in MIME headers. This document specifies an encoding 113 suitable for use in HTTP header fields that is compatible with a 114 profile of the encoding defined in RFC 2231. 116 This document obsoletes [RFC5987] and moves it to "historic" status; 117 the changes are summarized in Appendix A. 119 Note: in the remainder of this document, RFC 2231 is only 120 referenced for the purpose of explaining the choice of features 121 that were adopted; they are therefore purely informative. 123 Note: this encoding does not apply to message payloads transmitted 124 over HTTP, such as when using the media type "multipart/form-data" 125 ([RFC2388]). 127 2. Notational Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 This specification uses the ABNF (Augmented Backus-Naur Form) 134 notation defined in [RFC5234]. The following core rules are included 135 by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), 136 DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and LWSP 137 (linear whitespace). 139 Note that this specification uses the term "character set" for 140 consistency with other IETF specifications such as RFC 2277 (see 141 [RFC2277], Section 3). A more accurate term would be "character 142 encoding" (a mapping of code points to octet sequences). 144 3. Comparison to RFC 2231 and Definition of the Encoding 146 RFC 2231 defines several extensions to MIME. The sections below 147 discuss if and how they apply to HTTP header fields. 149 In short: 151 o Parameter Continuations aren't needed (Section 3.1), 153 o Character Set and Language Information are useful, therefore a 154 simple subset is specified (Section 3.2), and 156 o Language Specifications in Encoded Words aren't needed 157 (Section 3.3). 159 3.1. Parameter Continuations 161 Section 3 of [RFC2231] defines a mechanism that deals with the length 162 limitations that apply to MIME headers. These limitations do not 163 apply to HTTP ([RFC2616], Section 19.4.7). 165 Thus, parameter continuations are not part of the encoding defined by 166 this specification. 168 3.2. Parameter Value Character Set and Language Information 170 Section 4 of [RFC2231] specifies how to embed language information 171 into parameter values, and also how to encode non-ASCII characters, 172 dealing with restrictions both in MIME and HTTP header parameters. 174 However, RFC 2231 does not specify a mandatory-to-implement character 175 set, making it hard for senders to decide which character set to use. 176 Thus, recipients implementing this specification MUST support the 177 "UTF-8" character set [RFC3629]. 179 Furthermore, RFC 2231 allows the character set information to be left 180 out. The encoding defined by this specification does not allow that. 182 3.2.1. Definition 184 The syntax for parameters is defined in Section 3.6 of [RFC2616] 185 (with RFC 2616 implied LWS translated to RFC 5234 LWSP): 187 parameter = attribute LWSP "=" LWSP value 189 attribute = token 190 value = token / quoted-string 192 quoted-string = 193 token = 195 In order to include character set and language information, this 196 specification modifies the RFC 2616 grammar to be: 198 parameter = reg-parameter / ext-parameter 200 reg-parameter = parmname LWSP "=" LWSP value 202 ext-parameter = parmname "*" LWSP "=" LWSP ext-value 204 parmname = 1*attr-char 206 ext-value = charset "'" [ language ] "'" value-chars 207 ; like RFC 2231's 208 ; (see [RFC2231], Section 7) 210 charset = "UTF-8" / mime-charset 212 mime-charset = 1*mime-charsetc 213 mime-charsetc = ALPHA / DIGIT 214 / "!" / "#" / "$" / "%" / "&" 215 / "+" / "-" / "^" / "_" / "`" 216 / "{" / "}" / "~" 217 ; as in Section 2.3 of [RFC2978] 218 ; except that the single quote is not included 219 ; SHOULD be registered in the IANA charset registry 221 language = 223 value-chars = *( pct-encoded / attr-char ) 225 pct-encoded = "%" HEXDIG HEXDIG 226 ; see [RFC3986], Section 2.1 228 attr-char = ALPHA / DIGIT 229 / "!" / "#" / "$" / "&" / "+" / "-" / "." 230 / "^" / "_" / "`" / "|" / "~" 231 ; token except ( "*" / "'" / "%" ) 233 Thus, a parameter is either a regular parameter (reg-parameter), as 234 previously defined in Section 3.6 of [RFC2616], or an extended 235 parameter (ext-parameter). 237 Extended parameters are those where the left-hand side of the 238 assignment ends with an asterisk character. 240 The value part of an extended parameter (ext-value) is a token that 241 consists of three parts: the REQUIRED character set name (charset), 242 the OPTIONAL language information (language), and a character 243 sequence representing the actual value (value-chars), separated by 244 single quote characters. Note that both character set names and 245 language tags are restricted to the US-ASCII character set, and are 246 matched case-insensitively (see [RFC2978], Section 2.3 and [RFC5646], 247 Section 2.1.1). 249 Inside the value part, characters not contained in attr-char are 250 encoded into an octet sequence using the specified character set. 251 That octet sequence is then percent-encoded as specified in Section 252 2.1 of [RFC3986]. 254 Producers MUST use the "UTF-8" ([RFC3629]) character set. Extension 255 character sets (mime-charset) are reserved for future use. 257 Note: recipients should be prepared to handle encoding errors, 258 such as malformed or incomplete percent escape sequences, or non- 259 decodable octet sequences, in a robust manner. This specification 260 does not mandate any specific behavior, for instance, the 261 following strategies are all acceptable: 263 * ignoring the parameter, 265 * stripping a non-decodable octet sequence, 267 * substituting a non-decodable octet sequence by a replacement 268 character, such as the Unicode character U+FFFD (Replacement 269 Character). 271 Note: the RFC 2616 token production ([RFC2616], Section 2.2) 272 differs from the production used in RFC 2231 (imported from 273 Section 5.1 of [RFC2045]) in that curly braces ("{" and "}") are 274 excluded. Thus, these two characters are excluded from the attr- 275 char production as well. 277 Note: the ABNF defined here differs from the one in 278 Section 2.3 of [RFC2978] in that it does not allow the single 279 quote character (see also RFC Errata ID 1912 [Err1912]). In 280 practice, no character set names using that character have been 281 registered at the time of this writing. 283 Note: [RFC5987] did require support for ISO-8859-1, too; for 284 compatibility with legacy code, recipients are encouraged to 285 support this encoding as well. 287 3.2.2. Examples 289 Non-extended notation, using "token": 291 foo: bar; title=Economy 293 Non-extended notation, using "quoted-string": 295 foo: bar; title="US-$ rates" 297 Extended notation, using the Unicode character U+00A3 (POUND SIGN): 299 foo: bar; title*=utf-8'en'%C2%A3%20rates 301 Note: the Unicode pound sign character U+00A3 was encoded into the 302 octet sequence C2 A3 using the UTF-8 character encoding, then 303 percent-encoded. Also, note that the space character was encoded as 304 %20, as it is not contained in attr-char. 306 Extended notation, using the Unicode characters U+00A3 (POUND SIGN) 307 and U+20AC (EURO SIGN): 309 foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates 311 Note: the Unicode pound sign character U+00A3 was encoded into the 312 octet sequence C2 A3 using the UTF-8 character encoding, then 313 percent-encoded. Likewise, the Unicode euro sign character U+20AC 314 was encoded into the octet sequence E2 82 AC, then percent-encoded. 315 Also note that HEXDIG allows both lowercase and uppercase characters, 316 so recipients must understand both, and that the language information 317 is optional, while the character set is not. 319 3.3. Language Specification in Encoded Words 321 Section 5 of [RFC2231] extends the encoding defined in [RFC2047] to 322 also support language specification in encoded words. Although the 323 HTTP/1.1 specification does refer to RFC 2047 ([RFC2616], Section 324 2.2), it's not clear to which header field exactly it applies, and 325 whether it is implemented in practice (see 326 for details). 328 Thus, this specification does not include this feature. 330 4. Guidelines for Usage in HTTP Header Field Definitions 332 Specifications of HTTP header fields that use the extensions defined 333 in Section 3.2 ought to clearly state that. A simple way to achieve 334 this is to normatively reference this specification, and to include 335 the ext-value production into the ABNF for that header field. 337 For instance: 339 foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param 340 title-param = "title" LWSP "=" LWSP value 341 / "title*" LWSP "=" LWSP ext-value 342 ext-value = 344 Note: The Parameter Value Continuation feature defined in Section 345 3 of [RFC2231] makes it impossible to have multiple instances of 346 extended parameters with identical parmname components, as the 347 processing of continuations would become ambiguous. Thus, 348 specifications using this extension are advised to disallow this 349 case for compatibility with RFC 2231. 351 4.1. When to Use the Extension 353 Section 4.2 of [RFC2277] requires that protocol elements containing 354 human-readable text are able to carry language information. Thus, 355 the ext-value production ought to be always used when the parameter 356 value is of textual nature and its language is known. 358 Furthermore, the extension ought to also be used whenever the 359 parameter value needs to carry characters not present in the US-ASCII 360 ([USASCII]) character set (note that it would be unacceptable to 361 define a new parameter that would be restricted to a subset of the 362 Unicode character set). 364 4.2. Error Handling 366 Header field specifications need to define whether multiple instances 367 of parameters with identical parmname components are allowed, and how 368 they should be processed. This specification suggests that a 369 parameter using the extended syntax takes precedence. This would 370 allow producers to use both formats without breaking recipients that 371 do not understand the extended syntax yet. 373 Example: 375 foo: bar; title="EURO exchange rates"; 376 title*=utf-8''%e2%82%ac%20exchange%20rates 378 In this case, the sender provides an ASCII version of the title for 379 legacy recipients, but also includes an internationalized version for 380 recipients understanding this specification -- the latter obviously 381 ought to prefer the new syntax over the old one. 383 Note: at the time of this writing, many implementations failed to 384 ignore the form they do not understand, or prioritize the ASCII 385 form although the extended syntax was present. 387 5. Security Considerations 389 The format described in this document makes it possible to transport 390 non-ASCII characters, and thus enables character "spoofing" 391 scenarios, in which a displayed value appears to be something other 392 than it is. 394 Furthermore, there are known attack scenarios relating to decoding 395 UTF-8. 397 See Section 10 of [RFC3629] for more information on both topics. 399 In addition, the extension specified in this document makes it 400 possible to transport multiple language variants for a single 401 parameter, and such use might allow spoofing attacks, where different 402 language versions of the same parameter are not equivalent. Whether 403 this attack is useful as an attack depends on the parameter 404 specified. 406 6. Acknowledgements 408 Thanks to Martin Duerst and Frank Ellermann for help figuring out 409 ABNF details, to Graham Klyne and Alexey Melnikov for general review, 410 to Chris Newman for pointing out an RFC 2231 incompatibility, and to 411 Benjamin Carlyle, Roar Lauritzsen, and Eric Lawrence for 412 implementer's feedback. 414 7. References 416 7.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 422 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 423 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 425 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 426 Procedures", BCP 19, RFC 2978, October 2000. 428 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 429 10646", STD 63, RFC 3629, November 2003. 431 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 432 "Uniform Resource Identifier (URI): Generic Syntax", 433 STD 66, RFC 3986, January 2005. 435 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 436 Syntax Specifications: ABNF", STD 68, RFC 5234, 437 January 2008. 439 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for 440 Identifying Languages", BCP 47, RFC 5646, 441 September 2009. 443 [USASCII] American National Standards Institute, "Coded Character 444 Set -- 7-bit American Standard Code for Information 445 Interchange", ANSI X3.4, 1986. 447 7.2. Informative References 449 [Err1912] RFC Errata, "Errata ID 1912, RFC 2978", 450 . 452 [ISO-8859-1] International Organization for Standardization, 453 "Information technology -- 8-bit single-byte coded 454 graphic character sets -- Part 1: Latin alphabet No. 455 1", ISO/IEC 8859-1:1998, 1998. 457 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 458 Mail Extensions (MIME) Part One: Format of Internet 459 Message Bodies", RFC 2045, November 1996. 461 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 462 Extensions) Part Three: Message Header Extensions for 463 Non-ASCII Text", RFC 2047, November 1996. 465 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and 466 Encoded Word Extensions: Character Sets, Languages, and 467 Continuations", RFC 2231, November 1997. 469 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 470 Languages", BCP 18, RFC 2277, January 1998. 472 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 473 form-data", RFC 2388, August 1998. 475 [RFC5987] Reschke, J., "Character Set and Language Encoding for 476 Hypertext Transfer Protocol (HTTP) Header Field 477 Parameters", RFC 5987, August 2010. 479 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 481 [RFC6266] Reschke, J., "Use of the Content-Disposition Header 482 Field in the Hypertext Transfer Protocol (HTTP)", 483 RFC 6266, June 2011. 485 URIs 487 [1] 489 [2] 491 Appendix A. Changes from RFC 5987 493 This section summarizes the changes compared to [RFC5987]: 495 o The document title was changed to "Indicating Character Encoding 496 and Language for HTTP Header Field Parameters". 498 o The requirement to support the "ISO-8859-1" encoding was removed. 500 Appendix B. Implementation Report 502 The encoding defined in this document currently is used for two 503 different HTTP header fields: 505 o "Content-Disposition", defined in [RFC6266], and 507 o "Link", defined in [RFC5988]. 509 As the encoding is a profile/clarification of the one defined in 510 [RFC2231] in 1997, many user agents already supported it for use in 511 "Content-Disposition" when [RFC5987] got published. 513 Since the publication of [RFC5987], two more popular desktop user 514 agents have added support for this encoding; see for details. 516 At this time, only one major desktop user agent (Safari) does not 517 support it. 519 Note that the implementation in Internet Explorer 9 does not support 520 the ISO-8859-1 encoding; this document revision acknowledges that 521 UTF-8 is sufficient for expressing all code points, and removes the 522 requirement to support ISO-8859-1. 524 The "Link" header field, on the other hand, was only recently 525 specified in [RFC5988]. At the time of this writing, no User Agent 526 supported the "title*" parameter, using the encoding defined by this 527 document, but implementation for Firefox was already in progress (see 528 ). 530 Appendix C. Change Log (to be removed by RFC Editor before publication) 532 C.1. Since RFC5987 534 Only editorial changes for the purpose of starting the revision 535 process (obs5987). 537 C.2. Since draft-reschke-rfc5987bis-00 539 Resolved issues "iso-8859-1" and "title" (title simplified). Added 540 and resolved issue "historic5987". 542 C.3. Since draft-reschke-rfc5987bis-01 544 Added issues "httpbis", "parmsyntax", "terminology" and 545 "valuesyntax". Closed issue "impls". 547 Appendix D. Resolved issues (to be removed by RFC Editor before 548 publication) 550 Issues that were either rejected or resolved in this version of this 551 document. 553 D.1. impls 555 Type: change 557 julian.reschke@greenbytes.de (2011-04-15): Add implementation report. 559 Appendix E. Open issues (to be removed by RFC Editor prior to 560 publication) 562 E.1. edit 564 Type: edit 566 julian.reschke@greenbytes.de (2011-04-15): Umbrella issue for 567 editorial fixes/enhancements. 569 E.2. terminology 571 Type: edit 573 julian.reschke@greenbytes.de (2011-09-17): Try to be consistent with 574 the terminology defined in RFC 6365. 576 E.3. parmsyntax 578 Type: edit 580 583 James.H.Manger@team.telstra.com (2011-11-02): Noted by James Manger: 584 "Presumably RFC5987 (or its predecessors) decided it was highly 585 unlikely that any parameter names in use ended in "*" (though they 586 are valid) so it could redefine the syntax of values for such names." 587 - add a note that the notation indeed overloads parameter name syntax 588 and clarify the use. 590 E.4. valuesyntax 592 Type: edit 594 597 James.H.Manger@team.telstra.com (2011-11-02): Noted by James Manger: 598 "Curiously, RFC5987 disobeys the proposed recommendations for new 599 parameters. It allows foo*=UTF-8''coll%C3%A8gues but not foo*="UTF- 600 8''coll%C3%A8gues" That might be ok with a parser that understands 601 token, quoted-string, and RFC5987, but presumably it will cause 602 problems when RFC5987 processing is done after a "standard httpbis 603 parser" handles the token | quoted-string step. " - add a note 604 clarifying that this is indeed a shortcoming of the format, and what 605 it means for implementations. 607 E.5. httpbis 609 Type: edit 611 julian.reschke@greenbytes.de (2011-09-17): The document refers 612 normatively to RFC 2616. Should it continue to do so, or should we 613 wait for HTTPbis? This may affect edge case in the ABNF, such as the 614 definition of linear white space or the characters allowed in 615 "token". 617 Author's Address 619 Julian F. Reschke 620 greenbytes GmbH 621 Hafenweg 16 622 Muenster, NW 48155 623 Germany 625 EMail: julian.reschke@greenbytes.de 626 URI: http://greenbytes.de/tech/webdav/