Re: non-ascii user name & password

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

		- 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