idnits 2.17.1
draft-reschke-rfc5987bis-04.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:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The abstract seems to contain references ([2], [1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
-- The draft header indicates that this document obsoletes RFC5987, but the
abstract doesn't seem to directly say this. It does mention RFC5987
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (December 18, 2011) is 4512 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 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'
-- 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 5987
(Obsoleted by RFC 8187)
-- Obsolete informational reference (is this intentional?): RFC 5988
(Obsoleted by RFC 8288)
Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Reschke
3 Internet-Draft greenbytes
4 Obsoletes: 5987 (if approved) December 18, 2011
5 Intended status: Standards Track
6 Expires: June 20, 2012
8 Indicating Character Encoding and Language for HTTP Header Field
9 Parameters
10 draft-reschke-rfc5987bis-04
12 Abstract
14 By default, message header field parameters in Hypertext Transfer
15 Protocol (HTTP) messages cannot carry characters outside the ISO-
16 8859-1 character set. RFC 2231 defines an encoding mechanism for use
17 in Multipurpose Internet Mail Extensions (MIME) headers. This
18 document specifies an encoding suitable for use in HTTP header fields
19 that is compatible with a profile of the encoding defined in RFC
20 2231.
22 Editorial Note (To be removed by RFC Editor before publication)
24 Distribution of this document is unlimited. Although this is not a
25 work item of the HTTPbis Working Group, comments should be sent to
26 the Hypertext Transfer Protocol (HTTP) mailing list at
27 ietf-http-wg@w3.org [1], which may be joined by sending a message
28 with subject "subscribe" to ietf-http-wg-request@w3.org [2].
30 Discussions of the HTTPbis Working Group are archived at
31 .
33 XML versions, latest edits, diffs, and the issues list for this
34 document are available from
35 . A
36 collection of test cases is available at
37 .
39 Status of This Memo
41 This Internet-Draft is submitted in full conformance with the
42 provisions of BCP 78 and BCP 79.
44 Internet-Drafts are working documents of the Internet Engineering
45 Task Force (IETF). Note that other groups may also distribute
46 working documents as Internet-Drafts. The list of current Internet-
47 Drafts is at http://datatracker.ietf.org/drafts/current/.
49 Internet-Drafts are draft documents valid for a maximum of six months
50 and may be updated, replaced, or obsoleted by other documents at any
51 time. It is inappropriate to use Internet-Drafts as reference
52 material or to cite them other than as "work in progress."
54 This Internet-Draft will expire on June 20, 2012.
56 Copyright Notice
58 Copyright (c) 2011 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
71 Table of Contents
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
74 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
75 3. Comparison to RFC 2231 and Definition of the Encoding . . . . 4
76 3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 5
77 3.2. Parameter Value Character Encoding and Language
78 Information . . . . . . . . . . . . . . . . . . . . . . . 5
79 3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 5
80 3.2.2. Historical Notes . . . . . . . . . . . . . . . . . . . 7
81 3.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 8
82 3.3. Language Specification in Encoded Words . . . . . . . . . 8
83 4. Guidelines for Usage in HTTP Header Field Definitions . . . . 9
84 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 9
85 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9
86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
89 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
90 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
91 Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . . 12
92 Appendix B. Implementation Report . . . . . . . . . . . . . . . . 12
93 Appendix C. Change Log (to be removed by RFC Editor before
94 publication) . . . . . . . . . . . . . . . . . . . . 13
95 C.1. Since RFC5987 . . . . . . . . . . . . . . . . . . . . . . 13
96 C.2. Since draft-reschke-rfc5987bis-00 . . . . . . . . . . . . 13
97 C.3. Since draft-reschke-rfc5987bis-01 . . . . . . . . . . . . 13
98 C.4. Since draft-reschke-rfc5987bis-02 . . . . . . . . . . . . 13
99 C.5. Since draft-reschke-rfc5987bis-03 . . . . . . . . . . . . 13
100 Appendix D. Resolved issues (to be removed by RFC Editor
101 before publication) . . . . . . . . . . . . . . . . . 14
102 D.1. parmsyntax . . . . . . . . . . . . . . . . . . . . . . . . 14
103 D.2. valuesyntax . . . . . . . . . . . . . . . . . . . . . . . 14
104 Appendix E. Open issues (to be removed by RFC Editor prior to
105 publication) . . . . . . . . . . . . . . . . . . . . 14
106 E.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
107 E.2. httpbis . . . . . . . . . . . . . . . . . . . . . . . . . 15
109 1. Introduction
111 By default, message header field parameters in HTTP ([RFC2616])
112 messages cannot carry characters outside the ISO-8859-1 coded
113 character set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an
114 encoding mechanism for use in MIME headers. This document specifies
115 an encoding suitable for use in HTTP header fields that is compatible
116 with a profile of the encoding defined in RFC 2231.
118 This document obsoletes [RFC5987] and moves it to "historic" status;
119 the changes are summarized in Appendix A.
121 Note: in the remainder of this document, RFC 2231 is only
122 referenced for the purpose of explaining the choice of features
123 that were adopted; they are therefore purely informative.
125 Note: this encoding does not apply to message payloads transmitted
126 over HTTP, such as when using the media type "multipart/form-data"
127 ([RFC2388]).
129 2. Notational Conventions
131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
133 document are to be interpreted as described in [RFC2119].
135 This specification uses the ABNF (Augmented Backus-Naur Form)
136 notation defined in [RFC5234]. The following core rules are included
137 by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters),
138 DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and LWSP
139 (linear whitespace).
141 This specification uses terminology defined in [RFC6365], namely:
142 "character encoding scheme" (below abbreviated to "character
143 encoding"), "charset" and "coded character set".
145 Note that this differs from RFC 2231, which uses the term "character
146 set" for "character encoding scheme".
148 3. Comparison to RFC 2231 and Definition of the Encoding
150 RFC 2231 defines several extensions to MIME. The sections below
151 discuss if and how they apply to HTTP header fields.
153 In short:
155 o Parameter Continuations aren't needed (Section 3.1),
156 o Character Encoding and Language Information are useful, therefore
157 a simple subset is specified (Section 3.2), and
159 o Language Specifications in Encoded Words aren't needed
160 (Section 3.3).
162 3.1. Parameter Continuations
164 Section 3 of [RFC2231] defines a mechanism that deals with the length
165 limitations that apply to MIME headers. These limitations do not
166 apply to HTTP ([RFC2616], Section 19.4.7).
168 Thus, parameter continuations are not part of the encoding defined by
169 this specification.
171 3.2. Parameter Value Character Encoding and Language Information
173 Section 4 of [RFC2231] specifies how to embed language information
174 into parameter values, and also how to encode non-ASCII characters,
175 dealing with restrictions both in MIME and HTTP header field
176 parameters.
178 However, RFC 2231 does not specify a mandatory-to-implement character
179 encoding, making it hard for senders to decide which encoding to use.
180 Thus, recipients implementing this specification MUST support the
181 "UTF-8" character encoding [RFC3629].
183 Furthermore, RFC 2231 allows the character encoding information to be
184 left out. The encoding defined by this specification does not allow
185 that.
187 3.2.1. Definition
189 The syntax for parameters is defined in Section 3.6 of [RFC2616]
190 (with RFC 2616 implied LWS translated to RFC 5234 LWSP):
192 parameter = attribute LWSP "=" LWSP value
194 attribute = token
195 value = token / quoted-string
197 quoted-string =
198 token =
200 In order to include character encoding and language information, this
201 specification modifies the RFC 2616 grammar to be:
203 parameter = reg-parameter / ext-parameter
205 reg-parameter = parmname LWSP "=" LWSP value
207 ext-parameter = parmname "*" LWSP "=" LWSP ext-value
209 parmname = 1*attr-char
211 ext-value = charset "'" [ language ] "'" value-chars
212 ; like RFC 2231's
213 ; (see [RFC2231], Section 7)
215 charset = "UTF-8" / mime-charset
217 mime-charset = 1*mime-charsetc
218 mime-charsetc = ALPHA / DIGIT
219 / "!" / "#" / "$" / "%" / "&"
220 / "+" / "-" / "^" / "_" / "`"
221 / "{" / "}" / "~"
222 ; as in Section 2.3 of [RFC2978]
223 ; except that the single quote is not included
224 ; SHOULD be registered in the IANA charset registry
226 language =
228 value-chars = *( pct-encoded / attr-char )
230 pct-encoded = "%" HEXDIG HEXDIG
231 ; see [RFC3986], Section 2.1
233 attr-char = ALPHA / DIGIT
234 / "!" / "#" / "$" / "&" / "+" / "-" / "."
235 / "^" / "_" / "`" / "|" / "~"
236 ; token except ( "*" / "'" / "%" )
238 Thus, a parameter is either a regular parameter (reg-parameter), as
239 previously defined in Section 3.6 of [RFC2616], or an extended
240 parameter (ext-parameter).
242 Extended parameters are those where the left-hand side of the
243 assignment ends with an asterisk character.
245 The value part of an extended parameter (ext-value) is a token that
246 consists of three parts: the REQUIRED character encoding name
247 (charset), the OPTIONAL language information (language), and a
248 character sequence representing the actual value (value-chars),
249 separated by single quote characters. Note that both character
250 encoding names and language tags are restricted to the US-ASCII coded
251 character set, and are matched case-insensitively (see [RFC2978],
252 Section 2.3 and [RFC5646], Section 2.1.1).
254 Inside the value part, characters not contained in attr-char are
255 encoded into an octet sequence using the specified character
256 encoding. That octet sequence is then percent-encoded as specified
257 in Section 2.1 of [RFC3986].
259 Producers MUST use the "UTF-8" ([RFC3629]) character encoding.
260 Extension character encodings (mime-charset) are reserved for future
261 use.
263 Note: recipients should be prepared to handle encoding errors,
264 such as malformed or incomplete percent escape sequences, or non-
265 decodable octet sequences, in a robust manner. This specification
266 does not mandate any specific behavior, for instance, the
267 following strategies are all acceptable:
269 * ignoring the parameter,
271 * stripping a non-decodable octet sequence,
273 * substituting a non-decodable octet sequence by a replacement
274 character, such as the Unicode character U+FFFD (Replacement
275 Character).
277 3.2.2. Historical Notes
279 The RFC 2616 token production ([RFC2616], Section 2.2) differs from
280 the production used in RFC 2231 (imported from Section 5.1 of
281 [RFC2045]) in that curly braces ("{" and "}") are excluded. Thus,
282 these two characters are excluded from the attr-char production as
283 well.
285 The ABNF defined here differs from the one in Section
286 2.3 of [RFC2978] in that it does not allow the single quote character
287 (see also RFC Errata ID 1912 [Err1912]). In practice, no character
288 encoding names using that character have been registered at the time
289 of this writing.
291 For backwards compatibility with RFC 2231, the encoding defined by
292 this specification deviates from common parameter syntax in that the
293 quoted-string notation is not allowed. Implementations using generic
294 parser components might not be able to detect the use of quoted-
295 string notation and thus might accept that format, although invalid,
296 as well.
298 [RFC5987] did require support for ISO-8859-1, too; for compatibility
299 with legacy code, recipients are encouraged to support this encoding
300 as well.
302 3.2.3. Examples
304 Non-extended notation, using "token":
306 foo: bar; title=Economy
308 Non-extended notation, using "quoted-string":
310 foo: bar; title="US-$ rates"
312 Extended notation, using the Unicode character U+00A3 (POUND SIGN):
314 foo: bar; title*=utf-8'en'%C2%A3%20rates
316 Note: the Unicode pound sign character U+00A3 was encoded into the
317 octet sequence C2 A3 using the UTF-8 character encoding, then
318 percent-encoded. Also, note that the space character was encoded as
319 %20, as it is not contained in attr-char.
321 Extended notation, using the Unicode characters U+00A3 (POUND SIGN)
322 and U+20AC (EURO SIGN):
324 foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates
326 Note: the Unicode pound sign character U+00A3 was encoded into the
327 octet sequence C2 A3 using the UTF-8 character encoding, then
328 percent-encoded. Likewise, the Unicode euro sign character U+20AC
329 was encoded into the octet sequence E2 82 AC, then percent-encoded.
330 Also note that HEXDIG allows both lowercase and uppercase characters,
331 so recipients must understand both, and that the language information
332 is optional, while the character encoding is not.
334 3.3. Language Specification in Encoded Words
336 Section 5 of [RFC2231] extends the encoding defined in [RFC2047] to
337 also support language specification in encoded words. Although the
338 HTTP/1.1 specification does refer to RFC 2047 ([RFC2616], Section
339 2.2), it's not clear to which header field exactly it applies, and
340 whether it is implemented in practice (see
341 for details).
343 Thus, this specification does not include this feature.
345 4. Guidelines for Usage in HTTP Header Field Definitions
347 Specifications of HTTP header fields that use the extensions defined
348 in Section 3.2 ought to clearly state that. A simple way to achieve
349 this is to normatively reference this specification, and to include
350 the ext-value production into the ABNF for that header field.
352 For instance:
354 foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param
355 title-param = "title" LWSP "=" LWSP value
356 / "title*" LWSP "=" LWSP ext-value
357 ext-value =
359 Note: The Parameter Value Continuation feature defined in Section
360 3 of [RFC2231] makes it impossible to have multiple instances of
361 extended parameters with identical parmname components, as the
362 processing of continuations would become ambiguous. Thus,
363 specifications using this extension are advised to disallow this
364 case for compatibility with RFC 2231.
366 Note: This specification does not automatically assign a new
367 interpretration to parameter names ending in an asterisk. As
368 pointed out above, it's up to the specification for the non-
369 extended parameter to "opt in" to the syntax defined here. That
370 being said, some existing implementations are known to
371 automatically switch to the use of this notation when a parameter
372 name ends with an asterisk, thus using parameter names ending in
373 an asterisk for something else is likely to cause interoperability
374 problems.
376 4.1. When to Use the Extension
378 Section 4.2 of [RFC2277] requires that protocol elements containing
379 human-readable text are able to carry language information. Thus,
380 the ext-value production ought to be always used when the parameter
381 value is of textual nature and its language is known.
383 Furthermore, the extension ought to also be used whenever the
384 parameter value needs to carry characters not present in the US-ASCII
385 ([USASCII]) coded character set (note that it would be unacceptable
386 to define a new parameter that would be restricted to a subset of the
387 Unicode character set).
389 4.2. Error Handling
391 Header field specifications need to define whether multiple instances
392 of parameters with identical parmname components are allowed, and how
393 they should be processed. This specification suggests that a
394 parameter using the extended syntax takes precedence. This would
395 allow producers to use both formats without breaking recipients that
396 do not understand the extended syntax yet.
398 Example:
400 foo: bar; title="EURO exchange rates";
401 title*=utf-8''%e2%82%ac%20exchange%20rates
403 In this case, the sender provides an ASCII version of the title for
404 legacy recipients, but also includes an internationalized version for
405 recipients understanding this specification -- the latter obviously
406 ought to prefer the new syntax over the old one.
408 Note: at the time of this writing, many implementations failed to
409 ignore the form they do not understand, or prioritize the ASCII
410 form although the extended syntax was present.
412 5. Security Considerations
414 The format described in this document makes it possible to transport
415 non-ASCII characters, and thus enables character "spoofing"
416 scenarios, in which a displayed value appears to be something other
417 than it is.
419 Furthermore, there are known attack scenarios relating to decoding
420 UTF-8.
422 See Section 10 of [RFC3629] for more information on both topics.
424 In addition, the extension specified in this document makes it
425 possible to transport multiple language variants for a single
426 parameter, and such use might allow spoofing attacks, where different
427 language versions of the same parameter are not equivalent. Whether
428 this attack is useful as an attack depends on the parameter
429 specified.
431 6. Acknowledgements
433 Thanks to Martin Duerst and Frank Ellermann for help figuring out
434 ABNF details, to Graham Klyne and Alexey Melnikov for general review,
435 to Chris Newman for pointing out an RFC 2231 incompatibility, and to
436 Benjamin Carlyle, Roar Lauritzsen, Eric Lawrence, and James Manger
437 for implementer's feedback.
439 7. References
440 7.1. Normative References
442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
443 Requirement Levels", BCP 14, RFC 2119, March 1997.
445 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
446 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
447 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
449 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
450 Procedures", BCP 19, RFC 2978, October 2000.
452 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
453 10646", STD 63, RFC 3629, November 2003.
455 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
456 "Uniform Resource Identifier (URI): Generic Syntax",
457 STD 66, RFC 3986, January 2005.
459 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
460 Syntax Specifications: ABNF", STD 68, RFC 5234,
461 January 2008.
463 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
464 Identifying Languages", BCP 47, RFC 5646,
465 September 2009.
467 [USASCII] American National Standards Institute, "Coded Character
468 Set -- 7-bit American Standard Code for Information
469 Interchange", ANSI X3.4, 1986.
471 7.2. Informative References
473 [Err1912] RFC Errata, "Errata ID 1912, RFC 2978",
474 .
476 [ISO-8859-1] International Organization for Standardization,
477 "Information technology -- 8-bit single-byte coded
478 graphic character sets -- Part 1: Latin alphabet No.
479 1", ISO/IEC 8859-1:1998, 1998.
481 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
482 Mail Extensions (MIME) Part One: Format of Internet
483 Message Bodies", RFC 2045, November 1996.
485 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
486 Extensions) Part Three: Message Header Extensions for
487 Non-ASCII Text", RFC 2047, November 1996.
489 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
490 Encoded Word Extensions: Character Sets, Languages, and
491 Continuations", RFC 2231, November 1997.
493 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
494 Languages", BCP 18, RFC 2277, January 1998.
496 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
497 form-data", RFC 2388, August 1998.
499 [RFC5987] Reschke, J., "Character Set and Language Encoding for
500 Hypertext Transfer Protocol (HTTP) Header Field
501 Parameters", RFC 5987, August 2010.
503 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
505 [RFC6266] Reschke, J., "Use of the Content-Disposition Header
506 Field in the Hypertext Transfer Protocol (HTTP)",
507 RFC 6266, June 2011.
509 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
510 Internationalization in the IETF", BCP 166, RFC 6365,
511 September 2011.
513 URIs
515 [1]
517 [2]
519 Appendix A. Changes from RFC 5987
521 This section summarizes the changes compared to [RFC5987]:
523 o The document title was changed to "Indicating Character Encoding
524 and Language for HTTP Header Field Parameters".
526 o The requirement to support the "ISO-8859-1" encoding was removed.
528 Appendix B. Implementation Report
530 The encoding defined in this document currently is used for two
531 different HTTP header fields:
533 o "Content-Disposition", defined in [RFC6266], and
535 o "Link", defined in [RFC5988].
537 As the encoding is a profile/clarification of the one defined in
538 [RFC2231] in 1997, many user agents already supported it for use in
539 "Content-Disposition" when [RFC5987] got published.
541 Since the publication of [RFC5987], two more popular desktop user
542 agents have added support for this encoding; see for details.
544 At this time, only one major desktop user agent (Safari) does not
545 support it.
547 Note that the implementation in Internet Explorer 9 does not support
548 the ISO-8859-1 character encoding; this document revision
549 acknowledges that UTF-8 is sufficient for expressing all code points,
550 and removes the requirement to support ISO-8859-1.
552 The "Link" header field, on the other hand, was only recently
553 specified in [RFC5988]. At the time of this writing, no User Agent
554 supported the "title*" parameter, using the encoding defined by this
555 document, but implementation for Firefox was already in progress (see
556 ).
558 Appendix C. Change Log (to be removed by RFC Editor before publication)
560 C.1. Since RFC5987
562 Only editorial changes for the purpose of starting the revision
563 process (obs5987).
565 C.2. Since draft-reschke-rfc5987bis-00
567 Resolved issues "iso-8859-1" and "title" (title simplified). Added
568 and resolved issue "historic5987".
570 C.3. Since draft-reschke-rfc5987bis-01
572 Added issues "httpbis", "parmsyntax", "terminology" and
573 "valuesyntax". Closed issue "impls".
575 C.4. Since draft-reschke-rfc5987bis-02
577 Resolved issue "terminology".
579 C.5. Since draft-reschke-rfc5987bis-03
581 In Section 3.2, pull historical notes into a separate subsection.
582 Resolved issues "valuesyntax" and "parmsyntax".
584 Appendix D. Resolved issues (to be removed by RFC Editor before
585 publication)
587 Issues that were either rejected or resolved in this version of this
588 document.
590 D.1. parmsyntax
592 Type: edit
594
597 James.H.Manger@team.telstra.com (2011-11-02): Noted by James Manger:
598 "Presumably RFC5987 (or its predecessors) decided it was highly
599 unlikely that any parameter names in use ended in "*" (though they
600 are valid) so it could redefine the syntax of values for such names."
601 - add a note that the notation indeed overloads parameter name syntax
602 and clarify the use.
604 Resolution (2011-12-18): Note that this spec doesn't mandate special
605 handling of parameters ending in "*", but also point out that some
606 implemenations assume this, so trailing asterisks should be avoided
607 when not used for this encoding.
609 D.2. valuesyntax
611 Type: edit
613
616 James.H.Manger@team.telstra.com (2011-11-02): Noted by James Manger:
617 "Curiously, RFC5987 disobeys the proposed recommendations for new
618 parameters. It allows foo*=UTF-8''coll%C3%A8gues but not foo*="UTF-
619 8''coll%C3%A8gues" That might be ok with a parser that understands
620 token, quoted-string, and RFC5987, but presumably it will cause
621 problems when RFC5987 processing is done after a "standard httpbis
622 parser" handles the token | quoted-string step. " - add a note
623 clarifying that this is indeed a shortcoming of the format, and what
624 it means for implementations.
626 Resolution (2011-12-18): Added a note describing the problem.
628 Appendix E. Open issues (to be removed by RFC Editor prior to
629 publication)
631 E.1. edit
633 Type: edit
635 julian.reschke@greenbytes.de (2011-04-15): Umbrella issue for
636 editorial fixes/enhancements.
638 E.2. httpbis
640 Type: edit
642 julian.reschke@greenbytes.de (2011-09-17): The document refers
643 normatively to RFC 2616. Should it continue to do so, or should we
644 wait for HTTPbis? This may affect edge case in the ABNF, such as the
645 definition of linear white space or the characters allowed in
646 "token".
648 Author's Address
650 Julian F. Reschke
651 greenbytes GmbH
652 Hafenweg 16
653 Muenster, NW 48155
654 Germany
656 EMail: julian.reschke@greenbytes.de
657 URI: http://greenbytes.de/tech/webdav/