< draft-reschke-rfc2231-in-http-07.txt   draft-reschke-rfc2231-in-http-08.txt >
Network Working Group J. Reschke Network Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Intended status: Standards Track December 27, 2009 Intended status: Standards Track January 19, 2010
Expires: June 30, 2010 Expires: July 23, 2010
Application of RFC 2231 Encoding to Application of RFC 2231 Encoding to
Hypertext Transfer Protocol (HTTP) Header Fields Hypertext Transfer Protocol (HTTP) Header Fields
draft-reschke-rfc2231-in-http-07 draft-reschke-rfc2231-in-http-08
Abstract Abstract
By default, message header field parameters in Hypertext Transfer By default, message header field parameters in Hypertext Transfer
Protocol (HTTP) messages can not carry characters outside the ISO- Protocol (HTTP) messages can not carry characters outside the ISO-
8859-1 character set. RFC 2231 defines an escaping mechanism for use 8859-1 character set. RFC 2231 defines an escaping mechanism for use
in Multipurpose Internet Mail Extensions (MIME) headers. This in Multipurpose Internet Mail Extensions (MIME) headers. This
document specifies a profile of that encoding suitable for use in document specifies a profile of that encoding suitable for use in
HTTP. HTTP header fields.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
There are multiple HTTP header fields that already use RFC 2231 There are multiple HTTP header fields that already use RFC 2231
encoding in practice (Content-Disposition) or might use it in the encoding in practice (Content-Disposition) or might use it in the
future (Link). The purpose of this document is to provide a single future (Link). The purpose of this document is to provide a single
place where the generic aspects of RFC 2231 encoding in HTTP header place where the generic aspects of RFC 2231 encoding in HTTP header
fields is defined. fields are defined.
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-wg@w3.org [1], which may be joined by sending a message ietf-http-wg@w3.org [1], which may be joined by sending a message
with subject "subscribe" to ietf-http-wg-request@w3.org [2]. with subject "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 and the issues list for this document are XML versions, latest edits and the issues list for this document are
available from available from
<http://greenbytes.de/tech/webdav/#draft-reschke-rfc2231-in-http>. A <http://greenbytes.de/tech/webdav/#draft-reschke-rfc2231-in-http>. 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 Note: as of January 2010, there were at least three independent
implementations of the encoding defined in Section 3.2: Konqueror
(trunk), Mozilla Firefox, and Opera.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 30, 2010. This Internet-Draft will expire on July 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. A Profile of RFC 2231 for Use in HTTP . . . . . . . . . . . . 4 3. A Profile of RFC 2231 for Use in HTTP . . . . . . . . . . . . 4
3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 4 3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 5
3.2. Parameter Value Character Set and Language Information . . 5 3.2. Parameter Value Character Set and Language Information . . 5
3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . 8 4. Guidelines for Usage in HTTP Header Field Definitions . . . . 8
4.1. When to Use the Extension . . . . . . . . . . . . . . . . 8 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 8
4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Using Multiple Instances for Internationalization . . . . 9 4.3. Using Multiple Instances for Internationalization . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 34 skipping to change at page 3, line 34
Appendix A. Document History and Future Plans (to be removed Appendix A. Document History and Future Plans (to be removed
by RFC Editor before publication) . . . . . . . . . . 11 by RFC Editor before publication) . . . . . . . . . . 11
Appendix B. Change Log (to be removed by RFC Editor before Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 12 publication) . . . . . . . . . . . . . . . . . . . . 12
B.1. Since draft-reschke-rfc2231-in-http-00 . . . . . . . . . . 12 B.1. Since draft-reschke-rfc2231-in-http-00 . . . . . . . . . . 12
B.2. Since draft-reschke-rfc2231-in-http-01 . . . . . . . . . . 12 B.2. Since draft-reschke-rfc2231-in-http-01 . . . . . . . . . . 12
B.3. Since draft-reschke-rfc2231-in-http-02 . . . . . . . . . . 12 B.3. Since draft-reschke-rfc2231-in-http-02 . . . . . . . . . . 12
B.4. Since draft-reschke-rfc2231-in-http-03 . . . . . . . . . . 12 B.4. Since draft-reschke-rfc2231-in-http-03 . . . . . . . . . . 12
B.5. Since draft-reschke-rfc2231-in-http-04 . . . . . . . . . . 12 B.5. Since draft-reschke-rfc2231-in-http-04 . . . . . . . . . . 12
B.6. Since draft-reschke-rfc2231-in-http-05 . . . . . . . . . . 12 B.6. Since draft-reschke-rfc2231-in-http-05 . . . . . . . . . . 12
B.7. Since draft-reschke-rfc2231-in-http-06 . . . . . . . . . . 12 B.7. Since draft-reschke-rfc2231-in-http-06 . . . . . . . . . . 13
Appendix C. Open issues (to be removed by RFC Editor prior to B.8. Since draft-reschke-rfc2231-in-http-07 . . . . . . . . . . 13
publication) . . . . . . . . . . . . . . . . . . . . 13 Appendix C. Resolved issues (to be removed by RFC Editor
before publication) . . . . . . . . . . . . . . . . . 13
C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
C.2. impl . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
C.3. rel-2388 . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
By default, message header field parameters in HTTP ([RFC2616]) By default, message header field parameters in HTTP ([RFC2616])
messages can not carry characters outside the ISO-8859-1 character messages can not carry characters outside the ISO-8859-1 character
set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an escaping set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an escaping
mechanism for use in MIME headers. This document specifies a profile mechanism for use in MIME headers. This document specifies a profile
of that encoding for use in HTTP. of that encoding for use in HTTP header fields.
Note: this profile does not apply to message payloads transmitted
over HTTP, such as when using the media type "multipart/form-data"
([RFC2388]).
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification uses the ABNF (Augmented Backus-Naur Form) This specification uses the ABNF (Augmented Backus-Naur Form)
notation defined in [RFC5234]. The following core rules are included notation defined in [RFC5234]. The following core rules are included
by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters),
skipping to change at page 11, line 13 skipping to change at page 11, line 13
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231, Character Sets, Languages, and Continuations", RFC 2231,
November 1997. November 1997.
[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, January 1998.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998.
[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, October 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, Resource Identifier (URI): Generic Syntax", RFC 3986,
STD 66, January 2005. STD 66, January 2005.
[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.
skipping to change at page 13, line 5 skipping to change at page 13, line 10
B.6. Since draft-reschke-rfc2231-in-http-05 B.6. Since draft-reschke-rfc2231-in-http-05
Say "header field" instead of "header" in the context of HTTP. Say "header field" instead of "header" in the context of HTTP.
B.7. Since draft-reschke-rfc2231-in-http-06 B.7. Since draft-reschke-rfc2231-in-http-06
Add an appendix discussing document history and future plans, to be Add an appendix discussing document history and future plans, to be
removed before publication. removed before publication.
Appendix C. Open issues (to be removed by RFC Editor prior to B.8. Since draft-reschke-rfc2231-in-http-07
Add and resolve issues "impl" and "rel-2388".
Appendix C. Resolved issues (to be removed by RFC Editor before
publication) publication)
Issues that were either rejected or resolved in this version of this
document.
C.1. edit C.1. edit
Type: edit Type: edit
julian.reschke@greenbytes.de (2009-04-17): Umbrella issue for julian.reschke@greenbytes.de (2009-04-17): Umbrella issue for
editorial fixes/enhancements. editorial fixes/enhancements.
C.2. impl
Type: edit
julian.reschke@greenbytes.de (2010-01-16): Report on current
implementations.
C.3. rel-2388
Type: edit
julian.reschke@greenbytes.de (2010-01-07): Note the non-applicability
to the use of RFC 2231 encoding in multipart/form-data.
Resolution (2010-01-07): Done.
Author's Address Author's Address
Julian F. Reschke Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, 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. 16 change blocks. 
14 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35