idnits 2.17.1 draft-reschke-rfc5987bis-07.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. -- 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 (July 2, 2014) is 3579 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) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- 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: 4 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) July 2, 2014 5 Intended status: Standards Track 6 Expires: January 3, 2015 8 Indicating Character Encoding and Language for HTTP Header Field 9 Parameters 10 draft-reschke-rfc5987bis-07 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, diffs, and the issues list for this 34 document are 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 January 3, 2015. 56 Copyright Notice 58 Copyright (c) 2014 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 Encoding and Language 78 Information . . . . . . . . . . . . . . . . . . . . . . . 5 79 3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 5 80 3.2.2. Historical Notes . . . . . . . . . . . . . . . . . . . 7 81 3.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.3. Language Specification in Encoded Words . . . . . . . . . 8 83 4. Guidelines for Usage in HTTP Header Field Definitions . . . . 9 84 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 9 85 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 92 Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . . 12 93 Appendix B. Implementation Report . . . . . . . . . . . . . . . . 13 94 Appendix C. Change Log (to be removed by RFC Editor before 95 publication) . . . . . . . . . . . . . . . . . . . . 13 96 C.1. Since RFC5987 . . . . . . . . . . . . . . . . . . . . . . 13 97 C.2. Since draft-reschke-rfc5987bis-00 . . . . . . . . . . . . 13 98 C.3. Since draft-reschke-rfc5987bis-01 . . . . . . . . . . . . 14 99 C.4. Since draft-reschke-rfc5987bis-02 . . . . . . . . . . . . 14 100 C.5. Since draft-reschke-rfc5987bis-03 . . . . . . . . . . . . 14 101 C.6. Since draft-reschke-rfc5987bis-04 . . . . . . . . . . . . 14 102 C.7. Since draft-reschke-rfc5987bis-05 . . . . . . . . . . . . 14 103 C.8. Since draft-reschke-rfc5987bis-06 . . . . . . . . . . . . 14 104 Appendix D. Open issues (to be removed by RFC Editor prior to 105 publication) . . . . . . . . . . . . . . . . . . . . 14 106 D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 107 D.2. httpbis . . . . . . . . . . . . . . . . . . . . . . . . . 14 109 1. Introduction 111 By default, message header field parameters in HTTP ([RFC2616]) 112 messages cannot carry characters outside the ISO-8859-1 coded 113 character set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an 114 encoding mechanism for use in MIME headers. This document specifies 115 an encoding suitable for use in HTTP header fields that is compatible 116 with a profile of the encoding defined in RFC 2231. 118 This document obsoletes [RFC5987] and moves it to "historic" status; 119 the changes are summarized in Appendix A. 121 Note: in the remainder of this document, RFC 2231 is only 122 referenced for the purpose of explaining the choice of features 123 that were adopted; they are therefore purely informative. 125 Note: this encoding does not apply to message payloads transmitted 126 over HTTP, such as when using the media type "multipart/form-data" 127 ([RFC2388]). 129 2. Notational Conventions 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 This specification uses the ABNF (Augmented Backus-Naur Form) 136 notation defined in [RFC5234]. The following core rules are included 137 by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), 138 DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and LWSP 139 (linear whitespace). 141 This specification uses terminology defined in [RFC6365], namely: 142 "character encoding scheme" (below abbreviated to "character 143 encoding"), "charset" and "coded character set". 145 Note that this differs from RFC 2231, which uses the term "character 146 set" for "character encoding scheme". 148 3. Comparison to RFC 2231 and Definition of the Encoding 150 RFC 2231 defines several extensions to MIME. The sections below 151 discuss if and how they apply to HTTP header fields. 153 In short: 155 o Parameter Continuations aren't needed (Section 3.1), 156 o Character Encoding and Language Information are useful, therefore 157 a simple subset is specified (Section 3.2), and 159 o Language Specifications in Encoded Words aren't needed 160 (Section 3.3). 162 3.1. Parameter Continuations 164 Section 3 of [RFC2231] defines a mechanism that deals with the length 165 limitations that apply to MIME headers. These limitations do not 166 apply to HTTP ([RFC7231], Appendix A.6). 168 Thus, parameter continuations are not part of the encoding defined by 169 this specification. 171 3.2. Parameter Value Character Encoding and Language Information 173 Section 4 of [RFC2231] specifies how to embed language information 174 into parameter values, and also how to encode non-ASCII characters, 175 dealing with restrictions both in MIME and HTTP header field 176 parameters. 178 However, RFC 2231 does not specify a mandatory-to-implement character 179 encoding, making it hard for senders to decide which encoding to use. 180 Thus, recipients implementing this specification MUST support the 181 "UTF-8" character encoding [RFC3629]. 183 Furthermore, RFC 2231 allows the character encoding information to be 184 left out. The encoding defined by this specification does not allow 185 that. 187 3.2.1. Definition 189 The syntax for parameters is defined in Section 3.6 of [RFC2616] 190 (with RFC 2616 implied LWS translated to RFC 5234 LWSP): 192 parameter = attribute LWSP "=" LWSP value 194 attribute = token 195 value = token / quoted-string 197 quoted-string = 198 token = 200 In order to include character encoding and language information, this 201 specification modifies the RFC 2616 grammar to be: 203 parameter = reg-parameter / ext-parameter 205 reg-parameter = parmname LWSP "=" LWSP value 207 ext-parameter = parmname "*" LWSP "=" LWSP ext-value 209 parmname = 1*attr-char 211 ext-value = charset "'" [ language ] "'" value-chars 212 ; like RFC 2231's 213 ; (see [RFC2231], Section 7) 215 charset = "UTF-8" / mime-charset 217 mime-charset = 1*mime-charsetc 218 mime-charsetc = ALPHA / DIGIT 219 / "!" / "#" / "$" / "%" / "&" 220 / "+" / "-" / "^" / "_" / "`" 221 / "{" / "}" / "~" 222 ; as in Section 2.3 of [RFC2978] 223 ; except that the single quote is not included 224 ; SHOULD be registered in the IANA charset registry 226 language = 228 value-chars = *( pct-encoded / attr-char ) 230 pct-encoded = "%" HEXDIG HEXDIG 231 ; see [RFC3986], Section 2.1 233 attr-char = ALPHA / DIGIT 234 / "!" / "#" / "$" / "&" / "+" / "-" / "." 235 / "^" / "_" / "`" / "|" / "~" 236 ; token except ( "*" / "'" / "%" ) 238 Thus, a parameter is either a regular parameter (reg-parameter), as 239 previously defined in Section 3.6 of [RFC2616], or an extended 240 parameter (ext-parameter). 242 Extended parameters are those where the left-hand side of the 243 assignment ends with an asterisk character. 245 The value part of an extended parameter (ext-value) is a token that 246 consists of three parts: the REQUIRED character encoding name 247 (charset), the OPTIONAL language information (language), and a 248 character sequence representing the actual value (value-chars), 249 separated by single quote characters. Note that both character 250 encoding names and language tags are restricted to the US-ASCII coded 251 character set, and are matched case-insensitively (see [RFC2978], 252 Section 2.3 and [RFC5646], Section 2.1.1). 254 Inside the value part, characters not contained in attr-char are 255 encoded into an octet sequence using the specified character 256 encoding. That octet sequence is then percent-encoded as specified 257 in Section 2.1 of [RFC3986]. 259 Producers MUST use the "UTF-8" ([RFC3629]) character encoding. 260 Extension character encodings (mime-charset) are reserved for future 261 use. 263 Note: recipients should be prepared to handle encoding errors, 264 such as malformed or incomplete percent escape sequences, or non- 265 decodable octet sequences, in a robust manner. This specification 266 does not mandate any specific behavior, for instance, the 267 following strategies are all acceptable: 269 * ignoring the parameter, 271 * stripping a non-decodable octet sequence, 273 * substituting a non-decodable octet sequence by a replacement 274 character, such as the Unicode character U+FFFD (Replacement 275 Character). 277 3.2.2. Historical Notes 279 The RFC 7230 token production ([RFC7230], Section 3.2.6) differs from 280 the production used in RFC 2231 (imported from Section 5.1 of 281 [RFC2045]) in that curly braces ("{" and "}") are excluded. Thus, 282 these two characters are excluded from the attr-char production as 283 well. 285 The ABNF defined here differs from the one in Section 286 2.3 of [RFC2978] in that it does not allow the single quote character 287 (see also RFC Errata ID 1912 [Err1912]). In practice, no character 288 encoding names using that character have been registered at the time 289 of this writing. 291 For backwards compatibility with RFC 2231, the encoding defined by 292 this specification deviates from common parameter syntax in that the 293 quoted-string notation is not allowed. Implementations using generic 294 parser components might not be able to detect the use of quoted- 295 string notation and thus might accept that format, although invalid, 296 as well. 298 [RFC5987] did require support for ISO-8859-1, too; for compatibility 299 with legacy code, recipients are encouraged to support this encoding 300 as well. 302 3.2.3. Examples 304 Non-extended notation, using "token": 306 foo: bar; title=Economy 308 Non-extended notation, using "quoted-string": 310 foo: bar; title="US-$ rates" 312 Extended notation, using the Unicode character U+00A3 (POUND SIGN): 314 foo: bar; title*=utf-8'en'%C2%A3%20rates 316 Note: the Unicode pound sign character U+00A3 was encoded into the 317 octet sequence C2 A3 using the UTF-8 character encoding, then 318 percent-encoded. Also, note that the space character was encoded as 319 %20, as it is not contained in attr-char. 321 Extended notation, using the Unicode characters U+00A3 (POUND SIGN) 322 and U+20AC (EURO SIGN): 324 foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates 326 Note: the Unicode pound sign character U+00A3 was encoded into the 327 octet sequence C2 A3 using the UTF-8 character encoding, then 328 percent-encoded. Likewise, the Unicode euro sign character U+20AC 329 was encoded into the octet sequence E2 82 AC, then percent-encoded. 330 Also note that HEXDIG allows both lowercase and uppercase characters, 331 so recipients must understand both, and that the language information 332 is optional, while the character encoding is not. 334 3.3. Language Specification in Encoded Words 336 Section 5 of [RFC2231] extends the encoding defined in [RFC2047] to 337 also support language specification in encoded words. RFC 2616, the 338 now-obsolete HTTP/1.1 specification, did refer to RFC 2047 339 ([RFC2616], Section 2.2). However, it wasn't clear to which header 340 field it applied. Consequently, the current revision of the HTTP/1.1 341 specification has deprecated use of the encoding forms defined in RFC 342 2047 (see Section 3.2.4 of [RFC7230]). 344 Thus, this specification does not include this feature. 346 4. Guidelines for Usage in HTTP Header Field Definitions 348 Specifications of HTTP header fields that use the extensions defined 349 in Section 3.2 ought to clearly state that. A simple way to achieve 350 this is to normatively reference this specification, and to include 351 the ext-value production into the ABNF for that header field. 353 For instance: 355 foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param 356 title-param = "title" LWSP "=" LWSP value 357 / "title*" LWSP "=" LWSP ext-value 358 ext-value = 360 Note: The Parameter Value Continuation feature defined in Section 361 3 of [RFC2231] makes it impossible to have multiple instances of 362 extended parameters with identical parmname components, as the 363 processing of continuations would become ambiguous. Thus, 364 specifications using this extension are advised to disallow this 365 case for compatibility with RFC 2231. 367 Note: This specification does not automatically assign a new 368 interpretration to parameter names ending in an asterisk. As 369 pointed out above, it's up to the specification for the non- 370 extended parameter to "opt in" to the syntax defined here. That 371 being said, some existing implementations are known to 372 automatically switch to the use of this notation when a parameter 373 name ends with an asterisk, thus using parameter names ending in 374 an asterisk for something else is likely to cause interoperability 375 problems. 377 4.1. When to Use the Extension 379 Section 4.2 of [RFC2277] requires that protocol elements containing 380 human-readable text are able to carry language information. Thus, 381 the ext-value production ought to be always used when the parameter 382 value is of textual nature and its language is known. 384 Furthermore, the extension ought to also be used whenever the 385 parameter value needs to carry characters not present in the US-ASCII 386 ([USASCII]) coded character set (note that it would be unacceptable 387 to define a new parameter that would be restricted to a subset of the 388 Unicode character set). 390 4.2. Error Handling 392 Header field specifications need to define whether multiple instances 393 of parameters with identical parmname components are allowed, and how 394 they should be processed. This specification suggests that a 395 parameter using the extended syntax takes precedence. This would 396 allow producers to use both formats without breaking recipients that 397 do not understand the extended syntax yet. 399 Example: 401 foo: bar; title="EURO exchange rates"; 402 title*=utf-8''%e2%82%ac%20exchange%20rates 404 In this case, the sender provides an ASCII version of the title for 405 legacy recipients, but also includes an internationalized version for 406 recipients understanding this specification -- the latter obviously 407 ought to prefer the new syntax over the old one. 409 Note: at the time of this writing, many implementations failed to 410 ignore the form they do not understand, or prioritize the ASCII 411 form although the extended syntax was present. 413 5. Security Considerations 415 The format described in this document makes it possible to transport 416 non-ASCII characters, and thus enables character "spoofing" 417 scenarios, in which a displayed value appears to be something other 418 than it is. 420 Furthermore, there are known attack scenarios relating to decoding 421 UTF-8. 423 See Section 10 of [RFC3629] for more information on both topics. 425 In addition, the extension specified in this document makes it 426 possible to transport multiple language variants for a single 427 parameter, and such use might allow spoofing attacks, where different 428 language versions of the same parameter are not equivalent. Whether 429 this attack is useful as an attack depends on the parameter 430 specified. 432 6. IANA Considerations 434 There are no IANA Considerations related to this specification. 436 7. Acknowledgements 438 Thanks to Martin Duerst and Frank Ellermann for help figuring out 439 ABNF details, to Graham Klyne and Alexey Melnikov for general review, 440 to Chris Newman for pointing out an RFC 2231 incompatibility, and to 441 Benjamin Carlyle, Roar Lauritzsen, Eric Lawrence, and James Manger 442 for implementer's feedback. 444 8. References 446 8.1. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 452 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 453 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 455 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 456 Procedures", BCP 19, RFC 2978, October 2000. 458 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 459 10646", STD 63, RFC 3629, November 2003. 461 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 462 "Uniform Resource Identifier (URI): Generic Syntax", 463 STD 66, RFC 3986, January 2005. 465 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 466 Syntax Specifications: ABNF", STD 68, RFC 5234, 467 January 2008. 469 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for 470 Identifying Languages", BCP 47, RFC 5646, 471 September 2009. 473 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 474 Transfer Protocol (HTTP/1.1): Message Syntax and 475 Routing", RFC 7230, June 2014. 477 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 478 Transfer Protocol (HTTP/1.1): Semantics and Content", 479 RFC 7231, June 2014. 481 [USASCII] American National Standards Institute, "Coded Character 482 Set -- 7-bit American Standard Code for Information 483 Interchange", ANSI X3.4, 1986. 485 8.2. Informative References 487 [Err1912] RFC Errata, "Errata ID 1912, RFC 2978", 488 . 490 [ISO-8859-1] International Organization for Standardization, 491 "Information technology -- 8-bit single-byte coded 492 graphic character sets -- Part 1: Latin alphabet No. 493 1", ISO/IEC 8859-1:1998, 1998. 495 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 496 Mail Extensions (MIME) Part One: Format of Internet 497 Message Bodies", RFC 2045, November 1996. 499 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 500 Extensions) Part Three: Message Header Extensions for 501 Non-ASCII Text", RFC 2047, November 1996. 503 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and 504 Encoded Word Extensions: Character Sets, Languages, and 505 Continuations", RFC 2231, November 1997. 507 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 508 Languages", BCP 18, RFC 2277, January 1998. 510 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 511 form-data", RFC 2388, August 1998. 513 [RFC5987] Reschke, J., "Character Set and Language Encoding for 514 Hypertext Transfer Protocol (HTTP) Header Field 515 Parameters", RFC 5987, August 2010. 517 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 519 [RFC6266] Reschke, J., "Use of the Content-Disposition Header 520 Field in the Hypertext Transfer Protocol (HTTP)", 521 RFC 6266, June 2011. 523 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 524 Internationalization in the IETF", BCP 166, RFC 6365, 525 September 2011. 527 URIs 529 [1] 531 [2] 533 Appendix A. Changes from RFC 5987 535 This section summarizes the changes compared to [RFC5987]: 537 o The document title was changed to "Indicating Character Encoding 538 and Language for HTTP Header Field Parameters". 540 o The requirement to support the "ISO-8859-1" encoding was removed. 542 Appendix B. Implementation Report 544 The encoding defined in this document currently is used for two 545 different HTTP header fields: 547 o "Content-Disposition", defined in [RFC6266], and 549 o "Link", defined in [RFC5988]. 551 As the encoding is a profile/clarification of the one defined in 552 [RFC2231] in 1997, many user agents already supported it for use in 553 "Content-Disposition" when [RFC5987] got published. 555 Since the publication of [RFC5987], three more popular desktop user 556 agents have added support for this encoding; see for details. 558 At this time, the current versions of all major desktop user agents 559 support it. 561 Note that the implementation in Internet Explorer 9 does not support 562 the ISO-8859-1 character encoding; this document revision 563 acknowledges that UTF-8 is sufficient for expressing all code points, 564 and removes the requirement to support ISO-8859-1. 566 The "Link" header field, on the other hand, was only recently 567 specified in [RFC5988]. At the time of this writing, no shipping 568 User Agent except Firefox supported the "title*" parameter (starting 569 with release 15). 571 Appendix C. Change Log (to be removed by RFC Editor before publication) 573 C.1. Since RFC5987 575 Only editorial changes for the purpose of starting the revision 576 process (obs5987). 578 C.2. Since draft-reschke-rfc5987bis-00 580 Resolved issues "iso-8859-1" and "title" (title simplified). Added 581 and resolved issue "historic5987". 583 C.3. Since draft-reschke-rfc5987bis-01 585 Added issues "httpbis", "parmsyntax", "terminology" and 586 "valuesyntax". Closed issue "impls". 588 C.4. Since draft-reschke-rfc5987bis-02 590 Resolved issue "terminology". 592 C.5. Since draft-reschke-rfc5987bis-03 594 In Section 3.2, pull historical notes into a separate subsection. 595 Resolved issues "valuesyntax" and "parmsyntax". 597 C.6. Since draft-reschke-rfc5987bis-04 599 Update status of Firefox support in HTTP Link Header field. 601 C.7. Since draft-reschke-rfc5987bis-05 603 Update status of Firefox support in HTTP Link Header field. 605 C.8. Since draft-reschke-rfc5987bis-06 607 Update status with respect to Safari 6. 609 Started work on update with respect to RFC 723x. 611 Appendix D. Open issues (to be removed by RFC Editor prior to 612 publication) 614 D.1. edit 616 Type: edit 618 julian.reschke@greenbytes.de (2011-04-15): Umbrella issue for 619 editorial fixes/enhancements. 621 D.2. httpbis 623 Type: edit 625 julian.reschke@greenbytes.de (2011-09-17): The document refers 626 normatively to RFC 2616. Should it continue to do so, or should we 627 wait for HTTPbis? This may affect edge case in the ABNF, such as the 628 definition of linear white space or the characters allowed in 629 "token". 631 Author's Address 633 Julian F. Reschke 634 greenbytes GmbH 635 Hafenweg 16 636 Muenster, NW 48155 637 Germany 639 EMail: julian.reschke@greenbytes.de 640 URI: http://greenbytes.de/tech/webdav/