Re: UTF8

[Alan Barrett <apb%cequrux.com@localhost>]

On Thu, 20 Jan 2005, der Mouse wrote:
> For that user, it is.  Another user of the same system may be of Greek
> extraction and use 8859-7, with username, say, 0xec 0xe1 0xf1 0xea (mu
> alpha rho kappa, which I can't insert directly because this message is
> in 8859-1, and I'd rather not mess around with trying to create a
> multipart/mixed message).  And what's wrong with that?

Even if the underlying operating system thinks that the user name
is

	OCTET_SEQUENCE(0xec, 0xe1, 0xf1, 0xea),

the user probably thinks that the user name is

	CHARACTER_STRING(<greek small letter mu>, <greek small letter alpha>,
		<greek small letter rho>, <greek small letter kappa>).

and perhaps the sysadmin thinks that the user name is

	ENCODE_USING_CHARSET(iso-8859-7, CHARACTER_STRING(...)).

I see no reason why the ssh server implementation could not have a
set of rules or a database to tell it things like "The user whose
username is really OCTET_SEQUENCE(x) likes to think that his user name
is CHARACTER_STRING(y)", or "All users on this system like to think that
their usernames are character strings encoded in CHARSET(z)".  Then,
when CHARACTER_STRING(y) arrives in the relevant ssh protocol field, the
server could map it to the correct OCTET_SEQUENCE(x).  Users who really
do think of their user names as octet sequences can be handled by having
an rule to say "The user whose username is really OCTET_SEQUENCE(0x01,
0x02) will login via ssh using the name CHARACTER_STRING(<digit zero>,
<latin small letter x>, <digit zero>, <digit one>, <digit zero>, <digit
two>)".

So, the fact that the ssh protocol wants to use a character string does
not appear to prevent an implementation that wants to use an octet
sequence.

--apb (Alan Barrett)