Language negotiation clarification requested

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

The draft-ietf-secsh-transport-15.txt document is under-specified with
respect to how languages are to be negotiated (or even what they are
negotiated for).

I propose a few clarifications:

 - The default language for messages that have missing optional language
   tags should be taken to be the primary language negotiated for the
   direction of the message or, if none was agreed, the first language
   in the sender's language support list.

 - Language tag negotiation during key exchange should be done in such a
   manner that exact matches are preferred, followed by matches by
   language tag prefix (language tags have a primary tag and optional
   sub-tags; "en-GB" has a primary tag "en" and a sub-tag "GB").  Other
   algorithms are possible, but only one should be specified and allowed.

   That is, if one side speaks only "en-GB" and the other only "en-US"
   then the agreed upon language should be "en" and one side should
   treat "en" as an alias of "en-GB" and the other as an alias of
   "en-US" (because, Churchill's witty remark(s) to the contrary
   notwithstanding, the two are close enough for our purposes :)

   The exact algorithm by which a single language set is derived from
   two languages_client_to_server or two languages_server_to_client
   value should be specified because there's currently no other
   way for each side to determine the other's view of the end result of
   language negotiation.  Alternatively the language negotiation should
   be extended with additional messages.  Either way, at the end of the
   negotiation both side have to agree exactly on negotiated languages
   or else we have more trouble defining a default language tag for
   missing optional language tag fields.

   ALTERNATIVELY, language range tags should be permitted in the values
   of languages_client_to_server and languages_server_to_client, but
   then final agreement on at least one supported language depends on
   the willingness of one side to include appropriate language range
   tags in the negotiation.

Additionally, the SSHv2 drafts should reference RFC3066, not RFC1766
(the former obsoletes the latter).  Neither rfc specifies language
tag matching rules such as I describe above.

Cheers,

Nico
--