W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: [Ietf-http-auth] Updating RFC 2617 (HTTP Digest) to use UTF-8

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 17 Oct 2006 23:20:34 +0200
Message-Id: <2987F2CC-2716-494B-9D59-902D51A64B43@greenbytes.de>
Cc: Julian Reschke <julian.reschke@gmx.de>, Bjoern Hoehrmann <derhoermi@gmx.net>, ietf-http-wg@w3.org
To: Mark Nottingham <mnot@mnot.net>

Hmm, I am not the greatest spec reader under the sun.

Looking at it from an implementor perspective, I fail to see how  
retroactively non-ascii chars can be *interoperably* fitted into the  
digest specification. If you see a way to do this, I am all for it.  
(It's just so annoying that 401 does not indicate which char of the  
password was wrong.)

What other options are there:

a) It could be clarified which characters in user names, passwords  
and realms can be used for it under which circumstances. An  
implementation having a non-ascii user name/password then at least  
knows which authentication scheme to avoid.

b) The behaviour of some wide-spread implementation could be made  
standard, forcing (or hoping to) the other implementation to follow  
its interpretation.

c) A new auth scheme is specificied which does all unicode chars most  
beautifully. Naming itself "digest-int" or such, so that  
implementations have something to rely on.

d) a mix of all the above. urgs. strike that.

Whatever the choice, it will be a Good Thing if some clarification of  
2616 regarding non-ascii chars in headers is done. Maybe it's already  
there, then some clear words for implementors would suffice. At least  
whoever is trying to fix 2617 has a better base to stand on.



Am 17.10.2006 um 22:29 schrieb Mark Nottingham:

> With the spec - passwd isn't defined as being TEXT, and therefore  
> 2047 encoding (or indeed any charset) isn't specified for it. At  
> least, that's how I read it.
> On 2006/10/17, at 11:56 AM, Julian Reschke wrote:
>> Mark Nottingham schrieb:
>>> ...
>>> If TEXT is well-defined as allowing 2047 encoding, and 2617  
>>> refers to it (albeit indirectly), then in most cases this is just  
>>> an implementation problem, I think. The one exception that I can  
>>> see is:
>>>       passwd   = < user's password >
>>> in Digest.
>>> *sigh*
>>> ...
>> Hm. Maybe I'm a bit slow, but where's the problem here?  
>> Implementations not allowing RFC2047 encoding here, or something  
>> with the spec itself?
>> Best regards, Julian
> --
> Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 17 October 2006 21:21:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:47:10 UTC