idnits 2.17.1
draft-ietf-httpbis-rfc5987bis-02.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 draft header indicates that this document obsoletes RFC5987, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 8, 2016) is 2848 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 2388
(Obsoleted by RFC 7578)
-- 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 (==), 7 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) July 8, 2016
5 Intended status: Standards Track
6 Expires: January 9, 2017
8 Indicating Character Encoding and Language for HTTP Header Field
9 Parameters
10 draft-ietf-httpbis-rfc5987bis-02
12 Abstract
14 By default, header field values in Hypertext Transfer Protocol (HTTP)
15 messages cannot directly carry characters outside the US-ASCII coded
16 character set. RFC 2231 defines an encoding mechanism for use in
17 Multipurpose Internet Mail Extensions (MIME) headers. This document
18 specifies an encoding suitable for use in HTTP header fields that is
19 compatible with a profile of the encoding defined in RFC 2231.
21 Editorial Note (To be removed by RFC Editor before publication)
23 Discussion of this draft takes place on the HTTPBIS working group
24 mailing list (ietf-http-wg@w3.org), which is archived at
25 .
27 Working Group information can be found at ;
28 source code and issues list for this draft can be found at
29 .
31 The changes in this draft are summarized in Appendix C.
33 Status of This Memo
35 This Internet-Draft is submitted in full conformance with the
36 provisions of BCP 78 and BCP 79.
38 Internet-Drafts are working documents of the Internet Engineering
39 Task Force (IETF). Note that other groups may also distribute
40 working documents as Internet-Drafts. The list of current Internet-
41 Drafts is at http://datatracker.ietf.org/drafts/current/.
43 Internet-Drafts are draft documents valid for a maximum of six months
44 and may be updated, replaced, or obsoleted by other documents at any
45 time. It is inappropriate to use Internet-Drafts as reference
46 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on January 9, 2017.
50 Copyright Notice
52 Copyright (c) 2016 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
69 3. Comparison to RFC 2231 and Definition of the Encoding . . . . 4
70 3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 5
71 3.2. Parameter Value Character Encoding and Language
72 Information . . . . . . . . . . . . . . . . . . . . . . . 5
73 3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 5
74 3.2.2. Historical Notes . . . . . . . . . . . . . . . . . . . 7
75 3.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 7
76 3.3. Language Specification in Encoded Words . . . . . . . . . 8
77 4. Guidelines for Usage in HTTP Header Field Definitions . . . . 8
78 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 9
79 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9
80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
84 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
85 Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . . 13
86 Appendix B. Implementation Report . . . . . . . . . . . . . . . . 13
87 Appendix C. Change Log (to be removed by RFC Editor before
88 publication) . . . . . . . . . . . . . . . . . . . . 14
89 C.1. Since RFC5987 . . . . . . . . . . . . . . . . . . . . . . 14
90 C.2. Since draft-reschke-rfc5987bis-00 . . . . . . . . . . . . 14
91 C.3. Since draft-reschke-rfc5987bis-01 . . . . . . . . . . . . 14
92 C.4. Since draft-reschke-rfc5987bis-02 . . . . . . . . . . . . 14
93 C.5. Since draft-reschke-rfc5987bis-03 . . . . . . . . . . . . 14
94 C.6. Since draft-reschke-rfc5987bis-04 . . . . . . . . . . . . 14
95 C.7. Since draft-reschke-rfc5987bis-05 . . . . . . . . . . . . 14
96 C.8. Since draft-reschke-rfc5987bis-06 . . . . . . . . . . . . 14
97 C.9. Since draft-ietf-httpbis-rfc5987bis-00 . . . . . . . . . . 14
98 C.10. Since draft-ietf-httpbis-rfc5987bis-01 . . . . . . . . . . 15
99 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 15
101 1. Introduction
103 By default, header field values in HTTP messages ([RFC7230]) cannot
104 directly carry characters outside the US-ASCII coded character set
105 ([RFC0020]). RFC 2231 ([RFC2231]) defines an encoding mechanism for
106 use in MIME headers. This document specifies an encoding suitable
107 for use in HTTP header fields that is compatible with a profile of
108 the encoding defined in RFC 2231.
110 This document obsoletes [RFC5987] and moves it to "historic" status;
111 the changes are summarized in Appendix A.
113 Note: in the remainder of this document, RFC 2231 is only
114 referenced for the purpose of explaining the choice of features
115 that were adopted; they are therefore purely informative.
117 Note: this encoding does not apply to message payloads transmitted
118 over HTTP, such as when using the media type "multipart/form-data"
119 ([RFC2388]).
121 2. Notational Conventions
123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
125 document are to be interpreted as described in [RFC2119].
127 This specification uses the ABNF (Augmented Backus-Naur Form)
128 notation defined in [RFC5234]. The following core rules are included
129 by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters),
130 DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and LWSP
131 (linear whitespace).
133 This specification uses terminology defined in [RFC6365], namely:
134 "character encoding scheme" (below abbreviated to "character
135 encoding"), "charset" and "coded character set".
137 Note that this differs from RFC 2231, which uses the term "character
138 set" for "character encoding scheme".
140 3. Comparison to RFC 2231 and Definition of the Encoding
142 RFC 2231 defines several extensions to MIME. The sections below
143 discuss if and how they apply to HTTP header fields.
145 In short:
147 o Parameter Continuations aren't needed (Section 3.1),
148 o Character Encoding and Language Information are useful, therefore
149 a simple subset is specified (Section 3.2), and
151 o Language Specifications in Encoded Words aren't needed
152 (Section 3.3).
154 3.1. Parameter Continuations
156 Section 3 of [RFC2231] defines a mechanism that deals with the length
157 limitations that apply to MIME headers. These limitations do not
158 apply to HTTP ([RFC7231], Appendix A.6).
160 Thus, parameter continuations are not part of the encoding defined by
161 this specification.
163 3.2. Parameter Value Character Encoding and Language Information
165 Section 4 of [RFC2231] specifies how to embed language information
166 into parameter values, and also how to encode non-ASCII characters,
167 dealing with restrictions both in MIME and HTTP header field
168 parameters.
170 However, RFC 2231 does not specify a mandatory-to-implement character
171 encoding, making it hard for senders to decide which encoding to use.
172 Thus, recipients implementing this specification MUST support the
173 "UTF-8" character encoding [RFC3629].
175 Furthermore, RFC 2231 allows the character encoding information to be
176 left out. The encoding defined by this specification does not allow
177 that.
179 3.2.1. Definition
181 The presence of extended parameter values usually is indicated by a
182 parameter name ending in an asterisk character. Note however that
183 this is just a convention, and that it needs to be explicitly
184 specified in the definition of the header field using this extension
185 (see Section 4).
187 The ABNF for extended parameter values is specified below:
189 ext-value = charset "'" [ language ] "'" value-chars
190 ; like RFC 2231's
191 ; (see [RFC2231], Section 7)
193 charset = "UTF-8" / mime-charset
195 mime-charset = 1*mime-charsetc
196 mime-charsetc = ALPHA / DIGIT
197 / "!" / "#" / "$" / "%" / "&"
198 / "+" / "-" / "^" / "_" / "`"
199 / "{" / "}" / "~"
200 ; as in Section 2.3 of [RFC2978]
201 ; except that the single quote is not included
202 ; SHOULD be registered in the IANA charset registry
204 language =
206 value-chars = *( pct-encoded / attr-char )
208 pct-encoded = "%" HEXDIG HEXDIG
209 ; see [RFC3986], Section 2.1
211 attr-char = ALPHA / DIGIT
212 / "!" / "#" / "$" / "&" / "+" / "-" / "."
213 / "^" / "_" / "`" / "|" / "~"
214 ; token except ( "*" / "'" / "%" )
216 The value part of an extended parameter (ext-value) is a token that
217 consists of three parts:
219 1. the REQUIRED character encoding name (charset),
221 2. the OPTIONAL language information (language), and
223 3. a character sequence representing the actual value (value-chars),
224 separated by single quote characters.
226 Note that both character encoding names and language tags are
227 restricted to the US-ASCII coded character set, and are matched case-
228 insensitively (see [RFC2978], Section 2.3 and [RFC5646], Section
229 2.1.1).
231 Inside the value part, characters not contained in attr-char are
232 encoded into an octet sequence using the specified character
233 encoding. That octet sequence is then percent-encoded as specified
234 in Section 2.1 of [RFC3986].
236 Producers MUST use the "UTF-8" ([RFC3629]) character encoding.
238 Extension character encodings (mime-charset) are reserved for future
239 use.
241 Note: recipients should be prepared to handle encoding errors,
242 such as malformed or incomplete percent escape sequences, or non-
243 decodable octet sequences, in a robust manner. This specification
244 does not mandate any specific behavior, for instance, the
245 following strategies are all acceptable:
247 * ignoring the parameter,
249 * stripping a non-decodable octet sequence,
251 * substituting a non-decodable octet sequence by a replacement
252 character, such as the Unicode character U+FFFD (Replacement
253 Character).
255 3.2.2. Historical Notes
257 The RFC 7230 token production ([RFC7230], Section 3.2.6) differs from
258 the production used in RFC 2231 (imported from Section 5.1 of
259 [RFC2045]) in that curly braces ("{" and "}") are excluded. Thus,
260 these two characters are excluded from the attr-char production as
261 well.
263 The ABNF defined here differs from the one in Section
264 2.3 of [RFC2978] in that it does not allow the single quote character
265 (see also RFC Errata ID 1912 [Err1912]). In practice, no character
266 encoding names using that character have been registered at the time
267 of this writing.
269 For backwards compatibility with RFC 2231, the encoding defined by
270 this specification deviates from common parameter syntax in that the
271 quoted-string notation is not allowed. Implementations using generic
272 parser components might not be able to detect the use of quoted-
273 string notation and thus might accept that format, although invalid,
274 as well.
276 [RFC5987] did require support for ISO-8859-1 ([ISO-8859-1]), too; for
277 compatibility with legacy code, recipients are encouraged to support
278 this encoding as well.
280 3.2.3. Examples
282 Non-extended notation, using "token":
284 foo: bar; title=Economy
286 Non-extended notation, using "quoted-string":
288 foo: bar; title="US-$ rates"
290 Extended notation, using the Unicode character U+00A3 ("£", POUND
291 SIGN):
293 foo: bar; title*=utf-8'en'%C2%A3%20rates
295 Note: the Unicode pound sign character U+00A3 was encoded into the
296 octet sequence C2 A3 using the UTF-8 character encoding, then
297 percent-encoded. Also, note that the space character was encoded as
298 %20, as it is not contained in attr-char.
300 Extended notation, using the Unicode characters U+00A3 ("£", POUND
301 SIGN) and U+20AC ("€", EURO SIGN):
303 foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates
305 Note: the Unicode pound sign character U+00A3 was encoded into the
306 octet sequence C2 A3 using the UTF-8 character encoding, then
307 percent-encoded. Likewise, the Unicode euro sign character U+20AC
308 was encoded into the octet sequence E2 82 AC, then percent-encoded.
309 Also note that HEXDIG allows both lowercase and uppercase characters,
310 so recipients must understand both, and that the language information
311 is optional, while the character encoding is not.
313 3.3. Language Specification in Encoded Words
315 Section 5 of [RFC2231] extends the encoding defined in [RFC2047] to
316 also support language specification in encoded words. RFC 2616, the
317 now-obsolete HTTP/1.1 specification, did refer to RFC 2047
318 ([RFC2616], Section 2.2). However, it wasn't clear to which header
319 field it applied. Consequently, the current revision of the HTTP/1.1
320 specification has deprecated use of the encoding forms defined in RFC
321 2047 (see Section 3.2.4 of [RFC7230]).
323 Thus, this specification does not include this feature.
325 4. Guidelines for Usage in HTTP Header Field Definitions
327 Specifications of HTTP header fields that use the extensions defined
328 in Section 3.2 ought to clearly state that. A simple way to achieve
329 this is to normatively reference this specification, and to include
330 the ext-value production into the ABNF for specific header field
331 parameters.
333 For instance:
335 foo = token ";" LWSP title-param
336 title-param = "title" LWSP "=" LWSP value
337 / "title*" LWSP "=" LWSP ext-value
338 ext-value =
340 [[pub: Upon publication as RFC, the string
341 "draft-ietf-httpbis-rfc5987bis" needs to be replaced with the RFC
342 name, and this comment needs to be removed.]]
344 Note: The Parameter Value Continuation feature defined in Section
345 3 of [RFC2231] makes it impossible to have multiple instances of
346 extended parameters with identical parmname components, as the
347 processing of continuations would become ambiguous. Thus,
348 specifications using this extension are advised to disallow this
349 case for compatibility with RFC 2231.
351 Note: This specification does not automatically assign a new
352 interpretration to parameter names ending in an asterisk. As
353 pointed out above, it's up to the specification for the non-
354 extended parameter to "opt in" to the syntax defined here. That
355 being said, some existing implementations are known to
356 automatically switch to the use of this notation when a parameter
357 name ends with an asterisk, thus using parameter names ending in
358 an asterisk for something else is likely to cause interoperability
359 problems.
361 4.1. When to Use the Extension
363 Section 4.2 of [RFC2277] requires that protocol elements containing
364 human-readable text are able to carry language information. Thus,
365 the ext-value production ought to be always used when the parameter
366 value is of textual nature and its language is known.
368 Furthermore, the extension ought to also be used whenever the
369 parameter value needs to carry characters not present in the US-ASCII
370 ([RFC0020]) coded character set (note that it would be unacceptable
371 to define a new parameter that would be restricted to a subset of the
372 Unicode character set).
374 4.2. Error Handling
376 Header field specifications need to define whether multiple instances
377 of parameters with identical parmname components are allowed, and how
378 they should be processed. This specification suggests that a
379 parameter using the extended syntax takes precedence. This would
380 allow producers to use both formats without breaking recipients that
381 do not understand the extended syntax yet.
383 Example:
385 foo: bar; title="EURO exchange rates";
386 title*=utf-8''%e2%82%ac%20exchange%20rates
388 In this case, the sender provides an ASCII version of the title for
389 legacy recipients, but also includes an internationalized version for
390 recipients understanding this specification -- the latter obviously
391 ought to prefer the new syntax over the old one.
393 Note: at the time of this writing, many implementations failed to
394 ignore the form they do not understand, or prioritize the ASCII
395 form although the extended syntax was present.
397 5. Security Considerations
399 The format described in this document makes it possible to transport
400 non-ASCII characters, and thus enables character "spoofing"
401 scenarios, in which a displayed value appears to be something other
402 than it is.
404 Furthermore, there are known attack scenarios relating to decoding
405 UTF-8.
407 See Section 10 of [RFC3629] for more information on both topics.
409 In addition, the extension specified in this document makes it
410 possible to transport multiple language variants for a single
411 parameter, and such use might allow spoofing attacks, where different
412 language versions of the same parameter are not equivalent. Whether
413 this attack is useful as an attack depends on the parameter
414 specified.
416 6. IANA Considerations
418 There are no IANA Considerations related to this specification.
420 7. References
422 7.1. Normative References
424 [RFC0020] Cerf, V., "ASCII format for network interchange",
425 STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969,
426 .
428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
429 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
430 RFC2119, March 1997,
431 .
433 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
434 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978,
435 October 2000, .
437 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
438 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
439 November 2003,
440 .
442 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
443 "Uniform Resource Identifier (URI): Generic Syntax",
444 STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
445 .
447 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
448 Syntax Specifications: ABNF", STD 68, RFC 5234,
449 DOI 10.17487/RFC5234, January 2008,
450 .
452 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
453 Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/
454 RFC5646, September 2009,
455 .
457 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
458 Transfer Protocol (HTTP/1.1): Message Syntax and
459 Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014,
460 .
462 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
463 Transfer Protocol (HTTP/1.1): Semantics and Content",
464 RFC 7231, DOI 10.17487/RFC7231, June 2014,
465 .
467 7.2. Informative References
469 [Err1912] RFC Errata, "Errata ID 1912, RFC 2978", October 2009,
470 .
472 [ISO-8859-1] International Organization for Standardization,
473 "Information technology -- 8-bit single-byte coded
474 graphic character sets -- Part 1: Latin alphabet No.
475 1", ISO/IEC 8859-1:1998, 1998.
477 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
478 Mail Extensions (MIME) Part One: Format of Internet
479 Message Bodies", RFC 2045, DOI 10.17487/RFC2045,
480 November 1996,
481 .
483 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
484 Extensions) Part Three: Message Header Extensions for
485 Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047,
486 November 1996,
487 .
489 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
490 Encoded Word Extensions: Character Sets, Languages, and
491 Continuations", RFC 2231, DOI 10.17487/RFC2231,
492 November 1997,
493 .
495 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
496 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
497 January 1998, .
499 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
500 form-data", RFC 2388, DOI 10.17487/RFC2388,
501 August 1998, .
503 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
504 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
505 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/
506 RFC2616, June 1999,
507 .
509 [RFC5987] Reschke, J., "Character Set and Language Encoding for
510 Hypertext Transfer Protocol (HTTP) Header Field
511 Parameters", RFC 5987, DOI 10.17487/RFC5987,
512 August 2010, .
514 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/
515 RFC5988, October 2010,
516 .
518 [RFC6266] Reschke, J., "Use of the Content-Disposition Header
519 Field in the Hypertext Transfer Protocol (HTTP)",
520 RFC 6266, DOI 10.17487/RFC6266, June 2011,
521 .
523 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
524 Internationalization in the IETF", BCP 166, RFC 6365,
525 DOI 10.17487/RFC6365, September 2011,
526 .
528 Appendix A. Changes from RFC 5987
530 This section summarizes the changes compared to [RFC5987]:
532 o The document title was changed to "Indicating Character Encoding
533 and Language for HTTP Header Field Parameters".
535 o The requirement to support the "ISO-8859-1" encoding was removed.
537 o The document does not attempt to re-define a generic "parameter"
538 ABNF anymore (it turned out that there really isn't a generic
539 definition of parameters in HTTP; for instance, there are subtle
540 differences with respect to whitespace handling).
542 Appendix B. Implementation Report
544 The encoding defined in this document currently is used for two
545 different HTTP header fields:
547 o "Content-Disposition", defined in [RFC6266], and
549 o "Link", defined in [RFC5988].
551 As the encoding is a profile/clarification of the one defined in
552 [RFC2231] in 1997, many user agents already supported it for use in
553 "Content-Disposition" when [RFC5987] got published.
555 Since the publication of [RFC5987], three more popular desktop user
556 agents have added support for this encoding; see for details.
558 At this time, the current versions of all major desktop user agents
559 support it.
561 Note that the implementation in Internet Explorer 9 does not support
562 the ISO-8859-1 character encoding; this document revision
563 acknowledges that UTF-8 is sufficient for expressing all code points,
564 and removes the requirement to support ISO-8859-1.
566 The "Link" header field, on the other hand, was only recently
567 specified in [RFC5988]. At the time of this writing, no shipping
568 User Agent except Firefox supported the "title*" parameter (starting
569 with release 15).
571 Appendix C. Change Log (to be removed by RFC Editor before publication)
573 C.1. Since RFC5987
575 Only editorial changes for the purpose of starting the revision
576 process (obs5987).
578 C.2. Since draft-reschke-rfc5987bis-00
580 Resolved issues "iso-8859-1" and "title" (title simplified). Added
581 and resolved issue "historic5987".
583 C.3. Since draft-reschke-rfc5987bis-01
585 Added issues "httpbis", "parmsyntax", "terminology" and
586 "valuesyntax". Closed issue "impls".
588 C.4. Since draft-reschke-rfc5987bis-02
590 Resolved issue "terminology".
592 C.5. Since draft-reschke-rfc5987bis-03
594 In Section 3.2, pull historical notes into a separate subsection.
595 Resolved issues "valuesyntax" and "parmsyntax".
597 C.6. Since draft-reschke-rfc5987bis-04
599 Update status of Firefox support in HTTP Link Header field.
601 C.7. Since draft-reschke-rfc5987bis-05
603 Update status of Firefox support in HTTP Link Header field.
605 C.8. Since draft-reschke-rfc5987bis-06
607 Update status with respect to Safari 6.
609 Started work on update with respect to RFC 723x.
611 C.9. Since draft-ietf-httpbis-rfc5987bis-00
613 Editorial changes; introducing non-ASCII characters into author's
614 address, acknowledgements, and examples.
616 C.10. Since draft-ietf-httpbis-rfc5987bis-01
618 Removed mention of RFC 2616 from Abstract and Introduction.
620 Reference RFC 20 for US-ASCII.
622 Do not attempt to define a generic parameter ABNF; just concentrate
623 on the parameter value syntax.
625 Appendix D. Acknowledgements
627 Thanks to Martin Dürst and Frank Ellermann for help figuring out
628 ABNF details, to Graham Klyne and Alexey Melnikov for general review,
629 to Chris Newman for pointing out an RFC 2231 incompatibility, and to
630 Benjamin Carlyle, Roar Lauritzsen, Eric Lawrence, and James Manger
631 for implementer's feedback.
633 Author's Address
635 Julian F. Reschke
636 greenbytes GmbH
637 Hafenweg 16
638 Münster, NW 48155
639 Germany
641 EMail: julian.reschke@greenbytes.de
642 URI: http://greenbytes.de/tech/webdav/