Subject: Fwd: I-D Action: draft-reschke-basicauth-enc-03.txt

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jan 2012 17:00:29 +0100

FYI: this is a minor update (adding a note about XHR sometimes using a 
different encoding default). At this point there's nothing left to do 
here except for waiting for feedback; hopefully from implementers. 
Should I try to get it published as is?

-------- Original Message --------
Subject: I-D Action: draft-reschke-basicauth-enc-03.txt
Date: Wed, 25 Jan 2012 07:56:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : An Encoding Parameter for HTTP Basic Authentication
	Author(s)       : Julian F. Reschke
	Filename        : draft-reschke-basicauth-enc-03.txt
	Pages           : 9
	Date            : 2012-01-25

    The "Basic" authentication scheme defined in RFC 2617 does not
    properly define how to treat non-ASCII characters.  This has lead to
    a situation where user agent implementations disagree, and servers
    make different assumptions based on the locales they are running in.
    There is little interoperability for characters in the ISO-8859-1
    character set, and even less interoperability for any characters
    beyond that.

    This document defines a backwards-compatible extension to "Basic",
    specifying the server's character encoding expectation, using a new
    authentication scheme parameter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reschke-basicauth-enc-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-reschke-basicauth-enc-03.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jan 2012 10:58:10 +1300

On 26.01.2012 05:00, Julian Reschke wrote:
> FYI: this is a minor update (adding a note about XHR sometimes using
> a different encoding default). At this point there's nothing left to
> do here except for waiting for feedback; hopefully from implementers.

I have a few questions before going off and looking at implementing :)
(Sorry if I missed a Q about this already.)

In section 3 you say "UTF-8" is to be case-insensitive. The insensitive 
comparison is slower on bytes which need changing.
I assume we should send the exact spec text of upper case (instead of 
the popular de-facto lower-case) as a best practice for highest speed 
and uniformity of implementations?

I assume this is also not limited to WWW-Authenticate:. But applies 
equally to Proxy-Authenticate?

Nit: in appendix A.1 paragraph 2 the word "already" is spread very 
thick on the ground and makes the text seem dated. This is the new text 
right?

And what is the second sentence there trying to convey? that some U-A 
will violate this spec?

"
   Note that some user
    agents already have different defaults depending on whether the
    request originates from page navigation as opposed to a 
script-driven
    request using XMLHttpRequest [XHR].
"
IIRC there was wording sprinkled around various RFCs already calling 
such implementations "old" or similar to deprecate them and hint at the 
text loophole being removed in some future document revision.

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jan 2012 23:09:41 +0100

> and uniformity of implementations?

Dunno. Charsets are usually compared case-insensitively.

> equally to Proxy-Authenticate?

I haven't thought about that, but that seems correct. I'll need to add that.

> Nit: in appendix A.1 paragraph 2 the word "already" is spread very thick
> on the ground and makes the text seem dated. This is the new text right?

Ack. Will rephrase.

> request originates from page navigation as opposed to a script-driven

Well, it's stating a fact that many readers probably don't know, and 
which is relevant to the deployment...

> text loophole being removed in some future document revision.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 26 Jan 2012 03:30:08 +0100

>Should I try to get it published as is?

A note to [email-masked] might be a good idea, at
least in 2006 the list discussed encoding issues like the document
addresses. In fact, let me just try copying it there (and if E-Mail
had a Followup-to header like we had with Netnews, I would not have
to worry about silly crosspost responses...)

>http://www.ietf.org/internet-drafts/draft-reschke-basicauth-enc-03.txt

regards,
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jan 2012 23:08:45 +0100

On 2012-01-25 22:58, Amos Jeffries wrote:
> ...
> ...

Tracked at 
<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.proxy>.

As far as I can tell, the spec doesn't say anything about it. It could 
be used for P-A as well; do we need to clarify that somewhere? If yes, 
where precisely?

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 27 Jan 2012 13:38:03 +1300

> be used for P-A as well; do we need to clarify that somewhere? If yes, 

I was thinking just in the example you have WWW-Authenticate.  If you 
add an example of Proxy-Authenticate next to it its clear that the 
intention is for it to be wherever the Basic auth details are valid 
without having to enumerate all cases or account for future uses.

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Jan 2012 10:12:58 +0100

On 2012-01-27 01:38, Amos Jeffries wrote:
> I was thinking just in the example you have WWW-Authenticate. If you add
> an example of Proxy-Authenticate next to it its clear that the intention
> is for it to be wherever the Basic auth details are valid without having
> to enumerate all cases or account for future uses.

Yes, that sounds good to me.

Best regards, Julian