Re: non-ascii user name & password

>With your proposal, vendor A could build a compliant HTTP client which
>only uses ISO-8859-1 for passwords and vendor B could build a compliant
>HTTP client which only uses UTF-8 for passwords.  Client A and Client B
>don't interoperate if the password contains non-ASCII characters. 
>Therefore the spec would fail the interoperability test and is certainly
>not eligable for draft standard status (and probably not even proposed
>standard status).

No, both would use octets for passwords and if either one does encoding
translation then they may or may not interoperate, depending on how
the user created the password in the first place.

>Forbidding this situation is necessary to make sure all compliant clients

If that were true, they wouldn't interoperate now.  The fact is that
everyone either uses ASCII passwords or continues to use the
same charset for password entry that they used for password creation,
which is not surprising.  None of the servers care about the encoding
of the password characters.  None of the clients do encoding translation.
That is why it works, even if it is sub-optimal.

>P.S. Will the average user realize he has to manually configure the
>"private agreement password charset" in his browser before he can
>authenticate if he uses non-ASCII characters?

It is, by its very nature, the default.  How do you think the average
user will feel about all of his current password-enabled services being
broken just to support a potential mismatch between system charsets?


Received on Thursday, 24 September 1998 15:57:42 UTC