An Encoding Parameter for HTTP Basic Authentication

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, 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

Closed/Editor Issues

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.

Progress

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

Last change: 2012-05-08