Indicating Character Encoding and Language for HTTP Header Field Parameters

Glossary

The identifier is a name for the issue (and is unique within this document).

The type of issue is one of:

The status of the issue is one of:

The reference is an indication of where the issue was first raised.

The description is a succinct overview of the issue.

The resolution describes the specification change that resolves the issue.

Open Issues

Identifier Type / Status Reference and Description Proposed Resolution / Latest Change
edit
edit
open
julian.reschke@greenbytes.de, 2011-04-15: Umbrella issue for editorial fixes/enhancements. latest change in revision latest
httpbis
edit
open
julian.reschke@greenbytes.de, 2011-09-17: The document refers normatively to RFC 2616. Should it continue to do so, or should we wait for HTTPbis? This may affect edge case in the ABNF, such as the definition of linear white space or the characters allowed in "token". latest change in revision latest

Closed/Editor Issues

Identifier Type / Status Reference and Description Resolution / Latest Change
historic5987
change
closed
julian.reschke@greenbytes.de, 2011-09-08: Point out that RFC 5987 should be moved to "historic". in revision 01:
Done.
impls
change
closed
julian.reschke@greenbytes.de, 2011-04-15: Add implementation report. in revision 02:
iso-­8859-­1
change
closed
julian.reschke@greenbytes.de, 2011-04-15: Remove requirement to support ISO-8859-1? It doesn't really help, and it is not implemented in IE9. in revision 01:
Removed requirement; adjusted examples; explain that RFC 5987 required this so recipients may want to support it anyway.
obs5987
change
closed
julian.reschke@greenbytes.de, 2011-04-15: Obsolete RFC 5987, summarize differences. in revision 00:
parmsyntax
edit
closed
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0159.html>

James.H.Manger@team.telstra.com, 2011-11-02: Noted by James Manger: "Presumably RFC5987 (or its predecessors) decided it was highly unlikely that any parameter names in use ended in "*" (though they are valid) so it could redefine the syntax of values for such names." - add a note that the notation indeed overloads parameter name syntax and clarify the use.
in revision 04:
Note that this spec doesn't mandate special handling of parameters ending in "*", but also point out that some implemenations assume this, so trailing asterisks should be avoided when not used for this encoding.
terminology
edit
closed
julian.reschke@greenbytes.de, 2011-09-17: Try to be consistent with the terminology defined in RFC 6365. in revision 03:
Done (but abbreviating "character encoding scheme" to "character encoding").
title
edit
closed
duerst@it.aoyama.ac.jp, 2011-04-17: Proposed title: "Indicating Character Encoding and Language for HTTP Header Field Parameters" in revision 01:
Done.
valuesyntax
edit
closed
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0159.html>

James.H.Manger@team.telstra.com, 2011-11-02: Noted by James Manger: "Curiously, RFC5987 disobeys the proposed recommendations for new parameters. It allows foo*=UTF-8''coll%C3%A8gues but not foo*="UTF-8''coll%C3%A8gues" That might be ok with a parser that understands token, quoted-string, and RFC5987, but presumably it will cause problems when RFC5987 processing is done after a "standard httpbis parser" handles the token | quoted-string step. " - add a note clarifying that this is indeed a shortcoming of the format, and what it means for implementations.
in revision 04:
Added a note describing the problem.

Progress

Version Issues
latest ||||||||||
06 ||||||||||
05 ||||||||||
04 ||||||||||
03 ||||||||||
02 ||||||||||
01 ||||||
00 ||||

Last change: 2011-12-18