Permalink
Find file
Fetching contributors…
Cannot retrieve contributors at this time
executable file 942 lines (861 sloc) 36 KB
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext include-references-in-index="yes" ?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<!DOCTYPE rfc [
<!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
<!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
<!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
<!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
<!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
<!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
<!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
<!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
<!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
<!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
<!ENTITY pound "&#163;">
<!ENTITY uuml "&#252;">
<!ENTITY euro "&#8364;">
]>
<rfc xmlns:x="http://purl.org/net/xml2rfc/ext" obsoletes="5987" ipr="trust200902" docName="draft-ietf-httpbis-rfc5987bis-latest" category="std" x:maturity-level="internet" xml:lang="en">
<x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
<front>
<title abbrev="Charset/Language Encoding in HTTP">Indicating Character Encoding and Language for HTTP Header Field Parameters</title>
<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
<organization abbrev="greenbytes">greenbytes GmbH</organization>
<address>
<postal>
<street>Hafenweg 16</street>
<city>M&uuml;nster</city><region>NW</region><code>48155</code>
<country>Germany</country>
</postal>
<email>julian.reschke@greenbytes.de</email>
<uri>http://greenbytes.de/tech/webdav/</uri>
</address>
</author>
<date year="2017"/>
<area>Applications and Real-Time</area>
<workgroup>HTTP</workgroup>
<keyword>HTTP</keyword>
<keyword>header field parameter</keyword>
<keyword>internationalization</keyword>
<abstract>
<t>
By default, header field values in Hypertext Transfer Protocol (HTTP)
messages cannot easily carry characters outside the US-ASCII coded
character set. RFC 2231 defines an encoding mechanism for use in
parameters inside Multipurpose Internet Mail Extensions (MIME) header
field values. This document specifies an encoding suitable for use in
HTTP header fields that is compatible with a simplified profile of the
encoding defined in RFC 2231.
</t>
<t>
This document obsoletes RFC 5987.
</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor before publication)">
<t>
Discussion of this draft takes place on the HTTPBIS working group mailing list
(ietf-http-wg@w3.org), which is archived at <eref
target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
</t>
<t>
Working Group information can be found at <eref target="http://httpwg.github.io/"/>; source code and issues
list for this draft can be found at
<eref target="https://github.com/httpwg/http-extensions"/>.
</t>
<t>
The changes in this draft are summarized in <xref target="change.log"/>.
</t>
</note>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>
Use of characters outside the US-ASCII coded character set (<xref target="RFC0020"/>)
in HTTP header fields (<xref target="RFC7230"/>) is non-trivial:
</t>
<ul>
<li>The HTTP specification discourages use of non-US-ASCII characters in field
values, placing them into the "obs-text" ABNF production (<xref target="RFC7230" x:fmt="," x:rel="#header.fields"/>).</li>
<li>Furthermore, it stays silent about default character encoding schemes for
field values, so any use of non-US-ASCII characters would need to be specific
to the field definition, or would require some other kind of out-of-band information.</li>
<li>Finally, some APIs assume a default character encoding scheme in order to map from the octet sequences (obtained from the HTTP message) to character sequences:
for instance, the XMLHttpRequest API (<xref target="XMLHttpRequest"/>) uses the Interface Definition Language type "ByteString",
effectively resulting in the ISO-8859-1 character encoding scheme <xref target="ISO-8859-1"/>
being used.
</li>
</ul>
<t>
On the other hand, RFC 2231 defines an encoding mechanism for parameters
inside MIME header fields (<xref target="RFC2231"/>), which, as opposed to
HTTP messages, do need to be sent over non-binary transports.
This document specifies an encoding suitable for use in HTTP header fields
that is compatible with a simplified profile of the encoding defined in RFC 2231.
It can be applied to any HTTP header field that uses the common "parameter"
("name=value") syntax.
</t>
<t>
This document obsoletes <xref target="RFC5987"/> and
moves it to "historic" status; the changes are summarized
in <xref target="changes.from.rfc5987"/>.
</t>
<x:note>
<t>
<x:h>Note:</x:h> in the remainder of this document, RFC 2231 is only referenced
for the purpose of explaining the choice of features that were adopted; they
are therefore purely informative.
</t>
</x:note>
<x:note>
<t>
<x:h>Note:</x:h> this encoding does not apply to message payloads
transmitted over HTTP, such as when using the media type "multipart/form-data"
(<xref target="RFC7578"/>).
</t>
</x:note>
</section>
<section title="Notational Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in <xref target="RFC2119"/>.
</t>
<t>
This specification uses the ABNF (Augmented Backus-Naur Form) notation defined in
<xref target="RFC5234"/>. The following core rules are included by
reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
ALPHA (letters), DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and
LWSP (linear whitespace).
</t>
<t>
This specification uses terminology defined in <xref target="RFC6365"/>,
namely: "<x:dfn>character encoding scheme</x:dfn>" (below abbreviated to
"<x:dfn>character encoding</x:dfn>"), "<x:dfn>charset</x:dfn>"
and "<x:dfn>coded character set</x:dfn>".
</t>
<t>
Note that this differs from RFC 2231, which uses the term "character set"
for "character encoding scheme".
</t>
</section>
<section title="Comparison to RFC 2231 and Definition of the Encoding">
<t>
RFC 2231 defines several extensions to MIME. The sections below discuss
if and how they apply to HTTP header fields.
</t>
<t>
In short:
<list style="symbols">
<t>Parameter Continuations aren't needed (<xref target="parameter.continuations"/>),</t>
<t>Character Encoding and Language Information are useful, therefore a simple subset
is specified (<xref target="character.set.and.language.information"/>), and</t>
<t>Language Specifications in Encoded Words aren't needed (<xref target="language.specification.in.encoded.words"/>).</t>
</list>
</t>
<section title="Parameter Continuations" anchor="parameter.continuations">
<t>
<xref target="RFC2231" x:fmt="of" x:sec="3"/> defines a mechanism that
deals with the length limitations that apply to MIME headers. These
limitations do not apply to HTTP (<xref target="RFC7231" x:fmt="," x:rel="#mhtml.line.length"/>).
</t>
<t>
Thus, parameter continuations are not part of the encoding defined by this
specification.
</t>
</section>
<section title="Parameter Value Character Encoding and Language Information" anchor="character.set.and.language.information">
<t>
<xref target="RFC2231" x:fmt="of" x:sec="4"/> specifies how to embed
language information into parameter values, and also how to encode
non-ASCII characters, dealing with restrictions both in MIME and HTTP
header field parameters.
</t>
<t>
However, RFC 2231 does not specify a mandatory-to-implement character encoding,
making it hard for senders to decide which encoding to use.
Thus, recipients implementing this specification &MUST; support the
"UTF-8" character encoding <xref target="RFC3629"/>.
</t>
<t>
Furthermore, RFC 2231 allows the character encoding information to be left out.
The encoding defined by this specification does not allow that.
</t>
<section title="Definition" anchor="definition">
<x:anchor-alias value="ext-value"/>
<t>
The presence of extended parameter values usually is indicated by a parameter name
ending in an asterisk character. Note however that this is just a convention,
and that it needs to be explicitly specified in the definition of the header
field using this extension (see <xref target="usage.guidelines"/>).
</t>
<t>
The ABNF for extended parameter values is specified below:
</t>
<figure><artwork type="abnf">
ext-value = charset "'" [ language ] "'" value-chars
; like RFC 2231's &lt;extended-initial-value&gt;
; (see <xref target="RFC2231" x:fmt="," x:sec="7"/>)
charset = "UTF-8" / mime-charset
mime-charset = 1*mime-charsetc
mime-charsetc = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&amp;"
/ "+" / "-" / "^" / "_" / "`"
/ "{" / "}" / "~"
; as &lt;mime-charset&gt; in <xref target="RFC2978" x:fmt="of" x:sec="2.3"/>
; except that the single quote is not included
; &SHOULD; be registered in the IANA charset registry
language = &lt;Language-Tag, see <xref target="RFC5646" x:fmt="," x:sec="2.1"/>&gt;
value-chars = *( pct-encoded / attr-char )
pct-encoded = "%" HEXDIG HEXDIG
; see <xref target="RFC3986" x:fmt="," x:sec="2.1"/>
attr-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "&amp;" / "+" / "-" / "."
/ "^" / "_" / "`" / "|" / "~"
; token except ( "*" / "'" / "%" )
</artwork></figure>
<t>
The value part of an extended parameter (ext-value) is a token that consists
of three parts:
</t>
<ol>
<li>the &REQUIRED; character encoding name (charset),</li>
<li>the &OPTIONAL; language information (language), and</li>
<li>a character sequence representing the
actual value (value-chars), separated by single quote
characters.</li>
</ol>
<t>
Note that both character encoding names and
language tags are restricted to the US-ASCII coded character set, and are matched
case-insensitively (see <xref target="RFC2978" x:fmt="," x:sec="2.3"/> and
<xref target="RFC5646" x:fmt="," x:sec="2.1.1"/>).
</t>
<t>
Inside the value part, characters not contained in attr-char are
encoded into an octet sequence using the specified character encoding. That octet
sequence is then percent-encoded as specified in <xref target="RFC3986" x:fmt="of" x:sec="2.1"/>.
</t>
<t>
Producers &MUST; use the "UTF-8" (<xref target="RFC3629"/>) character encoding.
Extension character encodings (mime-charset) are reserved for future use.
</t>
<x:note>
<t>
<x:h>Note:</x:h> recipients should be prepared to handle encoding
errors, such as malformed or incomplete percent escape sequences, or
non-decodable octet sequences, in a robust manner. This specification
does not mandate any specific behavior, for instance, the following
strategies are all acceptable:
<list style="symbols">
<t>ignoring the parameter,</t>
<t>stripping a non-decodable octet sequence,</t>
<t>substituting a non-decodable octet sequence by a replacement
character, such as the Unicode character U+FFFD (Replacement Character).</t>
</list>
</t>
</x:note>
</section>
<section title="Historical Notes">
<t>
The
RFC 7230 token production (<xref target="RFC7230" x:fmt="," x:rel="#field.components"/>)
differs from the production used in RFC 2231 (imported from <xref target="RFC2045" x:fmt="of" x:sec="5.1"/>)
in that curly braces ("{" and "}") are excluded. Thus, these two
characters are excluded from the attr-char production as well.
</t>
<t>
The &lt;mime-charset&gt; ABNF defined here differs from
the one in <xref target="RFC2978" x:fmt="of" x:sec="2.3"/> in that it does
not allow the single quote character (see also RFC Errata ID 1912 <xref target="Err1912"/>). In practice, no character encoding names
using that character have been registered at the time of this writing.
</t>
<t>
For backwards compatibility with RFC 2231, the encoding defined by this
specification deviates from common parameter syntax in that the
quoted-string notation is not allowed. Implementations using generic parser
components might not be able to detect the use of quoted-string notation and
thus might accept that format, although invalid, as well.
</t>
<t>
<xref target="RFC5987"/> did require support for ISO-8859-1 (<xref target="ISO-8859-1"/>),
too; for compatibility with legacy code, recipients are encouraged to
support this encoding as well.
</t>
</section>
<section title="Examples" anchor="examples">
<figure>
<preamble>
Non-extended notation, using "token":
</preamble>
<artwork type="example">
foo: bar; title=Economy
</artwork></figure>
<figure>
<preamble>
Non-extended notation, using "quoted-string":
</preamble>
<artwork type="example">
foo: bar; title="US-$ rates"
</artwork></figure>
<figure>
<preamble>
Extended notation, using the Unicode character U+00A3 ("&pound;", POUND SIGN):
</preamble>
<artwork type="example">
foo: bar; title*=utf-8'en'<x:highlight>%C2%A3</x:highlight>%20rates
</artwork>
<postamble>
Note: the Unicode pound sign character U+00A3 was encoded into the octet sequence C2 A3 using the UTF-8 character encoding, then percent-encoded. Also, note
that the space character was encoded as %20, as it is not contained in
attr-char.
</postamble>
</figure>
<figure>
<preamble>
Extended notation, using the Unicode characters U+00A3 ("&pound;", POUND SIGN)
and U+20AC ("&euro;", EURO SIGN):
</preamble>
<artwork type="example">
foo: bar; title*=UTF-8''<x:highlight>%c2%a3</x:highlight>%20and%20<x:highlight>%e2%82%ac</x:highlight>%20rates
</artwork>
<postamble>
Note: the Unicode pound sign character U+00A3 was encoded into the octet sequence C2 A3 using the UTF-8 character encoding, then percent-encoded. Likewise,
the Unicode euro sign character U+20AC was encoded into the octet
sequence E2 82 AC, then percent-encoded. Also note that HEXDIG allows
both lowercase and uppercase characters, so recipients must understand
both, and that the language information is optional, while the character encoding is not.
</postamble>
</figure>
</section>
</section>
<section title="Language Specification in Encoded Words" anchor="language.specification.in.encoded.words">
<t>
<xref target="RFC2231" x:fmt="of" x:sec="5"/> extends the encoding
defined in <xref target="RFC2047"/> to also support language specification
in encoded words.
RFC 2616, the now-obsolete HTTP/1.1 specification, did refer to RFC 2047
(<xref target="RFC2616" x:fmt="," x:sec="2.2"/>). However, it wasn't clear
to which header field it applied. Consequently, the current revision of
the HTTP/1.1 specification has deprecated use of the encoding forms defined in
RFC 2047 (see <xref target="RFC7230" x:fmt="of" x:rel="#field.parsing"/>).
</t>
<t>
Thus, this specification does not include this feature.
</t>
</section>
</section>
<section title="Guidelines for Usage in HTTP Header Field Definitions" anchor="usage.guidelines">
<t>
Specifications of HTTP header fields that use the extensions defined
in <xref target="character.set.and.language.information"/> ought to clearly
state that. A simple way to achieve this is to normatively reference
this specification, and to include the <x:ref>ext-value</x:ref>
production into the ABNF for specific header field parameters.
</t>
<figure><preamble>For instance:</preamble>
<artwork type="example">
foo = token ";" LWSP title-param
title-param = "title" LWSP "=" LWSP value
/ "title*" LWSP "=" LWSP ext-value
ext-value = &lt;see draft-ietf-httpbis-rfc5987bis, <xref target="character.set.and.language.information"/>&gt;
</artwork>
<postamble><cref anchor="pub">Upon publication as RFC, the string "draft-ietf-httpbis-rfc5987bis" needs to be replaced with the RFC name, and this comment needs to be removed.</cref></postamble>
</figure>
<x:note>
<t>
<x:h>Note:</x:h> The Parameter Value Continuation feature defined in
<xref target="RFC2231" x:fmt="of" x:sec="3"/> makes it impossible to
have multiple instances of extended parameters with identical names,
as the processing of continuations would become ambiguous. Thus, specifications
using this extension are advised to disallow this case for compatibility
with RFC 2231.
</t>
</x:note>
<x:note>
<t>
<x:h>Note:</x:h> This specification does not automatically assign a new
interpretation to parameter names ending in an asterisk. As pointed out
above, it's up to the specification for the non-extended parameter to "opt
in" to the syntax defined here. That being said, some existing
implementations are known to automatically switch to the use of this
notation when a parameter name ends with an asterisk, thus using parameter
names ending in an asterisk for something else is likely to cause
interoperability problems.
</t>
</x:note>
<section title="When to Use the Extension" anchor="when.to.use.the.extension">
<t>
<xref target="RFC2277" x:fmt="of" x:sec="4.2"/> requires that protocol
elements containing human-readable text are able to carry language information. Thus, the <x:ref>ext-value</x:ref>
production ought to be always used when the parameter value is of textual
nature and its language is known.
</t>
<t>
Furthermore, the extension ought to also be used whenever the parameter value
needs to carry characters not present in the US-ASCII (<xref target="RFC0020"/>)
coded character set (note that it would be unacceptable to define a new parameter that
would be restricted to a subset of the Unicode character set).
</t>
</section>
<section title="Error Handling">
<t>
Header field specifications need to define whether multiple
instances of parameters with identical names are allowed, and
how they should be processed. This specification suggests that a parameter using the
extended syntax takes precedence. This would allow producers to use both
formats without breaking recipients that do not understand the extended syntax
yet.
</t>
<figure><preamble>Example:</preamble>
<artwork type="example">
foo: bar; title="EURO exchange rates";
title*=utf-8''<x:highlight>%e2%82%ac</x:highlight>%20exchange%20rates
</artwork>
<postamble>In this case, the sender provides an ASCII version of the title
for legacy recipients, but also includes an internationalized version for
recipients understanding this specification -- the latter obviously
ought to prefer the new syntax over the old one.</postamble>
</figure>
</section>
</section>
<section title="Security Considerations" anchor="security.considerations">
<t>
The format described in this document makes it possible to transport
non-ASCII characters, and thus enables character "spoofing" scenarios,
in which a displayed value appears to be something other than it is.
</t>
<t>
Furthermore, there are known attack scenarios relating to decoding UTF-8.
</t>
<t>
See <xref target="RFC3629" x:fmt="of" x:sec="10"/> for more information on
both topics.
</t>
<t>
In addition, the extension specified in this document makes it possible
to transport multiple language variants for a single parameter, and such use might allow spoofing attacks, where
different language versions of the same parameter are not equivalent.
Whether this attack is useful as an attack depends on the parameter
specified.
</t>
</section>
<section title="IANA Considerations" anchor="iana.considerations">
<t>
There are no IANA Considerations related to this specification.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC0020'>
<front>
<title>ASCII format for network interchange</title>
<author initials='V.' surname='Cerf' fullname='Vint Cerf'/>
<date year='1969' month='October' />
</front>
<seriesInfo name='STD' value='80' />
<seriesInfo name='RFC' value='20' />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner"/>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC2978">
<front>
<title>IANA Charset Registration Procedures</title>
<author initials="N." surname="Freed" fullname="N. Freed"/>
<author initials="J." surname="Postel" fullname="J. Postel"/>
<date year="2000" month="October"/>
</front>
<seriesInfo name="BCP" value="19"/>
<seriesInfo name="RFC" value="2978"/>
</reference>
<reference anchor="RFC3629">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials="F." surname="Yergeau" fullname="F. Yergeau"/>
<date month="November" year="2003"/>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
</reference>
<reference anchor="RFC3986">
<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"/>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding"/>
<author initials="L." surname="Masinter" fullname="Larry Masinter"/>
<date month="January" year="2005"/>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
</reference>
<reference anchor="RFC5646">
<front>
<title>Tags for Identifying Languages</title>
<author initials="A." surname="Phillips" fullname="Addison Phillips" role="editor"/>
<author initials="M." surname="Davis" fullname="Mark Davis" role="editor"/>
<date month="September" year="2009"/>
</front>
<seriesInfo name="BCP" value="47"/>
<seriesInfo name="RFC" value="5646"/>
</reference>
<reference anchor="RFC5234">
<front>
<title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"/>
<author initials="P." surname="Overell" fullname="Paul Overell"/>
<date month="January" year="2008"/>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
</reference>
<reference anchor="RFC7230">
<front>
<title>
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"/>
<author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"/>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7230"/>
<x:source href="refs/rfc7230.xml" basename="rfc7230"/>
</reference>
<reference anchor="RFC7231">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"/>
<author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"/>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7231"/>
<x:source href="refs/rfc7231.xml" basename="rfc7231"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="Err1912" target="http://www.rfc-editor.org">
<front>
<title x:quotes="false">Errata ID 1912, RFC 2978</title>
<author>
<organization>RFC Errata</organization>
</author>
<date year="2009" month="October"/>
</front>
</reference>
<reference anchor="ISO-8859-1">
<front>
<title>Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date year="1998"/>
</front>
<seriesInfo name="ISO/IEC" value="8859-1:1998"/>
</reference>
<reference anchor="RFC2045">
<front>
<title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
<author initials="N." surname="Freed" fullname="Ned Freed"/>
<author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"/>
<date month="November" year="1996"/>
</front>
<seriesInfo name="RFC" value="2045"/>
</reference>
<reference anchor="RFC2047">
<front>
<title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
<author initials="K." surname="Moore" fullname="Keith Moore"/>
<date month="November" year="1996"/>
</front>
<seriesInfo name="RFC" value="2047"/>
</reference>
<reference anchor="RFC2231">
<front>
<title abbrev="MIME Value and Encoded Word Extensions">MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</title>
<author initials="N." surname="Freed" fullname="Ned Freed"/>
<author initials="K." surname="Moore" fullname="Keith Moore"/>
<date year="1997" month="November"/>
</front>
<seriesInfo name="RFC" value="2231"/>
</reference>
<reference anchor="RFC2277">
<front>
<title abbrev="Charset Policy">IETF Policy on Character Sets and Languages</title>
<author initials="H.T." surname="Alvestrand" fullname="Harald Tveit Alvestrand"/>
<date year="1998" month="January"/>
</front>
<seriesInfo name="BCP" value="18"/>
<seriesInfo name="RFC" value="2277"/>
</reference>
<reference anchor="RFC2616">
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="R. Fielding"/>
<author initials="J." surname="Gettys" fullname="J. Gettys"/>
<author initials="J." surname="Mogul" fullname="J. Mogul"/>
<author initials="H." surname="Frystyk" fullname="H. Frystyk"/>
<author initials="L." surname="Masinter" fullname="L. Masinter"/>
<author initials="P." surname="Leach" fullname="P. Leach"/>
<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"/>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
</reference>
<reference anchor="RFC5987">
<front>
<title>Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</title>
<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke"/>
<date month="August" year="2010"/>
</front>
<seriesInfo name="RFC" value="5987"/>
</reference>
<reference anchor="RFC5988">
<front>
<title>Web Linking</title>
<author fullname="Mark Nottingham" initials="M." surname="Nottingham"/>
<date month="October" year="2010"/>
</front>
<seriesInfo name="RFC" value="5988"/>
</reference>
<reference anchor="RFC6266">
<front>
<title abbrev="Content-Disposition in HTTP">Use of the Content-Disposition Header Field
in the Hypertext Transfer Protocol (HTTP)</title>
<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke"/>
<date month="June" year="2011"/>
</front>
<seriesInfo name="RFC" value="6266"/>
</reference>
<reference anchor="RFC6365">
<front>
<title>Terminology Used in Internationalization in the IETF</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"/>
<author initials="J." surname="Klensin" fullname="J. Klensin"/>
<date year="2011" month="September"/>
</front>
<seriesInfo name="BCP" value="166"/>
<seriesInfo name="RFC" value="6365"/>
</reference>
<reference anchor="RFC7578">
<front>
<title>Returning Values from Forms: multipart/form-data</title>
<author initials="L." surname="Masinter" fullname="Larry Masinter"/>
<date year="2015" month="July"/>
</front>
<seriesInfo name="RFC" value="7578"/>
</reference>
<reference anchor="RFC7616">
<front>
<title>HTTP Digest Access Authentication</title>
<author initials="R." surname="Shekh-Yusef" fullname="R. Shekh-Yusef" role="editor"/>
<author initials="D." surname="Ahrens" fullname="D. Ahrens"/>
<author initials="S." surname="Bremer" fullname="S. Bremer"/>
<date year="2015" month="September"/>
</front>
<seriesInfo name="RFC" value="7616"/>
</reference>
<reference anchor='XMLHttpRequest'
target='https://xhr.spec.whatwg.org/'>
<front>
<title>XMLHttpRequest</title>
<author><organization>WhatWG</organization></author>
<date/>
</front>
</reference>
</references>
<section title="Changes from RFC 5987" anchor="changes.from.rfc5987">
<t>
This section summarizes the changes compared to <xref target="RFC5987"/>:
</t>
<ul>
<li>
The document title was changed to "Indicating Character Encoding and Language for HTTP Header Field Parameters".
</li>
<li>
The introduction was rewritten to better explain the issues around non-ASCII characters in field values.
</li>
<li>
The requirement to support the "ISO-8859-1" encoding was removed.
</li>
<li>
The document does not attempt to re-define a generic "parameter" ABNF anymore (it turned out that
there really isn't a generic definition of parameters in HTTP; for instance,
there are subtle differences with respect to whitespace handling).
</li>
<li>
A note about defects in error handling in current implementations was removed, as it wasn't accurate anymore.
</li>
</ul>
</section>
<section title="Implementation Report" anchor="implementation.report">
<t>
The encoding defined in this document currently is used for three different
HTTP header fields:
</t>
<ul>
<li>
"Authorization" (as used in HTTP Digest Authentication, defined in <xref target="RFC7616"/>),
</li>
<li>
"Content-Disposition", defined in <xref target="RFC6266"/>, and
</li>
<li>
"Link", defined in <xref target="RFC5988"/>.
</li>
</ul>
<t>
As the encoding is a profile/clarification of the one defined in
<xref target="RFC2231"/> in 1997, many user agents already supported it for
use in "Content-Disposition" when <xref target="RFC5987"/> got published.
</t>
<t>
Since the publication of <xref target="RFC5987"/>, three more popular desktop
user agents have added support for this encoding; see
<eref target="http://purl.org/NET/http/content-disposition-tests#encoding-2231-char"/>
for details. At this time, the current versions of all major desktop
user agents support it.
</t>
<t>
Note that the implementation in Internet Explorer 9 does not support the
ISO-8859-1 character encoding; this document revision acknowledges that UTF-8 is
sufficient for expressing all code points, and removes the requirement
to support ISO-8859-1.
</t>
<t>
The "Link" header field, on the other hand, was more recently specified
in <xref target="RFC5988"/>. At the time of this writing, no User Agent
except Firefox supported the "title*" parameter (starting with release 15).
</t>
<t>
<xref target="RFC7616" x:fmt="of" x:sec="3.4"/> defines the "username*"
parameter for use in HTTP Digest Authentication. At the time of writing, no
User Agent implemented this extension.
</t>
</section>
<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
<section title="Since RFC5987">
<t>
Only editorial changes for the purpose of starting the revision process
(obs5987).
</t>
</section>
<section title="Since draft-reschke-rfc5987bis-00">
<t>
Resolved issues "iso-8859-1" and "title" (title simplified).
Added and resolved issue "historic5987".
</t>
</section>
<section title="Since draft-reschke-rfc5987bis-01">
<t>
Added issues "httpbis", "parmsyntax",
"terminology" and "valuesyntax".
Closed issue "impls".
</t>
</section>
<section title="Since draft-reschke-rfc5987bis-02">
<t>
Resolved issue "terminology".
</t>
</section>
<section title="Since draft-reschke-rfc5987bis-03">
<t>
In <xref target="character.set.and.language.information"/>, pull historical notes into a separate subsection.
Resolved issues "valuesyntax" and "parmsyntax".
</t>
</section>
<section title="Since draft-reschke-rfc5987bis-04">
<t>
Update status of Firefox support in HTTP Link Header field.
</t>
</section>
<section title="Since draft-reschke-rfc5987bis-05">
<t>
Update status of Firefox support in HTTP Link Header field.
</t>
</section>
<section title="Since draft-reschke-rfc5987bis-06">
<t>
Update status with respect to Safari 6.
</t>
<t>
Started work on update with respect to RFC 723x.
</t>
</section>
<section title="Since draft-ietf-httpbis-rfc5987bis-00">
<t>
Editorial changes; introducing non-ASCII characters into author's
address, acknowledgements, and examples.
</t>
</section>
<section title="Since draft-ietf-httpbis-rfc5987bis-01">
<t>
Removed mention of RFC 2616 from Abstract and Introduction.
</t>
<t>
Reference RFC 20 for US-ASCII.
</t>
<t>
Do not attempt to define a generic parameter ABNF; just concentrate on the
parameter value syntax.
</t>
</section>
<section title="Since draft-ietf-httpbis-rfc5987bis-02">
<t>
RFC 2388 -> RFC 7578.
</t>
<t>
Expand on the motivation (see <eref target="https://github.com/httpwg/http-extensions/issues/213"/>).
</t>
<t>
Mention RFC 7616 in implementation report.
</t>
</section>
<section title="Since draft-ietf-httpbis-rfc5987bis-03">
<t>
Fixed one editorial issue. Updated XHR reference.
</t>
<t>
Fixed <eref target="https://github.com/httpwg/http-extensions/issues/266"/>: use of now undefined term "parmname".
</t>
<t>
Include WG into Acknowledgements for this revision.
</t>
<t>
Mention RFC 5987 in the abstract (<eref target="https://github.com/httpwg/http-extensions/issues/271"/>).
</t>
</section>
<section title="Since draft-ietf-httpbis-rfc5987bis-04">
<t>
None yet.
</t>
</section>
</section>
<section title="Acknowledgements" numbered="false">
<t>
Thanks to Martin D&uuml;rst and Frank Ellermann for help figuring out ABNF details,
to Graham Klyne and Alexey Melnikov for general review, to
Chris Newman for pointing out an RFC 2231 incompatibility, and to
Benjamin Carlyle, Roar Lauritzsen, Eric Lawrence, and James Manger for implementer's feedback.
</t>
<t>
Furthermore thanks to the members of the IETF HTTP Working Group for
the feedback specific to this update of RFC 5987.
</t>
</section>
</back>
</rfc>