- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Tue, 17 Oct 2006 23:20:34 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Bjoern Hoehrmann <derhoermi@gmx.net>, ietf-http-wg@w3.org
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. Cheers, Stefan 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