draft-ietf-httpauth-basicauth-enc-00.txt   draft-ietf-httpauth-basicauth-enc-01.txt 
HTTPAuth Working Group J. Reschke HTTPAuth Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Updates: 2617 (if approved) May 16, 2013 Updates: 2617 (if approved) June 30, 2013
Intended status: Experimental Intended status: Experimental
Expires: November 17, 2013 Expires: January 1, 2014
An Encoding Parameter for HTTP Basic Authentication An Encoding Parameter for HTTP Basic Authentication
draft-ietf-httpauth-basicauth-enc-00 draft-ietf-httpauth-basicauth-enc-01
Abstract Abstract
The "Basic" authentication scheme defined in RFC 2617 does not The "Basic" authentication scheme defined in RFC 2617 does not
properly define how to treat non-ASCII characters. This has lead to properly define how to treat non-ASCII characters. This has led to a
a situation where user agent implementations disagree, and servers situation where user agent implementations disagree, and servers make
make different assumptions based on the locales they are running in. different assumptions based on the locales they are running in.
There is little interoperability for the non-ASCII characters in the There is little interoperability for the non-ASCII characters in the
ISO-8859-1 character set, and even less interoperability for any ISO-8859-1 character repertoire, and even less interoperability for
characters beyond that. any characters beyond that.
This document defines a backwards-compatible extension to "Basic", This document defines a backwards-compatible extension to "Basic",
specifying the server's character encoding expectation, using a new specifying the server's character encoding scheme expectation, using
authentication scheme parameter. a new authentication scheme parameter.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
Discussion of this draft takes place on the HTTPAuth working group Discussion of this draft takes place on the HTTPAuth working group
mailing list (http-auth@ietf.org), which is archived at <http:// mailing list (http-auth@ietf.org), which is archived at <http://
www.ietf.org/mail-archive/web/http-auth/current/maillist.html>. www.ietf.org/mail-archive/web/http-auth/current/maillist.html>.
XML versions, latest edits and the issues list for this document are XML versions, latest edits and the issues list for this document are
available from available from
<http://greenbytes.de/tech/ <http://greenbytes.de/tech/
skipping to change at page 2, line 8 skipping to change at page 2, line 8
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 17, 2013. This Internet-Draft will expire on January 1, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. The 'accept-charset' auth-param . . . . . . . . . . . . . . . 4 3. The 'charset' auth-param . . . . . . . . . . . . . . . . . . . 4
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Deployment Considerations . . . . . . . . . . . . . . 7 Appendix A. Deployment Considerations . . . . . . . . . . . . . . 7
A.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 7 A.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 7
A.1.1. Alternative approach . . . . . . . . . . . . . . . . . 7 A.1.1. Alternative approach . . . . . . . . . . . . . . . . . 7
A.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 8 A.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. FAQ (to be removed by RFC Editor before Appendix B. FAQ (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 8 publication) . . . . . . . . . . . . . . . . . . . . 8
B.1. Why not simply switch the default encoding to UTF-8? . . . 8 B.1. Why not simply switch the default encoding to UTF-8? . . . 8
B.2. What about Digest? . . . . . . . . . . . . . . . . . . . . 8 B.2. What about Digest? . . . . . . . . . . . . . . . . . . . . 8
B.3. Will existing UAs ignore the parameter? . . . . . . . . . 8 B.3. Will existing UAs ignore the parameter? . . . . . . . . . 8
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 8 publication) . . . . . . . . . . . . . . . . . . . . 9
C.1. Since draft-reschke-basicauth-enc-00 . . . . . . . . . . . 8 C.1. Since draft-reschke-basicauth-enc-00 . . . . . . . . . . . 9
C.2. Since draft-reschke-basicauth-enc-01 . . . . . . . . . . . 8 C.2. Since draft-reschke-basicauth-enc-01 . . . . . . . . . . . 9
C.3. Since draft-reschke-basicauth-enc-02 . . . . . . . . . . . 9 C.3. Since draft-reschke-basicauth-enc-02 . . . . . . . . . . . 9
C.4. Since draft-reschke-basicauth-enc-03 . . . . . . . . . . . 9 C.4. Since draft-reschke-basicauth-enc-03 . . . . . . . . . . . 9
C.5. Since draft-reschke-basicauth-enc-04 . . . . . . . . . . . 9 C.5. Since draft-reschke-basicauth-enc-04 . . . . . . . . . . . 9
C.6. Since draft-reschke-basicauth-enc-05 . . . . . . . . . . . 9 C.6. Since draft-reschke-basicauth-enc-05 . . . . . . . . . . . 9
C.7. Since draft-reschke-basicauth-enc-06 . . . . . . . . . . . 9 C.7. Since draft-reschke-basicauth-enc-06 . . . . . . . . . . . 9
C.8. Since draft-reschke-basicauth-enc-07 . . . . . . . . . . . 9 C.8. Since draft-reschke-basicauth-enc-07 . . . . . . . . . . . 9
C.9. Since draft-reschke-basicauth-enc-08 . . . . . . . . . . . 9 C.9. Since draft-reschke-basicauth-enc-08 . . . . . . . . . . . 9
Appendix D. Open issues (to be removed by RFC Editor prior to C.10. Since draft-ietf-httpauth-basicauth-enc-00 . . . . . . . . 9
publication) . . . . . . . . . . . . . . . . . . . . 9 Appendix D. Resolved issues (to be removed by RFC Editor
D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 before publication) . . . . . . . . . . . . . . . . . 10
D.2. unorm . . . . . . . . . . . . . . . . . . . . . . . . . . 9 D.1. terminology . . . . . . . . . . . . . . . . . . . . . . . 10
D.3. terminology . . . . . . . . . . . . . . . . . . . . . . . 10 D.2. parmname2831 . . . . . . . . . . . . . . . . . . . . . . . 10
D.4. parmname2831 . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix E. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 10
E.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
E.2. unorm . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The "Basic" authentication scheme defined in Section 2 of [RFC2617] The "Basic" authentication scheme defined in Section 2 of [RFC2617]
does not properly define how to treat non-ASCII characters does not properly define how to treat non-ASCII characters
([USASCII]): it uses the Base64 ([RFC4648], Section 4) encoding of ([USASCII]): it uses the Base64 ([RFC4648], Section 4) encoding of
the concatenation of username, separator character, and password the concatenation of username, separator character, and password
without stating which character encoding to use. without stating which character encoding scheme to use.
This has lead to a situation where user agent implementations This has led to a situation where user agent implementations
disagree, and servers make different assumptions based on the locales disagree, and servers make different assumptions based on the locales
they are running in. There is little interoperability for the non- they are running in. There is little interoperability for the non-
ASCII characters in the ISO-8859-1 character set ([USASCII], ASCII characters in the ISO-8859-1 character repertoire ([USASCII],
[ISO-8859-1]), and even less interoperability for any characters [ISO-8859-1]), and even less interoperability for any characters
beyond that. beyond that.
This document defines a backwards-compatible extension to "Basic", This document defines a backwards-compatible extension to "Basic",
specifying the server's character encoding expectation, using a new specifying the server's character encoding scheme expectation, using
auth-param for use in the Proxy-Authenticate and WWW-Authenticate a new auth-param for use in the Proxy-Authenticate and WWW-
header fields, as defined in [draft-ietf-httpbis-p7-auth]. Authenticate header fields, as defined in
[draft-ietf-httpbis-p7-auth].
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. The 'accept-charset' auth-param The terms (character) repertoire and character encoding scheme are
defined in Section 2 of [RFC6365].
In challenges, servers MAY use the "accept-charset" authentication 3. The 'charset' auth-param
parameter (case-insensitive) to express the character encoding they
expect the user agent to use. In challenges, servers MAY use the "charset" authentication parameter
(case-insensitive) to indicate the character encoding scheme they
expect the user agent to use when generating "user-pass" (a sequence
of octets) from "userid" and "password" ([RFC2617], Section 2).
The only allowed value is "UTF-8", to be matched case-insensitively The only allowed value is "UTF-8", to be matched case-insensitively
(see [RFC2978], Section 2.3), indicating that the server expects the (see [RFC2978], Section 2.3), indicating that the server expects the
UTF-8 character encoding to be used ([RFC3629]). UTF-8 character encoding scheme to be used ([RFC3629]).
Other values are reserved for future use. Other values are reserved for future use.
Note: The 'accept-charset' parameter cannot be included when Note: The 'charset' parameter cannot be included when sending
sending credentials (e.g. in the Authorization or Proxy- credentials (e.g. in the Authorization or Proxy-Authorization
Authorization header fields), as the "Basic" scheme uses a single header fields), as the "Basic" scheme uses a single token for
token for credentials ('token68' syntax), not a parameter list credentials ('token68' syntax), not a parameter list ('#auth-
('#auth-param' syntax); see Section 2.1 of param' syntax); see Section 2.1 of [draft-ietf-httpbis-p7-auth].
[draft-ietf-httpbis-p7-auth].
4. Examples Note: The name 'charset' has been chosen for consistency with
Section 2.1.1 of [RFC2831]. A better name would have been
'accept-charset', as it is not about the message it appears in,
but the server's expectation.
4. Example
In the example below, the server prompts for authentication in the In the example below, the server prompts for authentication in the
"foo" realm, using Basic authentication, with a preference for the "foo" realm, using Basic authentication, with a preference for the
UTF-8 character encoding: UTF-8 character encoding scheme:
WWW-Authenticate: Basic realm="foo", accept-charset="UTF-8" WWW-Authenticate: Basic realm="foo", charset="UTF-8"
Note that the parameter value can be either a token or a quoted Note that the parameter value can be either a token or a quoted
string; in this case the server chose to use the quoted-string string; in this case the server chose to use the quoted-string
notation. notation.
The user's name is "test", and his password is the string "123" The user's name is "test", and his password is the string "123"
followed by the Unicode character U+00A3 (POUND SIGN). Following followed by the Unicode character U+00A3 (POUND SIGN). Following
Section 1.2 of [RFC2617], but using the character encoding UTF-8, the Section 1.2 of [RFC2617], but using the character encoding scheme
user-pass, converted to a sequence of octets, is: UTF-8, the user-pass, converted to a sequence of octets, is:
't' 'e' 's' 't' ':' '1' '2' '3' pound 't' 'e' 's' 't' ':' '1' '2' '3' pound
74 65 73 74 3A 31 32 33 C2 A3 74 65 73 74 3A 31 32 33 C2 A3
Encoding this octet sequence in Base64 ([RFC4648], Section 4) yields: Encoding this octet sequence in Base64 ([RFC4648], Section 4) yields:
dGVzdDoxMjPCow== dGVzdDoxMjPCow==
Thus the Authorization header field would be: Thus the Authorization header field would be:
skipping to change at page 6, line 7 skipping to change at page 6, line 13
There are no IANA Considerations related to this specification. There are no IANA Considerations related to this specification.
7. Acknowledgements 7. Acknowledgements
The internationalisation problem has been reported as a Mozilla bug The internationalisation problem has been reported as a Mozilla bug
back in the year 2000 (see back in the year 2000 (see
<https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the <https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the
more recent <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>). more recent <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>).
It was Andrew Clover's idea to address it using a new auth-param. It was Andrew Clover's idea to address it using a new auth-param.
Thanks to Bjoern Hoehrmann, Amos Jeffries, James Manger, and Martin Thanks to Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James
Thomson for providing feedback on this document. Manger, Yaron Sheffer, and Martin Thomson for providing feedback on
this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ISO-8859-1] International Organization for [ISO-8859-1] International Organization for
Standardization, "Information Standardization, "Information
technology -- 8-bit single-byte coded technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin graphic character sets -- Part 1: Latin
alphabet No. 1", ISO/IEC 8859-1:1998, alphabet No. 1", ISO/IEC 8859-1:1998,
skipping to change at page 6, line 39 skipping to change at page 6, line 46
Authentication", RFC 2617, June 1999. Authentication", RFC 2617, June 1999.
[RFC2978] Freed, N. and J. Postel, "IANA Charset [RFC2978] Freed, N. and J. Postel, "IANA Charset
Registration Procedures", BCP 19, Registration Procedures", BCP 19,
RFC 2978, October 2000. RFC 2978, October 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation [RFC3629] Yergeau, F., "UTF-8, a transformation
format of ISO 10646", STD 63, RFC 3629, format of ISO 10646", STD 63, RFC 3629,
November 2003. November 2003.
[RFC6365] Hoffman, P. and J. Klensin,
"Terminology Used in
Internationalization in the IETF",
BCP 166, RFC 6365, September 2011.
[USASCII] American National Standards Institute, [USASCII] American National Standards Institute,
"Coded Character Set -- 7-bit American "Coded Character Set -- 7-bit American
Standard Code for Information Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[draft-ietf-httpbis-p7-auth] Fielding, R., Ed. and J. Reschke, Ed., [draft-ietf-httpbis-p7-auth] Fielding, R., Ed. and J. Reschke, Ed.,
"Hypertext Transfer Protocol "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-22 (work in draft-ietf-httpbis-p7-auth-22 (work in
progress), February 2013. progress), February 2013.
8.2. Informative References 8.2. Informative References
[RFC2831] Leach, P. and C. Newman, "Using Digest
Authentication as a SASL Mechanism",
RFC 2831, May 2000.
[RFC4648] Josefsson, S., "The Base16, Base32, and [RFC4648] Josefsson, S., "The Base16, Base32, and
Base64 Data Encodings", RFC 4648, Base64 Data Encodings", RFC 4648,
October 2006. October 2006.
[XHR] Aubourg, J., Song, J., and H. Steen, [XHR] Aubourg, J., Song, J., and H. Steen,
"XMLHttpRequest", W3C Working Draft WD- "XMLHttpRequest", W3C Working Draft WD-
XMLHttpRequest-20121206, December 2012, XMLHttpRequest-20121206, December 2012,
<http://www.w3.org/TR/2012/ <http://www.w3.org/TR/2012/
WD-XMLHttpRequest-20121206/>. WD-XMLHttpRequest-20121206/>.
Latest version available at Latest version available at
<http://www.w3.org/TR/XMLHttpRequest/>. <http://www.w3.org/TR/XMLHttpRequest/>.
Appendix A. Deployment Considerations Appendix A. Deployment Considerations
A.1. User Agents A.1. User Agents
User agents not implementing this specifications should continue to User agents not implementing this specification should continue to
work as before, ignoring the new parameter. work as before, ignoring the new parameter.
User agents which already default to the UTF-8 encoding implement User agents which already default to the UTF-8 encoding implement
this specification by definition. Note that some user agents also this specification by definition. Note that some user agents also
have different defaults depending on whether the request originates have different defaults depending on whether the request originates
from page navigation as opposed to a script-driven request using from page navigation as opposed to a script-driven request using
XMLHttpRequest [XHR]. XMLHttpRequest [XHR].
Other user agents can keep their default behavior, and switch to Other user agents can keep their default behavior, and switch to
UTF-8 when seeing the new parameter. UTF-8 when seeing the new parameter.
A.1.1. Alternative approach A.1.1. Alternative approach
On the other hand, the strategy below may already improve the user- On the other hand, the strategy below may already improve the user-
visible behavior today: visible behavior today:
o In the first authentication request, choose the character encoding o In the first authentication request, choose the character encoding
based on the user's credentials: if they do not need any scheme based on the user's credentials: if they do not need any
characters outside the ISO-8859-1 character set, default to ISO- characters outside the ISO-8859-1 character repertoire, default to
8859-1, otherwise use UTF-8. ISO-8859-1, otherwise use UTF-8.
o If the first attempt failed and the encoding used was ISO-8859-1, o If the first attempt failed and the encoding used was ISO-8859-1,
retry once with UTF-8 encoding instead. retry once with UTF-8 encoding instead.
Note that there's a risk if the site blocks an account after multiple Note that there's a risk if the site blocks an account after multiple
login failures (for instance, when it doesn't reset the counter after login failures (for instance, when it doesn't reset the counter after
a successful login). a successful login).
A.2. Origin Servers A.2. Origin Servers
Origin servers that do not support non-ASCII characters in Origin servers that do not support non-ASCII characters in
credentials do not require any changes. credentials do not require any changes.
Origin servers that need to support non-ASCII characters, but can't Origin servers that need to support non-ASCII characters, but can't
use the UTF-8 encoding will not be affected; they will continue to use the UTF-8 encoding will not be affected; they will continue to
function as well as before. function as well or as badly as before.
Finally, origin servers that need to support non-ASCII characters and Finally, origin servers that need to support non-ASCII characters and
can use the UTF-8 encoding can opt in as described above. In the can use the UTF-8 encoding can opt in as described above. In the
worst case, they'll continue to see either broken credentials or no worst case, they'll continue to see either broken credentials or no
credentials at all (depending on how legacy clients handle characters credentials at all (depending on how legacy clients handle characters
they can not encode). they can not encode).
Appendix B. FAQ (to be removed by RFC Editor before publication) Appendix B. FAQ (to be removed by RFC Editor before publication)
B.1. Why not simply switch the default encoding to UTF-8? B.1. Why not simply switch the default encoding to UTF-8?
There are sites in use today that default to a locale encoding, such There are sites in use today that default to a locale encoding, such
as ISO-8859-1, and expect user agents to use that encoding. These as ISO-8859-1, and expect user agents to use that encoding. These
sites will break if the user agent uses a different encoding, such as sites will break if the user agent uses a different encoding, such as
UTF-8. UTF-8.
B.2. What about Digest? B.2. What about Digest?
Although the solution proposed in this document may be applicable to The Digest scheme has similar issues with respect to
"Digest" as well, any attempt to update this scheme may be an uphill internationalization. The HTTPAuth Working Group is chartered to
battle hard to win. address this problem as well, and the solution might be very similar.
B.3. Will existing UAs ignore the parameter? B.3. Will existing UAs ignore the parameter?
It appears they will. See It appears they will. See
<http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam1> and <http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam1> and
<http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2>. <http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2>.
Appendix C. Change Log (to be removed by RFC Editor before publication) Appendix C. Change Log (to be removed by RFC Editor before publication)
C.1. Since draft-reschke-basicauth-enc-00 C.1. Since draft-reschke-basicauth-enc-00
skipping to change at page 9, line 36 skipping to change at page 9, line 48
C.8. Since draft-reschke-basicauth-enc-07 C.8. Since draft-reschke-basicauth-enc-07
"b64token" -> "token68" (ABNF term changed in HTTPbis P7). Change "b64token" -> "token68" (ABNF term changed in HTTPbis P7). Change
contact information from HTTPbis WG to HTTPAUTH WG. Add issue contact information from HTTPbis WG to HTTPAUTH WG. Add issue
parmname2831. Changed intended status to "experimental". parmname2831. Changed intended status to "experimental".
C.9. Since draft-reschke-basicauth-enc-08 C.9. Since draft-reschke-basicauth-enc-08
Made it a draft of the IETF HTTPauth Working Group. Made it a draft of the IETF HTTPauth Working Group.
Appendix D. Open issues (to be removed by RFC Editor prior to C.10. Since draft-ietf-httpauth-basicauth-enc-00
publication)
D.1. edit
Type: edit Clarify what encoding step the charset selection applies to.
julian.reschke@greenbytes.de (2010-08-11): Umbrella issue for Use RFC 6365 terminology.
editorial fixes/enhancements.
D.2. unorm Rename the parameter to "charset" for consistency with RFC 2831.
Type: edit Appendix D. Resolved issues (to be removed by RFC Editor before
publication)
julian.reschke@greenbytes.de (2012-02-02): We need a statement about Issues that were either rejected or resolved in this version of this
unicode normalization forms. document.
D.3. terminology D.1. terminology
Type: edit Type: edit
julian.reschke@greenbytes.de (2012-02-02): Try to be consistent with julian.reschke@greenbytes.de (2012-02-02): Try to be consistent with
the terminology defined in RFC 6365. the terminology defined in RFC 6365.
D.4. parmname2831 Resolution: Use "character repertoire" and "character encoding
scheme", refer to RFC 6365.
D.2. parmname2831
In Section 3: In Section 3:
Type: change Type: change
julian.reschke@greenbytes.de (2012-05-08): RFC 2831 (Digest SASL julian.reschke@greenbytes.de (2012-05-08): RFC 2831 (Digest SASL
Mechanism) defines a *very* similar parameter but calls it "charset". Mechanism) defines a *very* similar parameter but calls it "charset".
We may want to be consistent with that. We may want to be consistent with that.
Resolution: Be consistent with RFC 2831 and use "charset".
Appendix E. Open issues (to be removed by RFC Editor prior to
publication)
E.1. edit
Type: edit
julian.reschke@greenbytes.de (2010-08-11): Umbrella issue for
editorial fixes/enhancements.
E.2. unorm
Type: edit
julian.reschke@greenbytes.de (2012-02-02): We need a statement about
unicode normalization forms.
Author's Address Author's Address
Julian F. Reschke Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 39 change blocks. 
68 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/