The use of "name-list" in the core IDs.

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

I would like to make sure that I've made the right changes to the
documents with respect to "name-lists", as I havn't gotten any responses
back from the ID announcements.  Below is the section from [ARCH] that
details a "name-list".  I made very minor edits from [ARCH]-18 to
[ARCH]-19 for this.  Below that are the pertinent changes to the other
IDs.

=========================================================================
5.  Data Type Representations Used in the SSH Protocols

...skip some...

  name-list

      A string containing a comma-separated list of names.  A name-list
      is represented as a uint32 containing its length (number of bytes
      that follow) followed by a comma-separated list of zero or more
      names.  A name MUST be non-zero length, and it MUST NOT contain a
      comma (",").  Context may impose additional restrictions on the
      names; for example, the names in a name-list may have to be valid
      algorithm identifier (see Section 6 below), or [RFC3066] language
      tags.  The order of the names in a name-list may or may not be
      significant.  Again, this depends on the context where the list is
      used.  Terminating NUL characters are not used; neither for the
      individual names, nor for the list as a whole.

       Examples:

       value                      representation (hex)
       -----                      --------------------
       (), the empty name-list    00 00 00 00
       ("zlib")                   00 00 00 04 7a 6c 69 62
       ("zlib", "none")           00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
=========================================================================


Immediately below is the changed section in [TRANS]-21.  "name-list"
replaces "string" in each of the lines below.  Other things were modified
in this section to reflect the changes from "string" to "name-list".  (I
have a typo in [TRANS]-21:  s/listis/lists/  .)
=========================================================================
7.  Key Exchange

   Key exchange (kex) begins by each side sending name-lists of
   supported algorithms.  Each side has a preferred algorithm in each
   category, and it is assumed that most implementations at any given
   time will use the same preferred algorithm.  Each side MAY guess
   which algorithm the other side is using, and MAY send an initial key
   exchange packet according to the algorithm if appropriate for the
   preferred method.

...some skipped...

7.1  Algorithm Negotiation

   Key exchange begins by each side sending the following packet:

     byte         SSH_MSG_KEXINIT
     byte[16]     cookie (random bytes)
     name-list    kex_algorithms
     name-list    server_host_key_algorithms
     name-list    encryption_algorithms_client_to_server
     name-list    encryption_algorithms_server_to_client
     name-list    mac_algorithms_client_to_server
     name-list    mac_algorithms_server_to_client
     name-list    compression_algorithms_client_to_server
     name-list    compression_algorithms_server_to_client
     name-list    languages_client_to_server
     name-list    languages_server_to_client
     boolean      first_kex_packet_follows
     uint32       0 (reserved for future extension)
=========================================================================


Immediately below is the changed section in [AUTH]-24.
=========================================================================
5.1  Responses to Authentication Requests

   If the server rejects the authentication request, it MUST respond
   with the following:

     byte         SSH_MSG_USERAUTH_FAILURE
     name-list    authentications that can continue
     boolean      partial success

   The 'authentications that can continue' is a comma-separated
   name-list of authentication 'method name' values that may
   productively continue the authentication dialog.

   It is RECOMMENDED that servers only include those 'method name'
   values in the name-list that are actually useful.  However, it is not
   illegal to include 'method name' values that cannot be used to
   authenticate the user.

   Already successfully completed authentications SHOULD NOT be included
   in the name-list, unless they really should be performed again for
   some reason.
=========================================================================


All of these changes (and more :) can be found here:
  http://www.employees.org/~lonvick/secsh-wg/2004-nov-29/


Can I get either an "Amen!" for these changes, or some guidance on getting
them aligned with reality?

Thanks,
Chris