idnits 2.17.1
draft-ietf-httpbis-rfc5987bis-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== There are 5 instances of lines with non-ascii characters in the document.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The abstract seems to indicate that this document obsoletes RFC2231, but
the header doesn't have an 'Obsoletes:' line to match this.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 2, 2017) is 2605 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112)
** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110)
-- Duplicate reference: RFC2978, mentioned in 'Err1912', was also mentioned
in 'RFC2978'.
-- Obsolete informational reference (is this intentional?): RFC 2616
(Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 5987
(Obsoleted by RFC 8187)
-- Obsolete informational reference (is this intentional?): RFC 5988
(Obsoleted by RFC 8288)
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 HTTP Working Group J. Reschke
3 Internet-Draft greenbytes
4 Obsoletes: 5987 (if approved) March 2, 2017
5 Intended status: Standards Track
6 Expires: September 3, 2017
8 Indicating Character Encoding and Language for HTTP Header Field
9 Parameters
10 draft-ietf-httpbis-rfc5987bis-05
12 Abstract
14 By default, header field values in Hypertext Transfer Protocol (HTTP)
15 messages cannot easily carry characters outside the US-ASCII coded
16 character set. RFC 2231 defines an encoding mechanism for use in
17 parameters inside Multipurpose Internet Mail Extensions (MIME) header
18 field values. This document specifies an encoding suitable for use
19 in HTTP header fields that is compatible with a simplified profile of
20 the encoding defined in RFC 2231.
22 This document obsoletes RFC 5987.
24 Editorial Note (To be removed by RFC Editor before publication)
26 Discussion of this draft takes place on the HTTPBIS working group
27 mailing list (ietf-http-wg@w3.org), which is archived at
28 .
30 Working Group information can be found at ;
31 source code and issues list for this draft can be found at
32 .
34 The changes in this draft are summarized in Appendix C.
36 Status of This Memo
38 This Internet-Draft is submitted in full conformance with the
39 provisions of BCP 78 and BCP 79.
41 Internet-Drafts are working documents of the Internet Engineering
42 Task Force (IETF). Note that other groups may also distribute
43 working documents as Internet-Drafts. The list of current Internet-
44 Drafts is at http://datatracker.ietf.org/drafts/current/.
46 Internet-Drafts are draft documents valid for a maximum of six months
47 and may be updated, replaced, or obsoleted by other documents at any
48 time. It is inappropriate to use Internet-Drafts as reference
49 material or to cite them other than as "work in progress."
51 This Internet-Draft will expire on September 3, 2017.
53 Copyright Notice
55 Copyright (c) 2017 IETF Trust and the persons identified as the
56 document authors. All rights reserved.
58 This document is subject to BCP 78 and the IETF Trust's Legal
59 Provisions Relating to IETF Documents
60 (http://trustee.ietf.org/license-info) in effect on the date of
61 publication of this document. Please review these documents
62 carefully, as they describe your rights and restrictions with respect
63 to this document. Code Components extracted from this document must
64 include Simplified BSD License text as described in Section 4.e of
65 the Trust Legal Provisions and are provided without warranty as
66 described in the Simplified BSD License.
68 Table of Contents
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
72 3. Comparison to RFC 2231 and Definition of the Encoding . . . . 5
73 3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 5
74 3.2. Parameter Value Character Encoding and Language
75 Information . . . . . . . . . . . . . . . . . . . . . . . 5
76 3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 6
77 3.2.2. Historical Notes . . . . . . . . . . . . . . . . . . . 7
78 3.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 8
79 3.3. Language Specification in Encoded Words . . . . . . . . . 8
80 4. Guidelines for Usage in HTTP Header Field Definitions . . . . 9
81 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 9
82 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 10
83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
87 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
88 Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . . 13
89 Appendix B. Implementation Report . . . . . . . . . . . . . . . . 14
90 Appendix C. Change Log (to be removed by RFC Editor before
91 publication) . . . . . . . . . . . . . . . . . . . . 14
92 C.1. Since RFC5987 . . . . . . . . . . . . . . . . . . . . . . 15
93 C.2. Since draft-reschke-rfc5987bis-00 . . . . . . . . . . . . 15
94 C.3. Since draft-reschke-rfc5987bis-01 . . . . . . . . . . . . 15
95 C.4. Since draft-reschke-rfc5987bis-02 . . . . . . . . . . . . 15
96 C.5. Since draft-reschke-rfc5987bis-03 . . . . . . . . . . . . 15
97 C.6. Since draft-reschke-rfc5987bis-04 . . . . . . . . . . . . 15
98 C.7. Since draft-reschke-rfc5987bis-05 . . . . . . . . . . . . 15
99 C.8. Since draft-reschke-rfc5987bis-06 . . . . . . . . . . . . 15
100 C.9. Since draft-ietf-httpbis-rfc5987bis-00 . . . . . . . . . . 15
101 C.10. Since draft-ietf-httpbis-rfc5987bis-01 . . . . . . . . . . 15
102 C.11. Since draft-ietf-httpbis-rfc5987bis-02 . . . . . . . . . . 16
103 C.12. Since draft-ietf-httpbis-rfc5987bis-03 . . . . . . . . . . 16
104 C.13. Since draft-ietf-httpbis-rfc5987bis-04 . . . . . . . . . . 16
105 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 16
107 1. Introduction
109 Use of characters outside the US-ASCII coded character set
110 ([RFC0020]) in HTTP header fields ([RFC7230]) is non-trivial:
112 o The HTTP specification discourages use of non-US-ASCII characters
113 in field values, placing them into the "obs-text" ABNF production
114 ([RFC7230], Section 3.2).
116 o Furthermore, it stays silent about default character encoding
117 schemes for field values, so any use of non-US-ASCII characters
118 would need to be specific to the field definition, or would
119 require some other kind of out-of-band information.
121 o Finally, some APIs assume a default character encoding scheme in
122 order to map from the octet sequences (obtained from the HTTP
123 message) to character sequences: for instance, the XMLHttpRequest
124 API ([XMLHttpRequest]) uses the Interface Definition Language type
125 "ByteString", effectively resulting in the ISO-8859-1 character
126 encoding scheme [ISO-8859-1] being used.
128 On the other hand, RFC 2231 defines an encoding mechanism for
129 parameters inside MIME header fields ([RFC2231]), which, as opposed
130 to HTTP messages, do need to be sent over non-binary transports.
131 This document specifies an encoding suitable for use in HTTP header
132 fields that is compatible with a simplified profile of the encoding
133 defined in RFC 2231. It can be applied to any HTTP header field that
134 uses the common "parameter" ("name=value") syntax.
136 This document obsoletes [RFC5987] and moves it to "historic" status;
137 the changes are summarized in Appendix A.
139 Note: in the remainder of this document, RFC 2231 is only
140 referenced for the purpose of explaining the choice of features
141 that were adopted; they are therefore purely informative.
143 Note: this encoding does not apply to message payloads transmitted
144 over HTTP, such as when using the media type "multipart/form-data"
145 ([RFC7578]).
147 2. Notational Conventions
149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
151 document are to be interpreted as described in [RFC2119].
153 This specification uses the ABNF (Augmented Backus-Naur Form)
154 notation defined in [RFC5234]. The following core rules are included
155 by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters),
156 DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and LWSP
157 (linear whitespace).
159 This specification uses terminology defined in [RFC6365], namely:
160 "character encoding scheme" (below abbreviated to "character
161 encoding"), "charset" and "coded character set".
163 Note that this differs from RFC 2231, which uses the term "character
164 set" for "character encoding scheme".
166 3. Comparison to RFC 2231 and Definition of the Encoding
168 RFC 2231 defines several extensions to MIME. The sections below
169 discuss if and how they apply to HTTP header fields.
171 In short:
173 o Parameter Continuations aren't needed (Section 3.1),
175 o Character Encoding and Language Information are useful, therefore
176 a simple subset is specified (Section 3.2), and
178 o Language Specifications in Encoded Words aren't needed
179 (Section 3.3).
181 3.1. Parameter Continuations
183 Section 3 of [RFC2231] defines a mechanism that deals with the length
184 limitations that apply to MIME headers. These limitations do not
185 apply to HTTP ([RFC7231], Appendix A.6).
187 Thus, parameter continuations are not part of the encoding defined by
188 this specification.
190 3.2. Parameter Value Character Encoding and Language Information
192 Section 4 of [RFC2231] specifies how to embed language information
193 into parameter values, and also how to encode non-ASCII characters,
194 dealing with restrictions both in MIME and HTTP header field
195 parameters.
197 However, RFC 2231 does not specify a mandatory-to-implement character
198 encoding, making it hard for senders to decide which encoding to use.
199 Thus, recipients implementing this specification MUST support the
200 "UTF-8" character encoding [RFC3629].
202 Furthermore, RFC 2231 allows the character encoding information to be
203 left out. The encoding defined by this specification does not allow
204 that.
206 3.2.1. Definition
208 The presence of extended parameter values usually is indicated by a
209 parameter name ending in an asterisk character. Note however that
210 this is just a convention, and that it needs to be explicitly
211 specified in the definition of the header field using this extension
212 (see Section 4).
214 The ABNF for extended parameter values is specified below:
216 ext-value = charset "'" [ language ] "'" value-chars
217 ; like RFC 2231's
218 ; (see [RFC2231], Section 7)
220 charset = "UTF-8" / mime-charset
222 mime-charset = 1*mime-charsetc
223 mime-charsetc = ALPHA / DIGIT
224 / "!" / "#" / "$" / "%" / "&"
225 / "+" / "-" / "^" / "_" / "`"
226 / "{" / "}" / "~"
227 ; as in Section 2.3 of [RFC2978]
228 ; except that the single quote is not included
229 ; SHOULD be registered in the IANA charset registry
231 language =
233 value-chars = *( pct-encoded / attr-char )
235 pct-encoded = "%" HEXDIG HEXDIG
236 ; see [RFC3986], Section 2.1
238 attr-char = ALPHA / DIGIT
239 / "!" / "#" / "$" / "&" / "+" / "-" / "."
240 / "^" / "_" / "`" / "|" / "~"
241 ; token except ( "*" / "'" / "%" )
243 The value part of an extended parameter (ext-value) is a token that
244 consists of three parts:
246 1. the REQUIRED character encoding name (charset),
248 2. the OPTIONAL language information (language), and
249 3. a character sequence representing the actual value (value-chars),
250 separated by single quote characters.
252 Note that both character encoding names and language tags are
253 restricted to the US-ASCII coded character set, and are matched case-
254 insensitively (see [RFC2978], Section 2.3 and [RFC5646], Section
255 2.1.1).
257 Inside the value part, characters not contained in attr-char are
258 encoded into an octet sequence using the specified character
259 encoding. That octet sequence is then percent-encoded as specified
260 in Section 2.1 of [RFC3986].
262 Producers MUST use the "UTF-8" ([RFC3629]) character encoding.
263 Extension character encodings (mime-charset) are reserved for future
264 use.
266 Note: recipients should be prepared to handle encoding errors,
267 such as malformed or incomplete percent escape sequences, or non-
268 decodable octet sequences, in a robust manner. This specification
269 does not mandate any specific behavior, for instance, the
270 following strategies are all acceptable:
272 * ignoring the parameter,
274 * stripping a non-decodable octet sequence,
276 * substituting a non-decodable octet sequence by a replacement
277 character, such as the Unicode character U+FFFD (Replacement
278 Character).
280 3.2.2. Historical Notes
282 The RFC 7230 token production ([RFC7230], Section 3.2.6) differs from
283 the production used in RFC 2231 (imported from Section 5.1 of
284 [RFC2045]) in that curly braces ("{" and "}") are excluded. Thus,
285 these two characters are excluded from the attr-char production as
286 well.
288 The ABNF defined here differs from the one in Section
289 2.3 of [RFC2978] in that it does not allow the single quote character
290 (see also RFC Errata ID 1912 [Err1912]). In practice, no character
291 encoding names using that character have been registered at the time
292 of this writing.
294 For backwards compatibility with RFC 2231, the encoding defined by
295 this specification deviates from common parameter syntax in that the
296 quoted-string notation is not allowed. Implementations using generic
297 parser components might not be able to detect the use of quoted-
298 string notation and thus might accept that format, although invalid,
299 as well.
301 [RFC5987] did require support for ISO-8859-1 ([ISO-8859-1]), too; for
302 compatibility with legacy code, recipients are encouraged to support
303 this encoding as well.
305 3.2.3. Examples
307 Non-extended notation, using "token":
309 foo: bar; title=Economy
311 Non-extended notation, using "quoted-string":
313 foo: bar; title="US-$ rates"
315 Extended notation, using the Unicode character U+00A3 ("£", POUND
316 SIGN):
318 foo: bar; title*=utf-8'en'%C2%A3%20rates
320 Note: the Unicode pound sign character U+00A3 was encoded into the
321 octet sequence C2 A3 using the UTF-8 character encoding, then
322 percent-encoded. Also, note that the space character was encoded as
323 %20, as it is not contained in attr-char.
325 Extended notation, using the Unicode characters U+00A3 ("£", POUND
326 SIGN) and U+20AC ("€", EURO SIGN):
328 foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates
330 Note: the Unicode pound sign character U+00A3 was encoded into the
331 octet sequence C2 A3 using the UTF-8 character encoding, then
332 percent-encoded. Likewise, the Unicode euro sign character U+20AC
333 was encoded into the octet sequence E2 82 AC, then percent-encoded.
334 Also note that HEXDIG allows both lowercase and uppercase characters,
335 so recipients must understand both, and that the language information
336 is optional, while the character encoding is not.
338 3.3. Language Specification in Encoded Words
340 Section 5 of [RFC2231] extends the encoding defined in [RFC2047] to
341 also support language specification in encoded words. RFC 2616, the
342 now-obsolete HTTP/1.1 specification, did refer to RFC 2047
343 ([RFC2616], Section 2.2). However, it wasn't clear to which header
344 field it applied. Consequently, the current revision of the HTTP/1.1
345 specification has deprecated use of the encoding forms defined in RFC
346 2047 (see Section 3.2.4 of [RFC7230]).
348 Thus, this specification does not include this feature.
350 4. Guidelines for Usage in HTTP Header Field Definitions
352 Specifications of HTTP header fields that use the extensions defined
353 in Section 3.2 ought to clearly state that. A simple way to achieve
354 this is to normatively reference this specification, and to include
355 the ext-value production into the ABNF for specific header field
356 parameters.
358 For instance:
360 foo = token ";" LWSP title-param
361 title-param = "title" LWSP "=" LWSP value
362 / "title*" LWSP "=" LWSP ext-value
363 ext-value =
365 [[pub: Upon publication as RFC, the string
366 "draft-ietf-httpbis-rfc5987bis" needs to be replaced with the RFC
367 name, and this comment needs to be removed.]]
369 Note: The Parameter Value Continuation feature defined in Section
370 3 of [RFC2231] makes it impossible to have multiple instances of
371 extended parameters with identical names, as the processing of
372 continuations would become ambiguous. Thus, specifications using
373 this extension are advised to disallow this case for compatibility
374 with RFC 2231.
376 Note: This specification does not automatically assign a new
377 interpretation to parameter names ending in an asterisk. As
378 pointed out above, it's up to the specification for the non-
379 extended parameter to "opt in" to the syntax defined here. That
380 being said, some existing implementations are known to
381 automatically switch to the use of this notation when a parameter
382 name ends with an asterisk, thus using parameter names ending in
383 an asterisk for something else is likely to cause interoperability
384 problems.
386 4.1. When to Use the Extension
388 Section 4.2 of [RFC2277] requires that protocol elements containing
389 human-readable text are able to carry language information. Thus,
390 the ext-value production ought to be always used when the parameter
391 value is of textual nature and its language is known.
393 Furthermore, the extension ought to also be used whenever the
394 parameter value needs to carry characters not present in the US-ASCII
395 ([RFC0020]) coded character set (note that it would be unacceptable
396 to define a new parameter that would be restricted to a subset of the
397 Unicode character set).
399 4.2. Error Handling
401 Header field specifications need to define whether multiple instances
402 of parameters with identical names are allowed, and how they should
403 be processed. This specification suggests that a parameter using the
404 extended syntax takes precedence. This would allow producers to use
405 both formats without breaking recipients that do not understand the
406 extended syntax yet.
408 Example:
410 foo: bar; title="EURO exchange rates";
411 title*=utf-8''%e2%82%ac%20exchange%20rates
413 In this case, the sender provides an ASCII version of the title for
414 legacy recipients, but also includes an internationalized version for
415 recipients understanding this specification -- the latter obviously
416 ought to prefer the new syntax over the old one.
418 5. Security Considerations
420 The format described in this document makes it possible to transport
421 non-ASCII characters, and thus enables character "spoofing"
422 scenarios, in which a displayed value appears to be something other
423 than it is.
425 Furthermore, there are known attack scenarios relating to decoding
426 UTF-8.
428 See Section 10 of [RFC3629] for more information on both topics.
430 In addition, the extension specified in this document makes it
431 possible to transport multiple language variants for a single
432 parameter, and such use might allow spoofing attacks, where different
433 language versions of the same parameter are not equivalent. Whether
434 this attack is useful as an attack depends on the parameter
435 specified.
437 6. IANA Considerations
439 There are no IANA Considerations related to this specification.
441 7. References
443 7.1. Normative References
445 [RFC0020] Cerf, V., "ASCII format for network interchange",
446 STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969,
447 .
449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
450 Requirement Levels", BCP 14, RFC 2119,
451 DOI 10.17487/RFC2119, March 1997,
452 .
454 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
455 Procedures", BCP 19, RFC 2978, DOI 10.17487/
456 RFC2978, October 2000,
457 .
459 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
460 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
461 November 2003,
462 .
464 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
465 "Uniform Resource Identifier (URI): Generic
466 Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986,
467 January 2005,
468 .
470 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
471 Syntax Specifications: ABNF", STD 68, RFC 5234,
472 DOI 10.17487/RFC5234, January 2008,
473 .
475 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
476 Identifying Languages", BCP 47, RFC 5646,
477 DOI 10.17487/RFC5646, September 2009,
478 .
480 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
481 Transfer Protocol (HTTP/1.1): Message Syntax and
482 Routing", RFC 7230, DOI 10.17487/RFC7230,
483 June 2014,
484 .
486 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
487 Transfer Protocol (HTTP/1.1): Semantics and
488 Content", RFC 7231, DOI 10.17487/RFC7231,
489 June 2014,
490 .
492 7.2. Informative References
494 [Err1912] RFC Errata, "Errata ID 1912, RFC 2978",
495 October 2009, .
497 [ISO-8859-1] International Organization for Standardization,
498 "Information technology -- 8-bit single-byte coded
499 graphic character sets -- Part 1: Latin alphabet
500 No. 1", ISO/IEC 8859-1:1998, 1998.
502 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
503 Mail Extensions (MIME) Part One: Format of Internet
504 Message Bodies", RFC 2045, DOI 10.17487/RFC2045,
505 November 1996,
506 .
508 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
509 Extensions) Part Three: Message Header Extensions
510 for Non-ASCII Text", RFC 2047, DOI 10.17487/
511 RFC2047, November 1996,
512 .
514 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
515 Encoded Word Extensions: Character Sets, Languages,
516 and Continuations", RFC 2231, DOI 10.17487/RFC2231,
517 November 1997,
518 .
520 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
521 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
522 January 1998,
523 .
525 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
526 Masinter, L., Leach, P., and T. Berners-Lee,
527 "Hypertext Transfer Protocol -- HTTP/1.1",
528 RFC 2616, DOI 10.17487/RFC2616, June 1999,
529 .
531 [RFC5987] Reschke, J., "Character Set and Language Encoding
532 for Hypertext Transfer Protocol (HTTP) Header Field
533 Parameters", RFC 5987, DOI 10.17487/RFC5987,
534 August 2010,
535 .
537 [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
538 DOI 10.17487/RFC5988, October 2010,
539 .
541 [RFC6266] Reschke, J., "Use of the Content-Disposition Header
542 Field in the Hypertext Transfer Protocol (HTTP)",
543 RFC 6266, DOI 10.17487/RFC6266, June 2011,
544 .
546 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
547 Internationalization in the IETF", BCP 166,
548 RFC 6365, DOI 10.17487/RFC6365, September 2011,
549 .
551 [RFC7578] Masinter, L., "Returning Values from Forms:
552 multipart/form-data", RFC 7578, DOI 10.17487/
553 RFC7578, July 2015,
554 .
556 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer,
557 "HTTP Digest Access Authentication", RFC 7616,
558 DOI 10.17487/RFC7616, September 2015,
559 .
561 [RFC8053] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K.,
562 Hayashi, T., and Y. Ioku, "HTTP Authentication
563 Extensions for Interactive Clients", RFC 8053,
564 DOI 10.17487/RFC8053, January 2017,
565 .
567 [XMLHttpRequest] WhatWG, "XMLHttpRequest",
568 .
570 Appendix A. Changes from RFC 5987
572 This section summarizes the changes compared to [RFC5987]:
574 o The document title was changed to "Indicating Character Encoding
575 and Language for HTTP Header Field Parameters".
577 o The introduction was rewritten to better explain the issues around
578 non-ASCII characters in field values.
580 o The requirement to support the "ISO-8859-1" encoding was removed.
582 o The document does not attempt to re-define a generic "parameter"
583 ABNF anymore (it turned out that there really isn't a generic
584 definition of parameters in HTTP; for instance, there are subtle
585 differences with respect to whitespace handling).
587 o A note about defects in error handling in current implementations
588 was removed, as it wasn't accurate anymore.
590 Appendix B. Implementation Report
592 The encoding defined in this document currently is used in four
593 different HTTP header fields:
595 o "Authentication-Control", defined in [RFC8053],
597 o "Authorization" (as used in HTTP Digest Authentication, defined in
598 [RFC7616]),
600 o "Content-Disposition", defined in [RFC6266], and
602 o "Link", defined in [RFC5988].
604 As the encoding is a profile/clarification of the one defined in
605 [RFC2231] in 1997, many user agents already supported it for use in
606 "Content-Disposition" when [RFC5987] got published.
608 Since the publication of [RFC5987], three more popular desktop user
609 agents have added support for this encoding; see for details.
611 At this time, the current versions of all major desktop user agents
612 support it.
614 Note that the implementation in Internet Explorer 9 does not support
615 the ISO-8859-1 character encoding; this document revision
616 acknowledges that UTF-8 is sufficient for expressing all code points,
617 and removes the requirement to support ISO-8859-1.
619 The "Link" header field, on the other hand, was more recently
620 specified in [RFC5988]. At the time of this writing, no User Agent
621 except Firefox supported the "title*" parameter (starting with
622 release 15).
624 Section 3.4 of [RFC7616] defines the "username*" parameter for use in
625 HTTP Digest Authentication. At the time of writing, no User Agent
626 implemented this extension.
628 Appendix C. Change Log (to be removed by RFC Editor before publication)
629 C.1. Since RFC5987
631 Only editorial changes for the purpose of starting the revision
632 process (obs5987).
634 C.2. Since draft-reschke-rfc5987bis-00
636 Resolved issues "iso-8859-1" and "title" (title simplified). Added
637 and resolved issue "historic5987".
639 C.3. Since draft-reschke-rfc5987bis-01
641 Added issues "httpbis", "parmsyntax", "terminology" and
642 "valuesyntax". Closed issue "impls".
644 C.4. Since draft-reschke-rfc5987bis-02
646 Resolved issue "terminology".
648 C.5. Since draft-reschke-rfc5987bis-03
650 In Section 3.2, pull historical notes into a separate subsection.
651 Resolved issues "valuesyntax" and "parmsyntax".
653 C.6. Since draft-reschke-rfc5987bis-04
655 Update status of Firefox support in HTTP Link Header field.
657 C.7. Since draft-reschke-rfc5987bis-05
659 Update status of Firefox support in HTTP Link Header field.
661 C.8. Since draft-reschke-rfc5987bis-06
663 Update status with respect to Safari 6.
665 Started work on update with respect to RFC 723x.
667 C.9. Since draft-ietf-httpbis-rfc5987bis-00
669 Editorial changes; introducing non-ASCII characters into author's
670 address, acknowledgements, and examples.
672 C.10. Since draft-ietf-httpbis-rfc5987bis-01
674 Removed mention of RFC 2616 from Abstract and Introduction.
676 Reference RFC 20 for US-ASCII.
678 Do not attempt to define a generic parameter ABNF; just concentrate
679 on the parameter value syntax.
681 C.11. Since draft-ietf-httpbis-rfc5987bis-02
683 RFC 2388 -> RFC 7578.
685 Expand on the motivation (see
686 ).
688 Mention RFC 7616 in implementation report.
690 C.12. Since draft-ietf-httpbis-rfc5987bis-03
692 Fixed one editorial issue. Updated XHR reference.
694 Fixed : use of
695 now undefined term "parmname".
697 Include WG into Acknowledgements for this revision.
699 Mention RFC 5987 in the abstract
700 ().
702 C.13. Since draft-ietf-httpbis-rfc5987bis-04
704 Mention RFC8053 in Implementation Report.
706 Appendix D. Acknowledgements
708 Thanks to Martin Dürst and Frank Ellermann for help figuring out
709 ABNF details, to Graham Klyne and Alexey Melnikov for general review,
710 to Chris Newman for pointing out an RFC 2231 incompatibility, and to
711 Benjamin Carlyle, Roar Lauritzsen, Eric Lawrence, and James Manger
712 for implementer's feedback.
714 Furthermore thanks to the members of the IETF HTTP Working Group for
715 the feedback specific to this update of RFC 5987.
717 Author's Address
719 Julian F. Reschke
720 greenbytes GmbH
721 Hafenweg 16
722 Münster, NW 48155
723 Germany
725 EMail: julian.reschke@greenbytes.de
726 URI: http://greenbytes.de/tech/webdav/