idnits 2.17.1 draft-reschke-rfc2231-in-http-12.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 abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (April 30, 2010) is 5082 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' ** 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' -- Obsolete informational reference (is this intentional?): RFC 2388 (Obsoleted by RFC 7578) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 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 Intended status: Standards Track April 30, 2010 5 Expires: November 1, 2010 7 Character Set and Language Encoding for Hypertext Transfer Protocol 8 (HTTP) Header Field Parameters 9 draft-reschke-rfc2231-in-http-12 11 Abstract 13 By default, message header field parameters in Hypertext Transfer 14 Protocol (HTTP) messages can not carry characters outside the ISO- 15 8859-1 character set. RFC 2231 defines an encoding mechanism for use 16 in Multipurpose Internet Mail Extensions (MIME) headers. This 17 document specifies an encoding suitable for use in HTTP header fields 18 which is compatible to a profile of the encoding defined in RFC 2231. 20 Editorial Note (To be removed by RFC Editor before publication) 22 There are multiple HTTP header fields that already use RFC 2231 23 encoding in practice (Content-Disposition) or might use it in the 24 future (Link). The purpose of this document is to provide a single 25 place where the generic aspects of RFC 2231 encoding in HTTP header 26 fields are defined. 28 Distribution of this document is unlimited. Although this is not a 29 work item of the HTTPbis Working Group, comments should be sent to 30 the Hypertext Transfer Protocol (HTTP) mailing list at 31 ietf-http-wg@w3.org [1], which may be joined by sending a message 32 with subject "subscribe" to ietf-http-wg-request@w3.org [2]. 34 Discussions of the HTTPbis Working Group are archived at 35 . 37 XML versions, latest edits and the issues list for this document are 38 available from 39 . A 40 collection of test cases is available at 41 . 43 Note: as of February 2010, there were at least three independent 44 implementations of the encoding defined in Section 3.2: Konqueror 45 (starting with 4.4.1), Mozilla Firefox, and Opera. 47 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on November 1, 2010. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 82 3. Comparison to RFC 2231 and Definition of the Encoding . . . . 4 83 3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 5 84 3.2. Parameter Value Character Set and Language Information . . 5 85 3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 5 86 3.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 7 87 3.3. Language specification in Encoded Words . . . . . . . . . 8 88 4. Guidelines for Usage in HTTP Header Field Definitions . . . . 8 89 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 9 90 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 97 Appendix A. Document History and Future Plans (to be removed 98 by RFC Editor before publication) . . . . . . . . . . 12 99 Appendix B. Change Log (to be removed by RFC Editor before 100 publication) . . . . . . . . . . . . . . . . . . . . 12 101 B.1. Since draft-reschke-rfc2231-in-http-00 . . . . . . . . . . 12 102 B.2. Since draft-reschke-rfc2231-in-http-01 . . . . . . . . . . 12 103 B.3. Since draft-reschke-rfc2231-in-http-02 . . . . . . . . . . 13 104 B.4. Since draft-reschke-rfc2231-in-http-03 . . . . . . . . . . 13 105 B.5. Since draft-reschke-rfc2231-in-http-04 . . . . . . . . . . 13 106 B.6. Since draft-reschke-rfc2231-in-http-05 . . . . . . . . . . 13 107 B.7. Since draft-reschke-rfc2231-in-http-06 . . . . . . . . . . 13 108 B.8. Since draft-reschke-rfc2231-in-http-07 . . . . . . . . . . 13 109 B.9. Since draft-reschke-rfc2231-in-http-08 . . . . . . . . . . 13 110 B.10. Since draft-reschke-rfc2231-in-http-09 . . . . . . . . . . 13 111 B.11. Since draft-reschke-rfc2231-in-http-10 . . . . . . . . . . 13 112 B.12. Since draft-reschke-rfc2231-in-http-11 . . . . . . . . . . 14 113 Appendix C. Resolved issues (to be removed by RFC Editor 114 before publication) . . . . . . . . . . . . . . . . . 14 115 C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 116 C.2. nonorm2231 . . . . . . . . . . . . . . . . . . . . . . . . 14 118 1. Introduction 120 By default, message header field parameters in HTTP ([RFC2616]) 121 messages can not carry characters outside the ISO-8859-1 character 122 set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an encoding 123 mechanism for use in MIME headers. This document specifies an 124 encoding suitable for use in HTTP header fields which is compatible 125 to a profile of the encoding defined in RFC 2231. 127 Note: in the remainder of this document, RFC 2231 is only 128 referenced for the purpose of explaining the choice of features 129 that were adopted; they are therefore purely informative. 131 Note: this encoding does not apply to message payloads transmitted 132 over HTTP, such as when using the media type "multipart/form-data" 133 ([RFC2388]). 135 2. Notational Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 This specification uses the ABNF (Augmented Backus-Naur Form) 142 notation defined in [RFC5234]. The following core rules are included 143 by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), 144 DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f) and LWSP 145 (linear white space). 147 Note that this specification uses the term "character set" for 148 consistency with other IETF specifications such as RFC 2277 (see 149 [RFC2277], Section 3). A more accurate term would be "character 150 encoding" (a mapping of code points to octet sequences). 152 3. Comparison to RFC 2231 and Definition of the Encoding 154 RFC 2231 defines several extensions to MIME. The sections below 155 discuss if and how they apply to HTTP header fields. 157 In short: 159 o Parameter Continuations aren't needed (Section 3.1), 161 o Character Set and Language Information are useful, therefore a 162 simple subset is specified (Section 3.2), and 164 o Language Specifications in Encoded Words aren't needed 165 (Section 3.3). 167 3.1. Parameter Continuations 169 Section 3 of [RFC2231] defines a mechanism that deals with the length 170 limitations that apply to MIME headers. These limitations do not 171 apply to HTTP ([RFC2616], Section 19.4.7). 173 Thus, parameter continuations are not part of the encoding defined by 174 this specification. 176 3.2. Parameter Value Character Set and Language Information 178 Section 4 of [RFC2231] specifies how to embed language information 179 into parameter values, and also how to encode non-ASCII characters, 180 dealing with restrictions both in MIME and HTTP header parameters. 182 However, RFC 2231 does not specify a mandatory-to-implement character 183 set, making it hard for senders to decide which character set to use. 184 Thus, recipients implementing this specification MUST support the 185 character sets "ISO-8859-1" [ISO-8859-1] and "UTF-8" [RFC3629]. 187 Furthermore, RFC 2231 allows leaving out the character set 188 information. The encoding defined by this specification does not 189 allow that. 191 3.2.1. Definition 193 The syntax for parameters is defined in Section 3.6 of [RFC2616] 194 (with RFC 2616 implied LWS translated to RFC 5234 LWSP): 196 parameter = attribute LWSP "=" LWSP value 198 attribute = token 199 value = token / quoted-string 201 quoted-string = 202 token = 204 In order to include character set and language information, this 205 specification modifies the RFC 2616 grammar to: 207 parameter = reg-parameter / ext-parameter 209 reg-parameter = parmname LWSP "=" LWSP value 211 ext-parameter = parmname "*" LWSP "=" LWSP ext-value 213 parmname = 1*attr-char 215 ext-value = charset "'" [ language ] "'" value-chars 216 ; like RFC 2231's 217 ; (see [RFC2231], Section 7) 219 charset = "UTF-8" / "ISO-8859-1" / mime-charset 221 mime-charset = 1*mime-charsetc 222 mime-charsetc = ALPHA / DIGIT 223 / "!" / "#" / "$" / "%" / "&" 224 / "+" / "-" / "^" / "_" / "`" 225 / "{" / "}" / "~" 226 ; as in Section 2.3 of [RFC2978] 227 ; except that the single quote is not included 228 ; SHOULD be registered in the IANA charset registry 230 language = 232 value-chars = *( pct-encoded / attr-char ) 234 pct-encoded = "%" HEXDIG HEXDIG 235 ; see [RFC3986], Section 2.1 237 attr-char = ALPHA / DIGIT 238 / "!" / "#" / "$" / "&" / "+" / "-" / "." 239 / "^" / "_" / "`" / "|" / "~" 240 ; token except ( "*" / "'" / "%" ) 242 Thus, a parameter is either regular parameter (reg-parameter), as 243 previously defined in Section 3.6 of [RFC2616], or an extended 244 parameter (ext-parameter). 246 Extended parameters are those where the left hand side of the 247 assignment ends with an asterisk character. 249 The value part of an extended parameter (ext-value) is a token that 250 consists of three parts: the REQUIRED character set name (charset), 251 the OPTIONAL language information (language), and a character 252 sequence representing the actual value (value-chars), separated by 253 single quote characters. Note that both character set names and 254 language tags are restricted to the US-ASCII character set, and are 255 matched case-insensitively (see [RFC2978], Section 2.3 and [RFC5646], 256 Section 2.1.1). 258 Inside the value part, characters not contained in attr-char are 259 encoded into an octet sequence using the specified character set. 260 That octet sequence then is percent-encoded as specified in Section 261 2.1 of [RFC3986]. 263 Producers MUST use either the "UTF-8" ([RFC3629]) or the "ISO-8859-1" 264 ([ISO-8859-1]) character set. Extension character sets (mime- 265 charset) are reserved for future use. 267 Note: recipients should be prepared to handle encoding errors, 268 such as malformed or incomplete percent escape sequences, or non- 269 decodable octet sequences, in a robust manner. This specification 270 does not mandate any specific behavior, for instance the following 271 strategies are all acceptable: 273 * ignoring the parameter, 275 * stripping a non-decodable octet sequence, 277 * substituting a non-decodable octet sequence by a replacement 278 character, such as the Unicode character U+FFFD (Replacement 279 Character). 281 Note: the RFC 2616 token production ([RFC2616], Section 2.2) 282 differs from the production used in RFC 2231 (imported from 283 Section 5.1 of [RFC2045]) in that curly braces ("{" and "}") are 284 excluded. Thus, these two characters are excluded from the attr- 285 char production as well. 287 Note: the ABNF defined here differs from the one in 288 Section 2.3 of [RFC2978] in that it does not allow the single 289 quote character (see also RFC Editor Errata ID 1912 [3]). In 290 practice, no character set names using that character have been 291 registered at the time of this writing. 293 3.2.2. Examples 295 Non-extended notation, using "token": 297 foo: bar; title=Economy 299 Non-extended notation, using "quoted-string": 301 foo: bar; title="US-$ rates" 303 Extended notation, using the unicode character U+00A3 (POUND SIGN): 305 foo: bar; title*=iso-8859-1'en'%A3%20rates 307 Note: the Unicode pound sign character U+00A3 was encoded using ISO- 308 8859-1 into the single octet A3, then percent-encoded. Also note 309 that the space character was encoded as %20, as it is not contained 310 in attr-char. 312 Extended notation, using the unicode characters U+00A3 (POUND SIGN) 313 and U+20AC (EURO SIGN): 315 foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates 317 Note: the unicode pound sign character U+00A3 was encoded using UTF-8 318 into the octet sequence C2 A3, then percent-encoded. Likewise, the 319 unicode euro sign character U+20AC was encoded into the octet 320 sequence E2 82 AC, then percent-encoded. Also note that HEXDIG 321 allows both lower-case and upper-case character, so recipients must 322 understand both, and that the language information is optional, while 323 the character set is not. 325 3.3. Language specification in Encoded Words 327 Section 5 of [RFC2231] extends the encoding defined in [RFC2047] to 328 also support language specification in encoded words. Although the 329 HTTP/1.1 specification does refer to RFC 2047 ([RFC2616], Section 330 2.2), it's not clear to which header field exactly it applies, and 331 whether it is implemented in practice (see 332 for details). 334 Thus, this specification does not include this feature. 336 4. Guidelines for Usage in HTTP Header Field Definitions 338 Specifications of HTTP header fields that use the extensions defined 339 in Section 3.2 ought to clearly state that. A simple way to achieve 340 this is to normatively reference this specification, and to include 341 the ext-value production into the ABNF for that header field. 343 For instance: 345 foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param 346 title-param = "title" LWSP "=" LWSP value 347 / "title*" LWSP "=" LWSP ext-value 348 ext-value = 350 [[rfcno: Note to RFC Editor: in the figure above, please replace 351 "xxxx" by the RFC number assigned to this specification.]] 353 Note: The Parameter Value Continuation feature defined in Section 354 3 of [RFC2231] makes it impossible to have multiple instances of 355 extended parameters with identical parmname components, as the 356 processing of continuations would become ambiguous. Thus, 357 specifications using this extension are advised to disallow this 358 case for compatibility with RFC 2231. 360 4.1. When to Use the Extension 362 Section 4.2 of [RFC2277] requires that protocol elements containing 363 human-readable text are able to carry language information. Thus, 364 the ext-value production ought to be always used when the parameter 365 value is of textual nature and its language is known. 367 Furthermore, the extension ought to also be used whenever the 368 parameter value needs to carry characters not present in the US-ASCII 369 ([USASCII]) character set (note that it would be unacceptable to 370 define a new parameter that would be restricted to a subset of the 371 Unicode character set). 373 4.2. Error Handling 375 Header field specifications need to define whether multiple instances 376 of parameters with identical parmname components are allowed, and how 377 they should processed. This specification suggests that a parameter 378 using the extended syntax takes precedence. This could be used by 379 producers to use both formats without breaking recipients that do not 380 understand the extended syntax yet. 382 Example: 384 foo: bar; title="EURO exchange rates"; 385 title*=utf-8''%e2%82%ac%20exchange%20rates 387 In this case, the sender provides an ASCII version of the title for 388 legacy recipients, but also includes an internationalized version for 389 recipients understanding this specification -- the latter obviously 390 ought to prefer the new syntax over the old one. 392 Note: at the time of this writing, many implementations failed to 393 ignore the form they do not understand, or prioritize the ASCII 394 form although the extended syntax was present. 396 5. Security Considerations 398 The format described in this document makes it possible to transport 399 non-ASCII characters, and thus enables character "spoofing" 400 scenarios, in which a displayed value appears to be something other 401 than it is. 403 Furthermore, there are known attack scenarios relating to decoding 404 UTF-8. 406 See Section 10 of [RFC3629] for more information on both topics. 408 In addition, the extension specified in this document makes it 409 possible to transport multiple language variants for a single 410 parameter, and such use might allow spoofing attacks, where different 411 language versions of the same parameter are not equivalent. Whether 412 this attack is useful as an attack depends on the parameter 413 specified. 415 6. IANA Considerations 417 There are no IANA Considerations related to this specification. 419 7. Acknowledgements 421 Thanks to Martin Duerst and Frank Ellermann for help figuring out 422 ABNF details, to Graham Klyne and Alexey Melnikov for general review, 423 Chris Newman for pointing out an RFC 2231 incompatibility, and to 424 Benjamin Carlyle and Roar Lauritzsen for implementer's feedback. 426 8. References 428 8.1. Normative References 430 [ISO-8859-1] International Organization for Standardization, 431 "Information technology -- 8-bit single-byte coded 432 graphic character sets -- Part 1: Latin alphabet No. 433 1", ISO/IEC 8859-1:1998, 1998. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 439 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 440 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 442 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 443 Procedures", BCP 19, RFC 2978, October 2000. 445 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 446 10646", RFC 3629, STD 63, November 2003. 448 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 449 "Uniform Resource Identifier (URI): Generic Syntax", 450 RFC 3986, STD 66, January 2005. 452 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 453 Syntax Specifications: ABNF", STD 68, RFC 5234, 454 January 2008. 456 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for 457 Identifying Languages", BCP 47, RFC 5646, 458 September 2009. 460 [USASCII] American National Standards Institute, "Coded Character 461 Set -- 7-bit American Standard Code for Information 462 Interchange", ANSI X3.4, 1986. 464 8.2. Informative References 466 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 467 Mail Extensions (MIME) Part One: Format of Internet 468 Message Bodies", RFC 2045, November 1996. 470 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 471 Extensions) Part Three: Message Header Extensions for 472 Non-ASCII Text", RFC 2047, November 1996. 474 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and 475 Encoded Word Extensions: Character Sets, Languages, and 476 Continuations", RFC 2231, November 1997. 478 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 479 Languages", BCP 18, RFC 2277, January 1998. 481 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 482 form-data", RFC 2388, August 1998. 484 URIs 486 [1] 488 [2] 490 [3] 492 Appendix A. Document History and Future Plans (to be removed by RFC 493 Editor before publication) 495 Problems with the internationalization of the HTTP Content- 496 Disposition header field have been known for many years (see test 497 cases at ). 499 During IETF 72 500 (), the 501 HTTPbis Working Group shortly discussed how to deal with the 502 underspecification of (1) Content-Disposition, and its (2) 503 internationalization aspects. Back then, there was rough consensus 504 in the room to move the definition into a separate draft. 506 This specification addresses problem (2), by defining a simple subset 507 of the encoding format defined in RFC 2231. A separate 508 specification, draft-reschke-rfc2183-in-http, is planned to address 509 problem (1). Note that this approach was chosen because Content- 510 Disposition is just an example for an HTTP header field using this 511 kind of encoding. Another example is the currently proposed Link 512 header field (draft-nottingham-http-link-header). 514 This document is planned to be published on the IETF Standards Track, 515 so that other standards-track level documents can depend on it, such 516 as the new specification of Content-Disposition, or potentially 517 future revisions of the HTTP Link Header specification. 519 Also note that this document specifies a proper subset of the 520 extensions defined in RFC 2231, but does not normatively refer to it. 521 Thus, RFC 2231 can be revised separately, should the email community 522 decide to. 524 Appendix B. Change Log (to be removed by RFC Editor before publication) 526 B.1. Since draft-reschke-rfc2231-in-http-00 528 Use RFC5234-style ABNF, closer to the one used in RFC 2231. 530 Make RFC 2231 dependency informative, so this specification can 531 evolve independently. 533 Explain the ABNF in prose. 535 B.2. Since draft-reschke-rfc2231-in-http-01 537 Remove unneeded RFC5137 notation (code point vs character). 539 B.3. Since draft-reschke-rfc2231-in-http-02 541 And and resolve issues "charset", "repeats" and "rfc4646". 543 B.4. Since draft-reschke-rfc2231-in-http-03 545 And and resolve issue "charsetmatch". 547 B.5. Since draft-reschke-rfc2231-in-http-04 549 Add and resolve issues "badseq" and "tokenquotcharset". 551 B.6. Since draft-reschke-rfc2231-in-http-05 553 Say "header field" instead of "header" in the context of HTTP. 555 B.7. Since draft-reschke-rfc2231-in-http-06 557 Add an appendix discussing document history and future plans, to be 558 removed before publication. 560 B.8. Since draft-reschke-rfc2231-in-http-07 562 Add and resolve issues "impl" and "rel-2388". 564 B.9. Since draft-reschke-rfc2231-in-http-08 566 Editorial improvements. Add and resolve issues "attrcharvstoken" and 567 "tokengrammar". 569 B.10. Since draft-reschke-rfc2231-in-http-09 571 Add issues "i18n-spoofing", "iso8859", "parameter-abnf", and "when- 572 ext-value". Add and resolve issues "rfc2978-normative", "rfc3986- 573 normative" and "usascii-normative". 575 B.11. Since draft-reschke-rfc2231-in-http-10 577 Resolve issues "i18n-spoofing", "iso8859", "parameter-abnf", and 578 "when-ext-value". 580 Add and resolve issue "charset-registered", "handling-multiple", 581 "multiple-inst-spoofing", "repeated-param" and "value-abnf". 583 Update the KDE implementation note. 585 B.12. Since draft-reschke-rfc2231-in-http-11 587 In the prose in Section 3.2, "ext-charset" -> "mime-charset". In 588 Section 4, avoid the use of "should" and "recommended". In 589 Section 4.1 clarify that the RFC 2277 requirement is about human- 590 readable text. Clarify parts that made it look as if this spec has a 591 normative dependency on RFC 2231 (new issue "nonorm2231"). 593 Appendix C. Resolved issues (to be removed by RFC Editor before 594 publication) 596 Issues that were either rejected or resolved in this version of this 597 document. 599 C.1. edit 601 Type: edit 603 julian.reschke@greenbytes.de (2009-04-17): Umbrella issue for 604 editorial fixes/enhancements. 606 C.2. nonorm2231 608 Type: edit 610 julian.reschke@greenbytes.de (2010-04-23): It's not totally clear 611 that the mentions of RFC 2231 really are all informative. 613 Resolution (2010-04-28): Clarify title of the spec, plus text talking 614 about RFC 2231. Avoid saying "profile" in general. 616 Author's Address 618 Julian F. Reschke 619 greenbytes GmbH 620 Hafenweg 16 621 Muenster, NW 48155 622 Germany 624 EMail: julian.reschke@greenbytes.de 625 URI: http://greenbytes.de/tech/webdav/