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.
| 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 |
| 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. |
| Version | Issues |
|---|---|
| latest | |||||||||| |
| 07 | |||||||||| |
| 06 | |||||||||| |
| 05 | |||||||||| |
| 04 | |||||||||| |
| 03 | |||||||||| |
| 02 | |||||||||| |
| 01 | |||||| |
| 00 | |||| |
Last change: 2011-12-18