global and channel requests -- more information on failure, more flexibility on success

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

Regarding global and channel requests... I believe more
information on failure and more flexibility on success
is needed.

- In the connection draft, section 2, we should change

     byte      SSH_MSG_REQUEST_SUCCESS

  to

     byte      SSH_MSG_REQUEST_SUCCESS
     string    request-name
     ... request-specific data follows

  All current requests (unless otherwise specified) have no
  request specific data.

  If existing implementations won't safely ignore the extra
  packet data, we should change the packet number and
  deprecate the existing one.

- In the connection draft, section 2, we should change

    byte      SSH_MSG_REQUEST_FAILURE


  to

    byte      SSH_MSG_REQUEST_FAILURE
    string    request-name
    uint32    reason
    string    additional text (UTF-8)
    string    language

    where reason is one of

    ADMIN_PROHIBITED = 0
    UNKNOWN_UNSUPPORTED = 1
    RESOURCE_SHORTAGE = 2
    GENERAL_FAILURE = 3

  I think existing implementations should simply ignore the
  extra data.  If not, we should give this code a new value,
  i.e., SSH_MSG_REQUEST_FAILURE2, and deprecate the old
  message.

- If global requests are issued asynchronously (is this allowed?)
  are there any guarantees for order of completion?  Do we need
  to be able to tag requests?

- In the connection draft, section 3.4, we should change

     byte      SSH_MSG_CHANNEL_SUCCESS
     uint32    recipient_channel

  to

     byte      SSH_MSG_CHANNEL_SUCCESS
     uint32    recipient_channel
     string    request-name
     ...request specific data

  If existing implementations won't safely ignore the extra
  packet data, we should change the packet number and
  deprecate the existing one.

- In the connection draft, section 3.4, we should change

     byte      SSH_MSG_CHANNEL_FAILURE
     uint32    recipient_channel


  to

     byte      SSH_MSG_CHANNEL_FAILURE
     uint32    recipient_channel
     string    request-name
     uint32    reason
     string    addition descriptive text (UTF8)
     string    language

  Again, I believe current implementations should discard
  the extra data at the end of the packet -- if not, we
  should change the message number and deprecate this
  existing message.

- In the connection draft, section 3.4, we explicitly
  allow requests to be sent without waiting for completion.

  Are there any ordering guarantees?

  Do we need to tag the requests so responses can be
  associated with specific requests?

Joseph Galbraith
galb-list%vandyke.com@localhost