- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Thu, 24 Sep 1998 15:50:31 -0700
- To: Chris Newman <Chris.Newman@innosoft.com>
- Cc: http-wg@hplb.hpl.hp.com
>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 >interoperate. 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? ....Roy
Received on Thursday, 24 September 1998 15:57:42 UTC