Re: Publickey subsystem draft posted

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

> > While I support the intent of this the functionality seems like it would
> > actually be more appropriate for one of the core drafts rather than this one.
> 
> It seems to me that the core drafts are pretty well closed up at this point.
> I'm not sure yet if I understand completely why some language like this
> would be inappropriate in this document. I'd be happy to see it changed
> to "MAY provide a configuration option...". I could also see rephrasing it
> to not specifically mention password authentication. Otherwise this 
> seems pretty innocuous.

there is no strong requirement that the document boundaries exactly
match the implementation boundaries.  as a quality of implementation
issue it seems like the "disable password once a public key is
registered" should be enforced on a user-by-user basis (some users may
haev a need to be able use passwords even when a public key is
present) which suggests to me that the feature description touches
both parts and could end up in either place...

> > I'd like to see text added to say that the server is not supposed to
> > interpret the comment in any way and is NOT required to preserve it for
> > subsequent return in a list command.
> 
> Sounds good. But, I do think it would be nice to have a statement
> that indicates that returning the comment in a list would be helpful
> to users trying to distinguish keys from each other in a listing
> (other than by looking at fingerprints).

[wg chair hat off..]

For what it's worth, the management UI guy who sits next to me really
seems to like this sort of thing and i'm inclined to take his word for
it.  However, as long-lived user-visible text, you've just invoked the
full complexity of I18N:

    All user-visible text fields must be internationalizable
    See RFC 2277. For most cases, this means UTF-8.
    If text fields are included in some calculation, like matching,
    sorting etc, it must be described in detail how those operations are
    applied to the Unicode/ISO 10646 character set. see "stringprep" for
    more information on the recommended way of handling comparisons.

I think the case we want to worry about is -- what happens when you
get a client from mars which registers a key with a comment in
martian, then a client from venus connects to the same account and
registers a comment in venusian.. you need to tag each comment with an
appropriate language:

quoting from 2277:

   Protocols that transfer text MUST provide for carrying information
   about the language of that text.

   Protocols SHOULD also provide for carrying information about the
   language of names, where appropriate.

   Note that this does NOT mean that such information must always be
   present; the requirement is that if the sender of information
   wishes to send information about the language of a text, the protocol
   provides a well-defined way to carry this information.

					- Bill