Re: New drafts

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> In assignednumbers-07, 4.2.3, what about reason codes from ffffffea
>> through ffffffef?  Similar remarks apply to 4.3.3 and 4.4.3.
> I [...] hadn't realized that I had not completed my edits [...]
> Just to summarize the discussion, I am planning on the following:

Good.  I thought it was odd to entirely omit six of the 2^32 possible
values; I also thought it didn't look much like the consensus I
remembered from the list.  Your description of what you're planning
looks much better on both counts. :)

>> userauth-22 contains (in the description of password authentication)
>> more character set issues, similar to those raised by the recent
>> discussion of filenames.
> Was that the discussion with the subject line of "SFTP and unicode
> file names..."?  I wasn't paying close attention to that.

I think that was it.

> Is that this paragraph:

>    Note that the 'plaintext password' value is encoded in ISO-10646
>    UTF-8.  It is up to the server how it interprets [...]

Yes.

> If so, would anyone care to propose text as to how it can address
> this issue?

I don't have a good fix.  Basically, the problem is that passwords (or
filenames, for the sftp issue) are, on some systems, octet sequences,
with conversion between them and character sequences happening only
when they need to be displayed or typed; whereas, on others, they are
character sequences, with octet sequences involved only because of the
need to store some representation of those character sequences.  From
the one point of view, character set conversion in the protocol is
complete nonsense; from the other, it's reasonable even to the point of
being necessary.  Short of providing a character set tag field for
which some distinguished value means "this is actually an octet
sequence", I see no way to handle both with the same protocol.

For example, on the system I'm using right now, passwords and filenames
_are_ fundamentally octet sequences rather than character sequences.
Given the edict

>    However, if the client reads the password in some other encoding
>    (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the password to
>    ISO-10646 UTF-8 before transmitting,

then what should I do upon reading a password?  I _don't know_, and in
many cases finding out is not just difficult but impossible, what
character set is being used for display; what characters the user is
thinking of those octets, or the keystrokes behind them (if any), as
corresponding to is even more difficult to determine.

>    and the server MUST convert the password to the encoding used on
>    that system for passwords.

This appears to say that in order to implement password authentication
in my server, I have to redesign and reimplement how passwords are
handled and stored to make them character sequences rather than octet
sequences.  Is that really what we want the drafts to require?  I for
one would much rather simply not implement password authentication.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B