Re: Message Numbers and Disconnect Codes

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

Chris Lonvick wrote:
> 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'.

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