Re: UTF8

[Derek Fawcus <dfawcus%cisco.com@localhost>]

On Tue, Jan 18, 2005 at 10:13:55PM -0500, der Mouse wrote:
> What I think we do have consensus on, even if only consensus by apathy,
> is that this issue can be ignored; I appear to be the only person the
> least bit concerned about it.

I guess.  I happen to agree with your position to a large extent,  in
that I use unix systems which are using 8859-1 (from my POV).

But then since I happen to really only use the ASCII compatible part,
if it's an octet string or UTF-8 becomes irrelevant.  I don't have any
characters outside the ASCII range in usernames or passwords.

So it becomes academic.  The only other argument would probably be that
the original implementations (for unix I believe) would have been using
octet strings,  despite anything to the contrary in the spec.

Rather than have a new message defined now,  we could simply define a
new error code which mean 'need octet string input'.  Then on unix
machines,  if either the username or password contained octets with
values >= 128 this error could be returned.

Then in a new draft define new messages and a new error.  These being the
authentication forms with explicit interpretation as octet strings.
The error could be used to indicate 'need utf-8 string input' in case
some client way configured to start with the octet form.  An alternate
is simply a client -> server message meaning subsequent auth messages
are octet strings.  This would require client side config/choice to
send on a per server basis.

Mind,  the approach of having configuration (at the client) to say what
the server charset is,  seems simpler.  In which case the client would
convert to the proper octet string,  then just send the existing messages
but treating the fields as if they were defined as octets - i.e. possible
sequence which would be bad if interpreted as utf-8.

DF