draft-reschke-rfc5987bis-07.txt   draft-reschke-rfc5987bis-latest.txt 
Network Working Group J. Reschke Network Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Obsoletes: 5987 (if approved) July 2, 2014 Obsoletes: 5987 (if approved) July 6, 2024
Intended status: Standards Track Intended status: Standards Track
Expires: January 3, 2015 Expires: January 7, 2025
Indicating Character Encoding and Language for HTTP Header Field Indicating Character Encoding and Language for HTTP Header Field
Parameters Parameters
draft-reschke-rfc5987bis-07 draft-reschke-rfc5987bis-latest
Abstract Abstract
By default, message header field parameters in Hypertext Transfer By default, message header field parameters in Hypertext Transfer
Protocol (HTTP) messages cannot carry characters outside the ISO- Protocol (HTTP) messages cannot carry characters outside the ISO-
8859-1 character set. RFC 2231 defines an encoding mechanism for use 8859-1 character set. RFC 2231 defines an encoding mechanism for use
in Multipurpose Internet Mail Extensions (MIME) headers. This in Multipurpose Internet Mail Extensions (MIME) headers. This
document specifies an encoding suitable for use in HTTP header fields document specifies an encoding suitable for use in HTTP header fields
that is compatible with a profile of the encoding defined in RFC that is compatible with a profile of the encoding defined in RFC
2231. 2231.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
Distribution of this document is unlimited. Although this is not a Distribution of this document is unlimited. Although this is not a
work item of the HTTPbis Working Group, comments should be sent to work item of the HTTPbis Working Group, comments should be sent to
the Hypertext Transfer Protocol (HTTP) mailing list at the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-
ietf-http-wg@w3.org [1], which may be joined by sending a message wg@w3.org [1], which may be joined by sending a message with subject
with subject "subscribe" to ietf-http-wg-request@w3.org [2]. "subscribe" to ietf-http-wg-request@w3.org [2].
Discussions of the HTTPbis Working Group are archived at Discussions of the HTTPbis Working Group are archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
XML versions, latest edits, diffs, and the issues list for this XML versions, latest edits, diffs, and the issues list for this
document are available from document are available from <http://greenbytes.de/tech/webdav/#draft-
<http://greenbytes.de/tech/webdav/#draft-reschke-rfc5987bis>. A reschke-rfc5987bis>. A collection of test cases is available at
collection of test cases is available at
<http://greenbytes.de/tech/tc2231/>. <http://greenbytes.de/tech/tc2231/>.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2015. This Internet-Draft will expire on January 7, 2025.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Comparison to RFC 2231 and Definition of the Encoding . . . . 4 3. Comparison to RFC 2231 and Definition of the Encoding . . . . 4
3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 5 3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 4
3.2. Parameter Value Character Encoding and Language 3.2. Parameter Value Character Encoding and Language
Information . . . . . . . . . . . . . . . . . . . . . . . 5 Information . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Historical Notes . . . . . . . . . . . . . . . . . . . 7 3.2.2. Historical Notes . . . . . . . . . . . . . . . . . . 7
3.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Language Specification in Encoded Words . . . . . . . . . 8 3.3. Language Specification in Encoded Words . . . . . . . . . 8
4. Guidelines for Usage in HTTP Header Field Definitions . . . . 9 4. Guidelines for Usage in HTTP Header Field Definitions . . . . 9
4.1. When to Use the Extension . . . . . . . . . . . . . . . . 9 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 9
4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . . 12 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Implementation Report . . . . . . . . . . . . . . . . 13 Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . 14
Appendix B. Implementation Report . . . . . . . . . . . . . . . 14
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 13 publication) . . . . . . . . . . . . . . . . . . . . 14
C.1. Since RFC5987 . . . . . . . . . . . . . . . . . . . . . . 13
C.2. Since draft-reschke-rfc5987bis-00 . . . . . . . . . . . . 13 C.1. Since RFC5987 . . . . . . . . . . . . . . . . . . . . . . 14
C.3. Since draft-reschke-rfc5987bis-01 . . . . . . . . . . . . 14 C.2. Since draft-reschke-rfc5987bis-00 . . . . . . . . . . . . 15
C.4. Since draft-reschke-rfc5987bis-02 . . . . . . . . . . . . 14 C.3. Since draft-reschke-rfc5987bis-01 . . . . . . . . . . . . 15
C.5. Since draft-reschke-rfc5987bis-03 . . . . . . . . . . . . 14 C.4. Since draft-reschke-rfc5987bis-02 . . . . . . . . . . . . 15
C.6. Since draft-reschke-rfc5987bis-04 . . . . . . . . . . . . 14 C.5. Since draft-reschke-rfc5987bis-03 . . . . . . . . . . . . 15
C.7. Since draft-reschke-rfc5987bis-05 . . . . . . . . . . . . 14 C.6. Since draft-reschke-rfc5987bis-04 . . . . . . . . . . . . 15
C.8. Since draft-reschke-rfc5987bis-06 . . . . . . . . . . . . 14 C.7. Since draft-reschke-rfc5987bis-05 . . . . . . . . . . . . 15
C.8. Since draft-reschke-rfc5987bis-06 . . . . . . . . . . . . 15
Appendix D. Open issues (to be removed by RFC Editor prior to Appendix D. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 14 publication) . . . . . . . . . . . . . . . . . . . . 15
D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 15
D.2. httpbis . . . . . . . . . . . . . . . . . . . . . . . . . 14 D.2. httpbis . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
By default, message header field parameters in HTTP ([RFC2616]) By default, message header field parameters in HTTP ([RFC2616])
messages cannot carry characters outside the ISO-8859-1 coded messages cannot carry characters outside the ISO-8859-1 coded
character set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an character set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an
encoding mechanism for use in MIME headers. This document specifies encoding mechanism for use in MIME headers. This document specifies
an encoding suitable for use in HTTP header fields that is compatible an encoding suitable for use in HTTP header fields that is compatible
with a profile of the encoding defined in RFC 2231. with a profile of the encoding defined in RFC 2231.
skipping to change at page 7, line 38 skipping to change at page 7, line 38
Character). Character).
3.2.2. Historical Notes 3.2.2. Historical Notes
The RFC 7230 token production ([RFC7230], Section 3.2.6) differs from The RFC 7230 token production ([RFC7230], Section 3.2.6) differs from
the production used in RFC 2231 (imported from Section 5.1 of the production used in RFC 2231 (imported from Section 5.1 of
[RFC2045]) in that curly braces ("{" and "}") are excluded. Thus, [RFC2045]) in that curly braces ("{" and "}") are excluded. Thus,
these two characters are excluded from the attr-char production as these two characters are excluded from the attr-char production as
well. well.
The <mime-charset> ABNF defined here differs from the one in Section The <mime-charset> ABNF defined here differs from the one in
2.3 of [RFC2978] in that it does not allow the single quote character Section 2.3 of [RFC2978] in that it does not allow the single quote
(see also RFC Errata ID 1912 [Err1912]). In practice, no character character (see also RFC Errata ID 1912 [Err1912]). In practice, no
encoding names using that character have been registered at the time character encoding names using that character have been registered at
of this writing. the time of this writing.
For backwards compatibility with RFC 2231, the encoding defined by For backwards compatibility with RFC 2231, the encoding defined by
this specification deviates from common parameter syntax in that the this specification deviates from common parameter syntax in that the
quoted-string notation is not allowed. Implementations using generic quoted-string notation is not allowed. Implementations using generic
parser components might not be able to detect the use of quoted- parser components might not be able to detect the use of quoted-
string notation and thus might accept that format, although invalid, string notation and thus might accept that format, although invalid,
as well. as well.
[RFC5987] did require support for ISO-8859-1, too; for compatibility [RFC5987] did require support for ISO-8859-1, too; for compatibility
with legacy code, recipients are encouraged to support this encoding with legacy code, recipients are encouraged to support this encoding
skipping to change at page 9, line 19 skipping to change at page 9, line 19
this is to normatively reference this specification, and to include this is to normatively reference this specification, and to include
the ext-value production into the ABNF for that header field. the ext-value production into the ABNF for that header field.
For instance: For instance:
foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param
title-param = "title" LWSP "=" LWSP value title-param = "title" LWSP "=" LWSP value
/ "title*" LWSP "=" LWSP ext-value / "title*" LWSP "=" LWSP ext-value
ext-value = <see RFC 5987, Section 3.2> ext-value = <see RFC 5987, Section 3.2>
Note: The Parameter Value Continuation feature defined in Section Note: The Parameter Value Continuation feature defined in
3 of [RFC2231] makes it impossible to have multiple instances of Section 3 of [RFC2231] makes it impossible to have multiple
extended parameters with identical parmname components, as the instances of extended parameters with identical parmname
processing of continuations would become ambiguous. Thus, components, as the processing of continuations would become
specifications using this extension are advised to disallow this ambiguous. Thus, specifications using this extension are advised
case for compatibility with RFC 2231. to disallow this case for compatibility with RFC 2231.
Note: This specification does not automatically assign a new Note: This specification does not automatically assign a new
interpretration to parameter names ending in an asterisk. As interpretration to parameter names ending in an asterisk. As
pointed out above, it's up to the specification for the non- pointed out above, it's up to the specification for the non-
extended parameter to "opt in" to the syntax defined here. That extended parameter to "opt in" to the syntax defined here. That
being said, some existing implementations are known to being said, some existing implementations are known to
automatically switch to the use of this notation when a parameter automatically switch to the use of this notation when a parameter
name ends with an asterisk, thus using parameter names ending in name ends with an asterisk, thus using parameter names ending in
an asterisk for something else is likely to cause interoperability an asterisk for something else is likely to cause interoperability
problems. problems.
skipping to change at page 11, line 10 skipping to change at page 11, line 17
Thanks to Martin Duerst and Frank Ellermann for help figuring out Thanks to Martin Duerst and Frank Ellermann for help figuring out
ABNF details, to Graham Klyne and Alexey Melnikov for general review, ABNF details, to Graham Klyne and Alexey Melnikov for general review,
to Chris Newman for pointing out an RFC 2231 incompatibility, and to to Chris Newman for pointing out an RFC 2231 incompatibility, and to
Benjamin Carlyle, Roar Lauritzsen, Eric Lawrence, and James Manger Benjamin Carlyle, Roar Lauritzsen, Eric Lawrence, and James Manger
for implementer's feedback. for implementer's feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978,
October 2000, <https://www.rfc-editor.org/info/rfc2978>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
"Uniform Resource Identifier (URI): Generic Syntax", Resource Identifier (URI): Generic Syntax", STD 66,
STD 66, RFC 3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Syntax Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
January 2008. DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Identifying Languages", BCP 47, RFC 5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Transfer Protocol (HTTP/1.1): Message Syntax and Protocol (HTTP/1.1): Message Syntax and Routing",
Routing", RFC 7230, June 2014. RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Transfer Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
RFC 7231, June 2014. DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
8.2. Informative References 8.2. Informative References
[Err1912] RFC Errata, "Errata ID 1912, RFC 2978", [Err1912] RFC Errata, "Errata ID 1912, RFC 2978",
<http://www.rfc-editor.org>. <http://www.rfc-editor.org>.
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1]
"Information technology -- 8-bit single-byte coded International Organization for Standardization,
graphic character sets -- Part 1: Latin alphabet No. "Information technology -- 8-bit single-byte coded graphic
1", ISO/IEC 8859-1:1998, 1998. character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Mail Extensions (MIME) Part One: Format of Internet Extensions (MIME) Part One: Format of Internet Message
Message Bodies", RFC 2045, November 1996. Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Extensions) Part Three: Message Header Extensions for Part Three: Message Header Extensions for Non-ASCII Text",
Non-ASCII Text", RFC 2047, November 1996. RFC 2047, DOI 10.17487/RFC2047, November 1996,
<https://www.rfc-editor.org/info/rfc2047>.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Encoded Word Extensions: Character Sets, Languages, and Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997. Continuations", RFC 2231, DOI 10.17487/RFC2231, November
1997, <https://www.rfc-editor.org/info/rfc2231>.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
January 1998, <https://www.rfc-editor.org/info/rfc2277>.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998. form-data", RFC 2388, DOI 10.17487/RFC2388, August 1998,
<https://www.rfc-editor.org/info/rfc2388>.
[RFC5987] Reschke, J., "Character Set and Language Encoding for [RFC5987] Reschke, J., "Character Set and Language Encoding for
Hypertext Transfer Protocol (HTTP) Header Field Hypertext Transfer Protocol (HTTP) Header Field
Parameters", RFC 5987, August 2010. Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010,
<https://www.rfc-editor.org/info/rfc5987>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>.
[RFC6266] Reschke, J., "Use of the Content-Disposition Header [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
Field in the Hypertext Transfer Protocol (HTTP)", in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
RFC 6266, June 2011. DOI 10.17487/RFC6266, June 2011,
<https://www.rfc-editor.org/info/rfc6266>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
September 2011. DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>.
URIs 8.3. URIs
[1] <mailto:ietf-http-wg@w3.org> [1] mailto:ietf-http-wg@w3.org
[2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe> [2] mailto:ietf-http-wg-request@w3.org?subject=subscribe
Appendix A. Changes from RFC 5987 Appendix A. Changes from RFC 5987
This section summarizes the changes compared to [RFC5987]: This section summarizes the changes compared to [RFC5987]:
o The document title was changed to "Indicating Character Encoding o The document title was changed to "Indicating Character Encoding
and Language for HTTP Header Field Parameters". and Language for HTTP Header Field Parameters".
o The requirement to support the "ISO-8859-1" encoding was removed. o The requirement to support the "ISO-8859-1" encoding was removed.
skipping to change at page 13, line 24 skipping to change at page 14, line 28
o "Content-Disposition", defined in [RFC6266], and o "Content-Disposition", defined in [RFC6266], and
o "Link", defined in [RFC5988]. o "Link", defined in [RFC5988].
As the encoding is a profile/clarification of the one defined in As the encoding is a profile/clarification of the one defined in
[RFC2231] in 1997, many user agents already supported it for use in [RFC2231] in 1997, many user agents already supported it for use in
"Content-Disposition" when [RFC5987] got published. "Content-Disposition" when [RFC5987] got published.
Since the publication of [RFC5987], three more popular desktop user Since the publication of [RFC5987], three more popular desktop user
agents have added support for this encoding; see <http://purl.org/ agents have added support for this encoding; see
NET/http/content-disposition-tests#encoding-2231-char> for details. <http://purl.org/NET/http/content-disposition-tests#encoding-
At this time, the current versions of all major desktop user agents 2231-char> for details. At this time, the current versions of all
support it. major desktop user agents support it.
Note that the implementation in Internet Explorer 9 does not support Note that the implementation in Internet Explorer 9 does not support
the ISO-8859-1 character encoding; this document revision the ISO-8859-1 character encoding; this document revision
acknowledges that UTF-8 is sufficient for expressing all code points, acknowledges that UTF-8 is sufficient for expressing all code points,
and removes the requirement to support ISO-8859-1. and removes the requirement to support ISO-8859-1.
The "Link" header field, on the other hand, was only recently The "Link" header field, on the other hand, was only recently
specified in [RFC5988]. At the time of this writing, no shipping specified in [RFC5988]. At the time of this writing, no shipping
User Agent except Firefox supported the "title*" parameter (starting User Agent except Firefox supported the "title*" parameter (starting
with release 15). with release 15).
 End of changes. 40 change blocks. 
119 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/