Re: Message Numbers and Disconnect Codes (fwd)

[nisse%lysator.liu.se@localhost (Niels Möller)]

Chris Lonvick <clonvick%cisco.com@localhost> writes:

> In [CONNECT], we describe the opening of a channel.  This message has the
> format of:
>      byte      SSH_MSG_CHANNEL_OPEN
>      string    channel type in US-ASCII only
>      uint32    sender channel
>      uint32    initial window size
>      uint32    maximum packet size
>      ... channel type specific data follows
> where the 'channel type' "is a name as described in [SSH-ARCH] and
> [SSH-NUMBERS], with similar extension mechanisms."  (Not much to go on
> there.)

I think the intention is fairly clear. Names like "foo%example.com@localhost" can be
defined by whoever owns the "example.com" domain. Names without "@"
in them needs standardization.

> Further in the document, we say, "Many 'channel type' values have
> extensions that are specific to that particular 'channel type'.  An
> example is requesting a pty (pseudo terminal) for an interactive session."

channel types and channel request types are different. But I think the
intention is that they should live in one single name space. So if
"pty-req" is a channel request type, that name should not be reused
for a channel type. And a channel request type like "pty-req" is
intended to imply *one* operation, with *one* format for the
corresponding message.

Currently, the channel type "session" is the only standardized channel
type where "pty-req" make sense.

But it is fully possible to define a new channel type, say
"session-ng%example.com@localhost", where the request type "pty-req" is also
meaningful. It is however *not* approproate to define a new channel
type "session-ng%example.com@localhost", and say that for channels of this type,
"pty-req" has a different unrelated meaning, or that requests of type
"pty-req" should use a different format.

That is my understanding of the spec, do you agree with this? I know
it's technically possible to let "pty-req" have a totally different
meaning and a totally different request format for each channel type
(like we do for the numerical open failure codes), but I don't think
that's how the name space is intended to be used.

> I'll suggest that the mechanism be the IETF CONSENSUS method [RFC
> 2434]

I think "IETF CONSENSUS" is reasonable, since the namespace is for all
practical purposes unlimited, but we still want some level of review
to keep the namespace from cluttering up.

> This is the IANA controlled namespace which, as Jeffrey notes below,
> may contain the "@example.com" extension space if they are defined
> through an appropriate method.

I can make no sense out of this comment. I think the context for
Jeffrey's comment was the allocation of the *numerical* reason codes
in SSH_MSG_CHANNEL_OPEN_FAILURE, where the point was that the
specification for any channel type (no matter if it's standardized or
a local "foo%example.com@localhost" type) can allocate open failure codes from
the "channel-type specific" range in

> > >> > >> 0x0000 0000 - 0xFDFF FFFF        IETF / connection layer
> > >> > >> 0xFE00 0000 - 0xFEFF FFFF        channel-type specific,
> > >> > >> 0xFF00 0000 - 0xFFFF FFFF        private range, used any way

Regards,
/Niels