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, 2010-08-11: Umbrella issue for editorial fixes/enhancements. | latest change in revision 08 |
| parmname2831 |
change open |
julian.reschke@greenbytes.de, 2012-05-08: RFC 2831 (Digest SASL Mechanism) defines a *very* similar parameter but calls it "charset". We may want to be consistent with that. | latest change in revision 08 |
| terminology |
edit open |
julian.reschke@greenbytes.de, 2012-02-02: Try to be consistent with the terminology defined in RFC 6365. | latest change in revision 08 |
| unorm |
edit open |
julian.reschke@greenbytes.de, 2012-02-02: We need a statement about unicode normalization forms. | latest change in revision 08 |
| Identifier | Type / Status | Reference and Description | Resolution / Latest Change |
|---|---|---|---|
| credparam |
change closed |
julian.reschke@greenbytes.de, 2010-08-12: Should "encoding" also be defined for the credentials (the UA's response)? | in revision 01: Disallow (but reserve) encoding in credentials, and explain why this is the case. |
| paramcase |
change closed |
julian.reschke@greenbytes.de, 2010-08-12: Are auth param names case-sensitive? | in revision 01: Be consistent with "realm" (case-insensitive). Note that should be clarified in RFC2617bis for auth params in general. |
| paramname |
change closed |
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0302.html> derhoermi@gmx.net, 2012-01-30: ... (in part due to the name, `useUTF8` or `use-utf-8="yes" or some such would have been clearer) |
in revision 05: Switch to "accept-charset", so this is similar to the HTML form attribute. |
| proxy |
change closed |
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0159.html> squid3@treenet.co.nz, 2012-01-26: I assume this is also not limited to WWW-Authenticate:. But applies equally to Proxy-Authenticate? |
in revision 04: Add matching example for Proxy-Authenticate. |
| sentparam |
change closed |
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0299.html> James.H.Manger@team.telstra.com, 2011-01-30: The text about not including the 'encoding' parameter when sending the password is a bit confusing [section 3]. (...) My guess is that the spec intended to say that including the encoding information *would* be useful, but it cannot be added easily. This is a good illustration of the 3rd dot point from "2.3.1 Considerations for new Authentication Schemes" [draft-ietf-httpbis-p7-auth-18#section-2.3.1]: "b64token ... can only be used once ... future extensions will be impossible". |
in revision 05: Done. |
| Version | Issues |
|---|---|
| latest | ||||||||| |
| 08 | ||||||||| |
| 07 | |||||||| |
| 06 | |||||||| |
| 05 | |||||||| |
| 04 | |||| |
| 03 | ||| |
| 02 | ||| |
| 01 | ||| |
| 00 |
Last change: 2012-05-08