< draft-reschke-rfc2231-in-http-10.txt   draft-reschke-rfc2231-in-http-11.txt >
Network Working Group J. Reschke Network Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Intended status: Standards Track February 21, 2010 Intended status: Standards Track March 30, 2010
Expires: August 25, 2010 Expires: October 1, 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-10 draft-reschke-rfc2231-in-http-11
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 header fields. HTTP header fields.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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/>.
Note: as of January 2010, there were at least three independent Note: as of February 2010, there were at least three independent
implementations of the encoding defined in Section 3.2: Konqueror implementations of the encoding defined in Section 3.2: Konqueror
(trunk), Mozilla Firefox, and Opera. (starting with 4.4.1), Mozilla Firefox, and Opera.
Status of this Memo 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 August 25, 2010. This Internet-Draft will expire on October 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 9 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 9
4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 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
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
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) . . . . . . . . . . 12 by RFC Editor before publication) . . . . . . . . . . 12
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 . . . . . . . . . . 13 B.3. Since draft-reschke-rfc2231-in-http-02 . . . . . . . . . . 13
B.4. Since draft-reschke-rfc2231-in-http-03 . . . . . . . . . . 13 B.4. Since draft-reschke-rfc2231-in-http-03 . . . . . . . . . . 13
B.5. Since draft-reschke-rfc2231-in-http-04 . . . . . . . . . . 13 B.5. Since draft-reschke-rfc2231-in-http-04 . . . . . . . . . . 13
B.6. Since draft-reschke-rfc2231-in-http-05 . . . . . . . . . . 13 B.6. Since draft-reschke-rfc2231-in-http-05 . . . . . . . . . . 13
B.7. Since draft-reschke-rfc2231-in-http-06 . . . . . . . . . . 13 B.7. Since draft-reschke-rfc2231-in-http-06 . . . . . . . . . . 13
B.8. Since draft-reschke-rfc2231-in-http-07 . . . . . . . . . . 13 B.8. Since draft-reschke-rfc2231-in-http-07 . . . . . . . . . . 13
B.9. Since draft-reschke-rfc2231-in-http-08 . . . . . . . . . . 13 B.9. Since draft-reschke-rfc2231-in-http-08 . . . . . . . . . . 13
B.10. Since draft-reschke-rfc2231-in-http-09 . . . . . . . . . . 13 B.10. Since draft-reschke-rfc2231-in-http-09 . . . . . . . . . . 13
B.11. Since draft-reschke-rfc2231-in-http-10 . . . . . . . . . . 13
Appendix C. Resolved issues (to be removed by RFC Editor Appendix C. Resolved issues (to be removed by RFC Editor
before publication) . . . . . . . . . . . . . . . . . 13 before publication) . . . . . . . . . . . . . . . . . 14
C.1. rfc2978-normative . . . . . . . . . . . . . . . . . . . . 13 C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
C.2. rfc3986-normative . . . . . . . . . . . . . . . . . . . . 14 C.2. charset-registered . . . . . . . . . . . . . . . . . . . . 14
C.3. usascii-normative . . . . . . . . . . . . . . . . . . . . 14 C.3. parameter-abnf . . . . . . . . . . . . . . . . . . . . . . 14
Appendix D. Open issues (to be removed by RFC Editor prior to C.4. value-abnf . . . . . . . . . . . . . . . . . . . . . . . . 14
publication) . . . . . . . . . . . . . . . . . . . . 14 C.5. iso8859 . . . . . . . . . . . . . . . . . . . . . . . . . 15
D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 C.6. when-ext-value . . . . . . . . . . . . . . . . . . . . . . 15
D.2. parameter-abnf . . . . . . . . . . . . . . . . . . . . . . 14 C.7. repeated-param . . . . . . . . . . . . . . . . . . . . . . 15
D.3. iso8859 . . . . . . . . . . . . . . . . . . . . . . . . . 15 C.8. handling-multiple . . . . . . . . . . . . . . . . . . . . 16
D.4. when-ext-value . . . . . . . . . . . . . . . . . . . . . . 15 C.9. i18n-spoofing . . . . . . . . . . . . . . . . . . . . . . 17
D.5. i18n-spoofing . . . . . . . . . . . . . . . . . . . . . . 15 C.10. multiple-inst-spoofing . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
By default, message header field parameters in HTTP ([RFC2616]) By default, message header field parameters in HTTP ([RFC2616])
messages 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 (Appendix of [RFC2231]) defines an set ([ISO-8859-1]). RFC 2231 (Appendix of [RFC2231]) defines an
escaping mechanism for use in MIME headers. This document specifies escaping mechanism for use in MIME headers. This document specifies
a profile of that encoding for use in HTTP header fields. a profile of that encoding for use in HTTP header fields.
Note: this profile does not apply to message payloads transmitted Note: this profile does not apply to message payloads transmitted
skipping to change at page 5, line 40 skipping to change at page 5, line 40
(with RFC 2616 implied LWS translated to RFC 5234 LWSP): (with RFC 2616 implied LWS translated to RFC 5234 LWSP):
parameter = attribute LWSP "=" LWSP value parameter = attribute LWSP "=" LWSP value
attribute = token attribute = token
value = token / quoted-string value = token / quoted-string
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2> quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
token = <token, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC2616], Section 2.2>
This specification extends the grammar to: This specification modifies the grammar to:
parameter = reg-parameter / ext-parameter parameter = reg-parameter / ext-parameter
reg-parameter = attribute LWSP "=" LWSP value reg-parameter = parmname LWSP "=" LWSP value
ext-parameter = attribute "*" LWSP "=" LWSP ext-value ext-parameter = parmname "*" LWSP "=" LWSP ext-value
parmname = 1*attr-char
ext-value = charset "'" [ language ] "'" value-chars ext-value = charset "'" [ language ] "'" value-chars
; extended-initial-value, ; extended-initial-value,
; defined in [RFC2231], Section 7 ; defined in [RFC2231], Section 7
charset = "UTF-8" / "ISO-8859-1" / mime-charset charset = "UTF-8" / "ISO-8859-1" / mime-charset
mime-charset = 1*mime-charsetc mime-charset = 1*mime-charsetc
mime-charsetc = ALPHA / DIGIT mime-charsetc = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&" / "!" / "#" / "$" / "%" / "&"
/ "+" / "-" / "^" / "_" / "`" / "+" / "-" / "^" / "_" / "`"
/ "{" / "}" / "~" / "{" / "}" / "~"
; as <mime-charset> in Section 2.3 of [RFC2978] ; as <mime-charset> in Section 2.3 of [RFC2978]
; except that the single quote is not included ; except that the single quote is not included
; SHOULD be registered in the IANA charset registry
language = <Language-Tag, defined in [RFC5646], Section 2.1> language = <Language-Tag, defined in [RFC5646], Section 2.1>
value-chars = *( pct-encoded / attr-char ) value-chars = *( pct-encoded / attr-char )
pct-encoded = "%" HEXDIG HEXDIG pct-encoded = "%" HEXDIG HEXDIG
; see [RFC3986], Section 2.1 ; see [RFC3986], Section 2.1
attr-char = ALPHA / DIGIT attr-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "&" / "+" / "-" / "." / "!" / "#" / "$" / "&" / "+" / "-" / "."
skipping to change at page 9, line 8 skipping to change at page 9, line 8
For instance: For instance:
foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param
title-param = "title" LWSP "=" LWSP value title-param = "title" LWSP "=" LWSP value
/ "title*" LWSP "=" LWSP ext-value / "title*" LWSP "=" LWSP ext-value
ext-value = <see RFCxxxx, Section 3.2> ext-value = <see RFCxxxx, Section 3.2>
[[rfcno: Note to RFC Editor: in the figure above, please replace [[rfcno: Note to RFC Editor: in the figure above, please replace
"xxxx" by the RFC number assigned to this specification.]] "xxxx" by the RFC number assigned to this specification.]]
Note: The Parameter Value Continuation feature defined in Section
3 of [RFC2231] makes it impossible to have multiple instances of
extended parameters with identical parmname components, as the
processing of continuations would become ambiguous. Thus,
specifications using this extension are recommended to disallow
this case for compatibility with RFC 2231.
4.1. When to Use the Extension 4.1. When to Use the Extension
Section 4.2 of [RFC2277] requires that protocol elements containing Section 4.2 of [RFC2277] requires that protocol elements containing
text are able to carry language information. Thus, the ext-value text are able to carry language information. Thus, the ext-value
production should always be used when the parameter value is of production should always be used when the parameter value is of
textual nature. textual nature and its language is known.
Furthermore, the extension should also be used whenever the parameter Furthermore, the extension should also be used whenever the parameter
value needs to carry characters not present in the US-ASCII value needs to carry characters not present in the US-ASCII
([USASCII]) character set (note that it would be unacceptable to ([USASCII]) character set (note that it would be unacceptable to
define a new parameter that would be restricted to a subset of the 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 specifications that include parameters should also specify Header field specifications need to define whether multiple instances
whether same-named parameters can occur multiple times. If of parameters with identical parmname components are allowed, and how
repetitions are not allowed (and this is believed to be the common they should processed. It is recommended that a parameter using the
case), the specification should state whether regular or the extended extended syntax takes precedence. This could be used by producers to
syntax takes precedence. In the latter case, this could be used by use both formats without breaking recipients that do not understand
producers to use both formats without breaking recipients that do not the extended syntax yet.
understand the syntax.
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
should prefer the new syntax over the old one. should prefer the new syntax over the old one.
Note: at the time of this writing, many implementations failed to Note: at the time of this writing, many implementations failed to
ignore the form they do not understand, or prioritize the ASCII ignore the form they do not understand, or prioritize the ASCII
form although the extended syntax was present. form although the extended syntax was present.
4.3. Using Multiple Instances for Internationalization 5. Security Considerations
It is expected that in many cases, internationalization of parameters
in response headers is implemented using server driven content
negotiation ([RFC2616], Section 12.1) using the Accept-Language
header ([RFC2616], Section 14.4). However, the format described in
this specification also allows using multiple instances providing
multiple languages in a single header. Specifications that want to
take advantage of this should clearly specify the expected processing
by the recipient.
Example: 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.
foo: bar; title*=utf-8'en'Document%20Title; Furthermore, there are known attack scenarios relating to decoding
title*=utf-8'de'Titel%20des%20Dokuments UTF-8.
5. Security Considerations See Section 10 of [RFC3629] for more information on both topics.
This document does not discuss security issues and is not believed to In addition, the extension specified in this document makes it
raise any security issues not already endemic in HTTP. 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.
6. IANA Considerations 6. IANA Considerations
There are no IANA Considerations related to this specification. There are no IANA Considerations related to this specification.
7. Acknowledgements 7. Acknowledgements
Thanks to Martin Duerst and Frank Ellermann for help figuring out Thanks to Martin Duerst and Frank Ellermann for help figuring out
ABNF details, to Graham Klyne and Alexey Melnikov for general review, ABNF details, to Graham Klyne and Alexey Melnikov for general review,
and to Benjamin Carlyle and Roar Lauritzsen for implementer's Chris Newman for pointing out an RFC 2231 incompatibility, and to
feedback. Benjamin Carlyle and Roar Lauritzsen for implementer's feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ISO-8859-1] [ISO-8859-1] International Organization for Standardization,
International Organization for Standardization, "Information technology -- 8-bit single-byte coded
"Information technology -- 8-bit single-byte coded graphic graphic character sets -- Part 1: Latin alphabet No.
character sets -- Part 1: Latin alphabet No. 1", ISO/ 1", ISO/IEC 8859-1:1998, 1998.
IEC 8859-1:1998, 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003. 10646", RFC 3629, STD 63, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
Resource Identifier (URI): Generic Syntax", RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, January 2005. RFC 3986, STD 66, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Specifications: ABNF", STD 68, RFC 5234, January 2008. Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
Languages", BCP 47, RFC 5646, September 2009. Identifying Languages", BCP 47, RFC 5646,
September 2009.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
8.2. Informative References 8.2. Informative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet Message Mail Extensions (MIME) Part One: Format of Internet
Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Part Three: Message Header Extensions for Non-ASCII Text", Extensions) Part Three: Message Header Extensions for
RFC 2047, November 1996. Non-ASCII Text", 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
Word Extensions: Encoded Word Extensions: Character Sets, Languages, and
Character Sets, Languages, and Continuations", RFC 2231, 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/ [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998. form-data", RFC 2388, August 1998.
URIs URIs
[1] <mailto:ietf-http-wg@w3.org> [1] <mailto:ietf-http-wg@w3.org>
skipping to change at page 13, line 41 skipping to change at page 13, line 41
Editorial improvements. Add and resolve issues "attrcharvstoken" and Editorial improvements. Add and resolve issues "attrcharvstoken" and
"tokengrammar". "tokengrammar".
B.10. Since draft-reschke-rfc2231-in-http-09 B.10. Since draft-reschke-rfc2231-in-http-09
Add issues "i18n-spoofing", "iso8859", "parameter-abnf", and "when- Add issues "i18n-spoofing", "iso8859", "parameter-abnf", and "when-
ext-value". Add and resolve issues "rfc2978-normative", "rfc3986- ext-value". Add and resolve issues "rfc2978-normative", "rfc3986-
normative" and "usascii-normative". normative" and "usascii-normative".
B.11. Since draft-reschke-rfc2231-in-http-10
Resolve issues "i18n-spoofing", "iso8859", "parameter-abnf", and
"when-ext-value".
Add and resolve issue "charset-registered", "handling-multiple",
"multiple-inst-spoofing", "repeated-param" and "value-abnf".
Update the KDE implementation note.
Appendix C. Resolved issues (to be removed by RFC Editor before 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 Issues that were either rejected or resolved in this version of this
document. document.
C.1. rfc2978-normative C.1. edit
In Section 3.2:
Type: change Type: edit
julian.reschke@greenbytes.de (2010-02-20): The reference to RFC2978
needs to be normative (reported by Alexey Melnikov).
Resolution (2010-02-20): Done. julian.reschke@greenbytes.de (2009-04-17): Umbrella issue for
editorial fixes/enhancements.
C.2. rfc3986-normative C.2. charset-registered
In Section 3.2: In Section 3.2:
Type: change Type: change
julian.reschke@greenbytes.de (2010-02-20): The reference to percent- julian.reschke@greenbytes.de (2010-02-20): Mention to use only
encoding (RFC3986) needs to be normative (reported by Alexey registered charset names? (reported by Alexey Melnikov).
Melnikov).
Resolution (2010-02-20): Done. Resolution (2010-03-29): State this in the ABNF.
C.3. usascii-normative C.3. parameter-abnf
In Section 4.1: In Section 3.2:
Type: change Type: change
julian.reschke@greenbytes.de (2010-02-20): The reference to USASCII julian.reschke@greenbytes.de (2010-02-20): The ABNF for reg-parameter
needs to be normative. and ext-parameter is ambiguous, as "*" is a valid token character;
furthermore, RFC 2616's "attribute" production allows "*" while RFC
Resolution (2010-02-20): Done. 2231's does not. (reported by Alexey Melnikov).
Appendix D. Open issues (to be removed by RFC Editor prior to
publication)
D.1. edit
Type: edit julian.reschke@greenbytes.de (2010-02-21): Proposal: restrict the
allowable character set in parameter names to exclude "*" (and maybe
even more non-name characters?). Also, consider extending the set of
value characters (for the right hand side) to allow more characters
that can be unambiguously parsed outside quoted strings, such as "/".
julian.reschke@greenbytes.de (2009-04-17): Umbrella issue for Resolution: Introduced parmname, disallowing "*" / "'" / "%". Moving
editorial fixes/enhancements. the value ABNF discussion into a separate issue ("value-abnf").
D.2. parameter-abnf C.4. value-abnf
In Section 3.2: In Section 3.2:
Type: change Type: change
julian.reschke@greenbytes.de (2010-02-20): The ABNF for reg-parameter julian.reschke@greenbytes.de (2010-02-26): Consider extending the
and ext-parameter is ambiguous, as "*" is a valid token character; right-hand side ABNF - both for regular and extended parameters - to
furthermore, RFC 2616's "attribute" production allows "*" while RFC include more characters that can be unambiguously parsed outside
2231's does not. (reported by Alexey Melnikov). quoted strings, such as "/".
julian.reschke@greenbytes.de (2010-02-21): Proposal: destrict the Resolution (2010-03-29): No change due to lack of feedback.
allowable character set in parameter names to exclude "*" (amd maybe Potentially defer to future versions of HTTP/1.1 (defining guidelines
even more non-name characters?). Also, consider extending the set of for header definitions), or a revision of this spec.
value characters (for the right hand side) to allow more characters
that can be umabigouously parsed outside quoted strings, such as "/".
D.3. iso8859 C.5. iso8859
In Section 3.2: In Section 3.2:
Type: change Type: change
julian.reschke@greenbytes.de (2010-02-20): The protocol could be julian.reschke@greenbytes.de (2010-02-20): The protocol could be
further simplified by mandating UTF-8 only (reported by Alexey further simplified by mandating UTF-8 only (reported by Alexey
Melnikov). On the other hand and not surprinsingly, testing shows Melnikov). On the other hand and not surprinsingly, testing shows
that ISO-8859-1 support is widely implemented. The author is looking that ISO-8859-1 support is widely implemented. The author is looking
for community feedback on this choice. for community feedback on this choice.
D.4. when-ext-value Resolution (2010-03-29): Further feedback was requested during IETF
LC; but none was received. Thus defaulting to no change; keeping the
support for ISO-8859-1.
C.6. when-ext-value
In Section 4.1: In Section 4.1:
Type: change Type: change
julian.reschke@greenbytes.de (2010-02-18): There's no point in using julian.reschke@greenbytes.de (2010-02-18): There's no point in using
ext-value when the language is unknown and no "special" characters ext-value when the language is unknown and no "special" characters
are present. are present.
D.5. i18n-spoofing Resolution (2010-02-23): Fixed.
C.7. repeated-param
In Section 4:
Type: change
Chris.Newman@Sun.COM (2010-03-22): RFC 2231 did not allow two
parameters with the same name but different languages, at least in
the context of continuations that was impossible. Absent
continuations, RFC 2231 was otherwise silent on that topic.
So section 4.3 adds a new feature over and above what RFC 2231 did.
It's a feature that will make implementations significantly more
complex and is likely to cause interoperability problems.
Much of the experience with deployment of both language tagging and
language variants in the IETF seems to result in unnecessary
complexity. While there are good abstract arguments for language
tagging in theory, it seems more often than not that the parties in
the exchange are unable to put anything useful in the field in which
case it falls into the realm of unnecessary complexity. In addition,
we have experience where we attempted to allow language variants
(multipart/alternative) and not only did that usage not deploy, it is
actively broken despite being an explicit example in RFC 1766.
The one place where I've seen language variants mostly work is when
the language tag is actually included in the attribute name (LDAP
does this) and the "search" mechanism allows wildcarding of
languages. But having two attributes with the same name seems
dangerous.
My recommendation is to remove this feature as I believe it will not
be used in practice and will add unnecessary complexity that is
likely to create interoperability problems.
Resolution (2010-03-29): State the issue. Remove section 4.3.
Rephrase 4.2 accordingly.
C.8. handling-multiple
In Section 4.2:
Type: change
<http://www.ietf.org/mail-archive/web/apps-discuss/current/
msg01344.html>
roessler@gmail.com (2010-02-24): Leaving the choice of precedence to
the header specification implies that parsers need to special-case.
It would seem reasonable to make a choice in this specification that
for properties which can only occur once, the traditional syntax
takes precedence.
julian.reschke@greenbytes.de (2010-02-26): That would rule out the
use case where the traditional syntax is used as a fallback for
clients that do not support the new syntax, as discussed in that
section: ... http://greenbytes.de/tech/tc2231/#attfnboth2 is a test
case that shows that using this technique, both variants can be
served to clients, and those that understand the ext-parameter
encoding will indeed pick the "better" parameter. Unfortunately,
this appears to depend on parameter ordering, which I didn't want to
mention in this spec. Maybe I should?
Resolution (2010-03-29): Just state that when repetitions are not
allowed, the extended form should take precedence.
C.9. i18n-spoofing
In Section 5: In Section 5:
Type: change Type: change
<http://www.ietf.org/mail-archive/web/apps-discuss/current/ <http://www.ietf.org/mail-archive/web/apps-discuss/current/
msg01329.html> msg01329.html>
GK@ninebynine.org (2010-02-20): I note that the security GK@ninebynine.org (2010-02-20): I note that the security
considerations section says nothing about possible character considerations section says nothing about possible character
"spoofing" - i.e. making a displayed prompt or value appear to be "spoofing" - i.e. making a displayed prompt or value appear to be
something other than it is. E.g. Non-ASCII characters have been something other than it is. E.g. Non-ASCII characters have been
used to set up exploits involving dodgy URIs that may appear to a used to set up exploits involving dodgy URIs that may appear to a
user to be legitimate. user to be legitimate.
Resolution (2010-02-23): Mention the problem, and point to RFC 3629's
security considerations which mention this as well. While at it,
also mention the other UTF-8 related attack scenario.
C.10. multiple-inst-spoofing
In Section 5:
Type: change
kivinen@iki.fi (2010-03-01): Yes, but the impact of them is
different. For example it does not really matter if the filename
parameters having different languages differ, but there might be
parameters where this really matters.
As this document does not define any exact parameters, it might be
enough to comment something like that "This document specifies way to
transport multiple language variants for parameters, and such use
might allow spoofing attacks, where different language versions of
the same parameters do not match. Whether this attack is useful as
an attack depends on the parameter specified."
Resolution (2010-03-01): Add text based on the recommendation.
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. 49 change blocks. 
111 lines changed or deleted 211 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