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

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

Received on Tuesday, 17 October 2006 21:21:01 UTC