Subject: Message Numbers and Disconnect Codes

From: Chris Lonvick <[email-masked]>
Date: Thu, 23 Sep 2004 20:16:15 -0700 (PDT)

Hi Folks,

I need to bring this up again.  :)  In the last go-around, I made the
mistake of saying that the Disconnection Codes 'reason code' value was a
byte.  The document clearly states, however, that it is a uint32.  My bad.
Since we agreed that the high 16 values (what we said were going to be
239..254) would be reserved for local use, I'd like to suggest that this
be retained.  This would mean that the values of 0x00000001..0xFFFFFFE9
will be assigned by the IANA and the values of 0xFFFFFFF0..0xFFFFFFFF will
be reserved for local use.

I've also found a couple of more items that need to be listed in
[NUMBERS].  Including the Disconnection Codes we have:

Disconnection Codes                  from Section 11 in [TRANS]
      byte      SSH_MSG_DISCONNECT
      uint32    reason code
      string    description [RFC3629]
      string    language tag [RFC3066]
'reason code' values of 1..15 are assigned

Channel Connection Failure           from Section 5.1 in [CONNECT]
      byte      SSH_MSG_CHANNEL_OPEN_FAILURE
      uint32    recipient channel
      uint32    reason code
      string    additional text
      string    language tag
'reason code' values of 1..4 are assigned

Extended Channel Data Transfer       from Section 5.2 in [CONNECT]
     byte      SSH_MSG_CHANNEL_EXTENDED_DATA
     uint32    recipient_channel
     uint32    data_type_code
     string    data
'data_type_code' 1 is assigned

Unless anyone has a better plan, I'll suggest that the actual codes follow
the same pattern:
  values 0x00000001..0xFFFFFFE9 are assigned by the IANA
  values 0xFFFFFFF0..0xFFFFFFFF are locally assigned.

I'd also like to suggest that we change the name of 'data_type_code' to
'reason code'.  Also for consistency, I'd like to make all of the
additional descriptions become 'description' - and remove 'additional
text' and 'data'.

Are there any objections or comments on these?

Thanks,
Chris

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 23 Sep 2004 22:01:11 -0600

> additional descriptions become 'description' - and remove 'additional

SSH_MSG_CHANNEL_EXTENDED_DATA is dissimilar to the other two... it
is used for sending stderr data.  The data is not a description of
any particular event defined in the protocol, but is whatever
arbitrary data is being sent on stderr.

data_type_code describes the data as being stderr data, and provides
a mechanism for future data types to be used.  (Personally, if I
had it to do all over again, I'd be tempted to skip the data_type_code...)

But regardless, I think changing the name of those two fields would
be bad.

Indeed, however, 'additional text' should be changed to description,
and the same RFC references included on 'description' and on
'language tag' as for disconnect.  (That is another differnece
for EXTENDED_DATA: the data is __not__ UTF8, and there isn't
a language tag.)

As for the ranges, with a 32 bit address space, 16 codes seems
a bit stingy... I'd be tempted to say if the high bit is set
is locally assigned; however, I do not feel strongly about it.

(I can imagine needing more the 16 codes; and i can imagine future
IETF work needing all 256 code points in an 8 bit space... but,
I can't imagine out growing 2 billion codes, nor can I imagine
future IETF work needing more than 2 billion codes.)

- Joseph

---

From: [email-masked] (Niels Möller)
Date: 24 Sep 2004 08:52:05 +0200

> be reserved for local use.

I think it's somewhat silly to reserve only 16 values out of such a
large space. MaF's suggestion, that 0xFF000000-0xFFFFFFFF be reserved
for local use, sounds more reasonable to me.

> 'reason code'.

I don't think that's appropriate, the meaning is quite different. See
below. 

> Also for consistency, I'd like to make all of the

Changing "additional text" to "description" is fine. Changing "data",
in SSH_MSG_CHANNEL_EXTENDED_DATA, is not.

Note that while SSH_MSG_DISCONNECT and SSH_MSG_CHANNEL_OPEN_FAILURE
are reports various protocol related errors,
SSH_MSG_CHANNEL_EXTENDED_DATA is different, it's a segment of a
continous stream of data. SSH_MSG_CHANNEL_EXTENDED_DATA is almost like
the plain SSH_MSG_CHANNEL_DATA, only difference is that it carries one
additional id saying which of potentially many auxillary streams the
data belongs to.

Regards,
/Niels