- From: Chris Newman <Chris.Newman@innosoft.com>
- Date: Thu, 24 Sep 1998 23:10:21 +0100 (BST)
- To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
- Cc: http-wg@hplb.hpl.hp.com
On Thu, 24 Sep 1998, Roy T. Fielding wrote: > That would invalidate almost all client implementations of HTTP. > There is no technical reason to define the encoding other than to > say it is a shared understanding between client and server that > is outside the capacity of the protocol to determine, and that > interoperability problems may occur if non-US-ASCII characters > are used. Forbidding it just makes the specification worthless. I emphatically disagree. 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). Forbidding this situation is necessary to make sure all compliant clients interoperate. - Chris 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?
Received on Thursday, 24 September 1998 15:10:05 UTC