Re: Message Numbers and Disconnect Codes (fwd)

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

Hi,

I'm working-in the text for this and need some clarification.

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.)

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."

And still further in the document, we define "pty-req" as a specific
'channel type'.  As it is, we need to have the IANA set up a registry for
'channel type' values with the only current entry being "pty-req".  We
also need to tell the IANA that additional 'channel type' values may be
added through some mechanism.  I'll suggest that the mechanism be the IETF
CONSENSUS method [RFC 2434] but plese let me know if it should be "FIRST
COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", or "STANDARDS ACTION".  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.  Having the
method be IETF CONSENSUS allows an Informational RFC to add an entry to
the IANA Registry.

Most importantly, are there any other 'channel type' values that need to
be defined in this initial registry?

Thanks,
Chris

On Mon, 27 Sep 2004, Jeffrey Hutzelman wrote:

>
>
> On Monday, September 27, 2004 13:45:59 +0200 Niels Möller
> <nisse%lysator.liu.se@localhost> wrote:
>
> > Chris Lonvick <clonvick%cisco.com@localhost> writes:
> >
> >> > >> 0x0000 0000 - 0xFDFF FFFF        IETF / connection layer
> >> > >> 0xFE00 0000 - 0xFEFF FFFF        channel-type specific,
> >> > >> 0xFF00 0000 - 0xFFFF FFFF        private range, used any way
> >
> >> Are there any objections to this allocation scheme?  If not, I'll use it
> >> for the Disconnection Code 'reason code's and as the model for other
> >> uint32 ranges.
> >
> > Note that the above scheme is applicable only to the reason codes in
> > SSH_MSG_CHANNEL_OPEN_FAILURE.
>
> Right; the channel-type-specific range makes sense only for messages which
> occur in the context of a particular channel.  Global mesasges like
> SSH_MSG_DISCONNECT cannot be associated with any particular channel, and
> should not define this range.
>
>
> Note that there is no reason to restrict the use of the 0xFE range to
> privately-defined channel types.  It is IMHO entirely reasonable for a
> standards-track channel type to defined a channel-type-specifc code.  Such
> a code would be specified in the document defining the channel type and
> would be drawn from the 0xFE range, without regard to use of codes in that
> range by other channel types.
>
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
>
>