draft-ietf-httpbis-rfc5987bis.xml

<?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="proposed" 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='RFC8053'>
    <front>
      <title>HTTP Authentication Extensions for Interactive Clients</title>
      <author initials='Y.' surname='Oiwa' fullname='Y. Oiwa'/>
      <author initials='H.' surname='Watanabe' fullname='H. Watanabe'/>
      <author initials='H.' surname='Takagi' fullname='H. Takagi'/>
      <author initials='K.' surname='Maeda' fullname='K. Maeda'/>
      <author initials='T.' surname='Hayashi' fullname='T. Hayashi'/>
      <author initials='Y.' surname='Ioku' fullname='Y. Ioku'/>
      <date year='2017' month='January'/>
    </front>
    <seriesInfo name='RFC' value='8053'/>
  </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 in four different
  HTTP header fields:
</t>
<ul>
  <li>
    "Authentication-Control", defined in <xref target="RFC8053"/>,
  </li>
  <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>
  Mention RFC8053 in Implementation Report.
</t>
</section>

<section title="Since draft-ietf-httpbis-rfc5987bis-05">
<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>