draft-ietf-httpbis-rfc5987bis-03.txt   draft-ietf-httpbis-rfc5987bis-04.txt 
HTTP Working Group J. Reschke HTTP Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Obsoletes: 5987 (if approved) October 11, 2016 Obsoletes: 5987 (if approved) January 9, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: April 14, 2017 Expires: July 13, 2017
Indicating Character Encoding and Language for HTTP Header Field Indicating Character Encoding and Language for HTTP Header Field
Parameters Parameters
draft-ietf-httpbis-rfc5987bis-03 draft-ietf-httpbis-rfc5987bis-04
Abstract Abstract
By default, header field values in Hypertext Transfer Protocol (HTTP) By default, header field values in Hypertext Transfer Protocol (HTTP)
messages cannot easily carry characters outside the US-ASCII coded messages cannot easily carry characters outside the US-ASCII coded
character set. RFC 2231 defines an encoding mechanism for use in character set. RFC 2231 defines an encoding mechanism for use in
parameters inside Multipurpose Internet Mail Extensions (MIME) header parameters inside Multipurpose Internet Mail Extensions (MIME) header
field values. This document specifies an encoding suitable for use field values. This document specifies an encoding suitable for use
in HTTP header fields that is compatible with a simplified profile of in HTTP header fields that is compatible with a simplified profile of
the encoding defined in RFC 2231. the encoding defined in RFC 2231.
This document obsoletes RFC 5987.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <http://httpwg.github.io/>; Working Group information can be found at <http://httpwg.github.io/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-extensions>. <https://github.com/httpwg/http-extensions>.
skipping to change at page 2, line 4 skipping to change at page 2, line 5
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 http://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 April 14, 2017.
This Internet-Draft will expire on July 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 (http://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
skipping to change at page 3, line 30 skipping to change at page 3, line 30
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . . 13 Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . . 13
Appendix B. Implementation Report . . . . . . . . . . . . . . . . 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) . . . . . . . . . . . . . . . . . . . . 14 publication) . . . . . . . . . . . . . . . . . . . . 14
C.1. Since RFC5987 . . . . . . . . . . . . . . . . . . . . . . 14 C.1. Since RFC5987 . . . . . . . . . . . . . . . . . . . . . . 14
C.2. Since draft-reschke-rfc5987bis-00 . . . . . . . . . . . . 15 C.2. Since draft-reschke-rfc5987bis-00 . . . . . . . . . . . . 14
C.3. Since draft-reschke-rfc5987bis-01 . . . . . . . . . . . . 15 C.3. Since draft-reschke-rfc5987bis-01 . . . . . . . . . . . . 15
C.4. Since draft-reschke-rfc5987bis-02 . . . . . . . . . . . . 15 C.4. Since draft-reschke-rfc5987bis-02 . . . . . . . . . . . . 15
C.5. Since draft-reschke-rfc5987bis-03 . . . . . . . . . . . . 15 C.5. Since draft-reschke-rfc5987bis-03 . . . . . . . . . . . . 15
C.6. Since draft-reschke-rfc5987bis-04 . . . . . . . . . . . . 15 C.6. Since draft-reschke-rfc5987bis-04 . . . . . . . . . . . . 15
C.7. Since draft-reschke-rfc5987bis-05 . . . . . . . . . . . . 15 C.7. Since draft-reschke-rfc5987bis-05 . . . . . . . . . . . . 15
C.8. Since draft-reschke-rfc5987bis-06 . . . . . . . . . . . . 15 C.8. Since draft-reschke-rfc5987bis-06 . . . . . . . . . . . . 15
C.9. Since draft-ietf-httpbis-rfc5987bis-00 . . . . . . . . . . 15 C.9. Since draft-ietf-httpbis-rfc5987bis-00 . . . . . . . . . . 15
C.10. Since draft-ietf-httpbis-rfc5987bis-01 . . . . . . . . . . 15 C.10. Since draft-ietf-httpbis-rfc5987bis-01 . . . . . . . . . . 15
C.11. Since draft-ietf-httpbis-rfc5987bis-02 . . . . . . . . . . 16 C.11. Since draft-ietf-httpbis-rfc5987bis-02 . . . . . . . . . . 15
C.12. Since draft-ietf-httpbis-rfc5987bis-03 . . . . . . . . . . 16
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Use of characters outside the US-ASCII coded character set Use of characters outside the US-ASCII coded character set
([RFC0020]) in HTTP header fields ([RFC7230]) is non-trivial: ([RFC0020]) in HTTP header fields ([RFC7230]) is non-trivial:
o The HTTP specification discourages use of non-US-ASCII characters o The HTTP specification discourages use of non-US-ASCII characters
in field values, placing them into the "obs-text" ABNF production in field values, placing them into the "obs-text" ABNF production
([RFC7230], Section 3.2). ([RFC7230], Section 3.2).
skipping to change at page 9, line 30 skipping to change at page 9, line 30
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 draft-ietf-httpbis-rfc5987bis, Section 3.2> ext-value = <see draft-ietf-httpbis-rfc5987bis, Section 3.2>
[[pub: Upon publication as RFC, the string [[pub: Upon publication as RFC, the string
"draft-ietf-httpbis-rfc5987bis" needs to be replaced with the RFC "draft-ietf-httpbis-rfc5987bis" needs to be replaced with the RFC
name, and this comment needs to be removed.]] name, and this comment needs to be removed.]]
Note: The Parameter Value Continuation feature defined in Section Note: The Parameter Value Continuation feature defined in Section
3 of [RFC2231] makes it impossible to have multiple instances of 3 of [RFC2231] makes it impossible to have multiple instances of
extended parameters with identical parmname components, as the extended parameters with identical names, as the processing of
processing of continuations would become ambiguous. Thus, continuations would become ambiguous. Thus, specifications using
specifications using this extension are advised to disallow this this extension are advised to disallow this case for compatibility
case for compatibility with RFC 2231. 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 interpretation 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.
4.1. When to Use the Extension 4.1. When to Use the Extension
skipping to change at page 10, line 14 skipping to change at page 10, line 14
Furthermore, the extension ought to also be used whenever the Furthermore, the extension ought to also be used whenever the
parameter value needs to carry characters not present in the US-ASCII parameter value needs to carry characters not present in the US-ASCII
([RFC0020]) coded character set (note that it would be unacceptable ([RFC0020]) coded character set (note that it would be unacceptable
to define a new parameter that would be restricted to a subset of the to define a new parameter that would be restricted to a subset of the
Unicode character set). Unicode character set).
4.2. Error Handling 4.2. Error Handling
Header field specifications need to define whether multiple instances Header field specifications need to define whether multiple instances
of parameters with identical parmname components are allowed, and how of parameters with identical names are allowed, and how they should
they should be processed. This specification suggests that a be processed. This specification suggests that a parameter using the
parameter using the extended syntax takes precedence. This would extended syntax takes precedence. This would allow producers to use
allow producers to use both formats without breaking recipients that both formats without breaking recipients that do not understand the
do not understand the extended syntax yet. extended syntax yet.
Example: Example:
foo: bar; title="EURO exchange rates"; foo: bar; title="EURO exchange rates";
title*=utf-8''%e2%82%ac%20exchange%20rates title*=utf-8''%e2%82%ac%20exchange%20rates
In this case, the sender provides an ASCII version of the title for In this case, the sender provides an ASCII version of the title for
legacy recipients, but also includes an internationalized version for legacy recipients, but also includes an internationalized version for
recipients understanding this specification -- the latter obviously recipients understanding this specification -- the latter obviously
ought to prefer the new syntax over the old one. ought to prefer the new syntax over the old one.
skipping to change at page 13, line 29 skipping to change at page 13, line 29
[RFC7578] Masinter, L., "Returning Values from Forms: [RFC7578] Masinter, L., "Returning Values from Forms:
multipart/form-data", RFC 7578, DOI 10.17487/ multipart/form-data", RFC 7578, DOI 10.17487/
RFC7578, July 2015, RFC7578, July 2015,
<http://www.rfc-editor.org/info/rfc7578>. <http://www.rfc-editor.org/info/rfc7578>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer,
"HTTP Digest Access Authentication", RFC 7616, "HTTP Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<http://www.rfc-editor.org/info/rfc7616>. <http://www.rfc-editor.org/info/rfc7616>.
[XMLHttpRequest] van Kesteren, A., Aubourg, J., Song, J., and H. [XMLHttpRequest] WhatWG, "XMLHttpRequest",
Steen, "XMLHttpRequest Level 1", W3C Working <https://xhr.spec.whatwg.org/>.
Draft WD-XMLHttpRequest-20140130, January 2014, <ht
tp://www.w3.org/TR/2014/
WD-XMLHttpRequest-20140130/>.
Latest version available at
<http://www.w3.org/TR/XMLHttpRequest/>.
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 introduction was rewritten to better explain the issues around o The introduction was rewritten to better explain the issues around
non-ASCII characters in field values. non-ASCII characters in field values.
skipping to change at page 14, line 11 skipping to change at page 14, line 7
o The document does not attempt to re-define a generic "parameter" o The document does not attempt to re-define a generic "parameter"
ABNF anymore (it turned out that there really isn't a generic ABNF anymore (it turned out that there really isn't a generic
definition of parameters in HTTP; for instance, there are subtle definition of parameters in HTTP; for instance, there are subtle
differences with respect to whitespace handling). differences with respect to whitespace handling).
o A note about defects in error handling in current implementations o A note about defects in error handling in current implementations
was removed, as it wasn't accurate anymore. was removed, as it wasn't accurate anymore.
Appendix B. Implementation Report Appendix B. Implementation Report
The encoding defined in this document currently is used for two The encoding defined in this document currently is used for three
different HTTP header fields: different HTTP header fields:
o "Authorization" (as used in HTTP Digest Authentication, defined in o "Authorization" (as used in HTTP Digest Authentication, defined in
[RFC7616]), [RFC7616]),
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
skipping to change at page 16, line 14 skipping to change at page 16, line 7
C.11. Since draft-ietf-httpbis-rfc5987bis-02 C.11. Since draft-ietf-httpbis-rfc5987bis-02
RFC 2388 -> RFC 7578. RFC 2388 -> RFC 7578.
Expand on the motivation (see Expand on the motivation (see
<https://github.com/httpwg/http-extensions/issues/213>). <https://github.com/httpwg/http-extensions/issues/213>).
Mention RFC 7616 in implementation report. Mention RFC 7616 in implementation report.
C.12. Since draft-ietf-httpbis-rfc5987bis-03
Fixed one editorial issue. Updated XHR reference.
Fixed <https://github.com/httpwg/http-extensions/issues/266>: use of
now undefined term "parmname".
Include WG into Acknowledgements for this revision.
Mention RFC 5987 in the abstract
(<https://github.com/httpwg/http-extensions/issues/271>).
Appendix D. Acknowledgements Appendix D. Acknowledgements
Thanks to Martin Dürst and Frank Ellermann for help figuring out Thanks to Martin Dürst 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.
Furthermore thanks to the members of the IETF HTTP Working Group for
the feedback specific to this update of RFC 5987.
Author's Address Author's Address
Julian F. Reschke Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Münster, NW 48155 Münster, NW 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 15 change blocks. 
26 lines changed or deleted 39 lines changed or added

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