Re: Message Numbers and Disconnect Codes (fwd)

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

Hi Niels,

On Tue, 12 Oct 2004, [iso-8859-1] Niels Möller wrote:

> Chris Lonvick <clonvick%cisco.com@localhost> writes:
>
> Sorry, but I still find this utterly confusing.
>
> > I was saying that the IANA can control values for 'channel type' of
>                                          ^^^^^^
> > "session" and even "session%example.com@localhost", as long as "session%example.com@localhost"
> > is registered with the IANA through an RFC - even an Informational RFC.
>
> Exactly what "values" are you talking about here?

I'd like to try to clarify the "parameter" from the 'value' that fills the
"parameter" in the packet in the documents.  Currently, there are places
where the characters of ` and ' set off the 'values', and in other places,
nothing sets off the values.  I'd like to make that consistent throughout
the documents.  Do these examples work:

-------current text in [CONNECT]--------
   There are several kinds of requests that affect the state of the
   remote end "globally", independent of any channels.  An example is a
   request to start TCP/IP forwarding for a specific port.  All such
   requests use the following format.

     byte      SSH_MSG_GLOBAL_REQUEST
     string    request name in US-ASCII only
     boolean   want reply
     ... request-specific data follows

   Request names follow the DNS extensibility naming convention outlined
   in [SSH-ARCH].
----------------------------------------
"Request names" in the last sentence is not distinguished.

-------proposed text in [CONNECT]-------
   There are several kinds of requests that affect the state of the
   remote end globally, independent of any channels.  An example is a
   request to start TCP/IP forwarding for a specific port.  All such
   requests use the following format.

     byte      SSH_MSG_GLOBAL_REQUEST
     string    request name in US-ASCII only
     boolean   want reply
     ... request-specific data follows

   The value of 'request name' follows the DNS extensibility naming
   convention outlined in [SSH-ARCH].
------------------------------------------
'request name' is denoted as a parameter.


In another place:
-------current text in [CONNECT]--------
   If want reply is FALSE, no response will be sent to the request.
   Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS
   or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation
   messages.  If the request is not recognized or is not supported for
   the channel, SSH_MSG_CHANNEL_FAILURE is returned.
----------------------------------------
I first thought that the first sentence was a grammatical error. :)

-------proposed text in [CONNECT]-------
   If 'want reply' is FALSE, no response will be sent to the request.
   Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS
   or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation
   messages.  If the request is not recognized or is not supported for
   the channel, SSH_MSG_CHANNEL_FAILURE is returned.
----------------------------------------
This qualifies 'want reply' as a parameter.

Does this clarify things?  Does anyone have a better suggestion?


>
>  1. Channel type id:s, example: "session"?

Yes.  The values are in the left-hand column in the table in Section
4.2.2.1 in [NUMBERS]-06.  They are "session", "x11", "forwarded-tcpip",
and "direct-tcpip".

>
>  2. Channel request type id:s, example: "pty-req"?

Yes.  Section 4.2.2.3 in [NUMBERS]-06.

>
>  3. Channel open failure reason codes in the "IETF / connection layer"
>     range (0x0000 0000 - 0xFDFF FFFF), example: 0x0000 0001?

Yes.  This will be included in the next set of IDs.

>
>  4. Channel open failure reason codes in the "channel-type specific"
>     range (0xFE00 0000 - 0xFEFF FFFF), example: 0xFE00 0017?

Yes.  This will be included in the next set of IDs.

>
> None of the alternatives make much sense to me (in particular, any
> IANA registration of the id "session%example.com@localhost" seems absurd), but
> I'd like to know exactly which values you are talking about before I
> write more about it.

Sorry.  I took my finger off of the statement in [ARCH] where we say that
names that contain the "@" character will not be registered with the IANA;
Section 6 in [ARCH]-16 and in various places in [NUMBERS]-06.  (Which is
why I ask for clarification. :)


>
> > From that:
> >
> > > > >> > >> 0x0000 0000 - 0xFDFF FFFF        IETF / connection layer
> > "session" and "foo%example.com@localhost" get to use this range (as long as any
> > 'reason code' values have been registered with the IANA through an RFC
> > action).

Change that.  It should be
     0x0000 0000 - 0xFDFF FFFF        IETF / connection layer
     "session" and the other values will use this range as long as they
     are registered with the IANA through an RFC action.


>
> Ok, I only have one clarification: These reason codes should have a
> meaning that is reasonably independent of any particular channel-type.
> Ideally, the definition of any code in this range should not refer to
> any particular channel type, except possibly for examples. Currently
> defined values have this character, including SSH_OPEN_CONNECT_FAILED,
> which is applicable to all the channel types which perform some kind
> of forwarding.

OK.  That should just be a few sentences in the appropriate places.  Does
anyone disagree with this?

>
> > > > >> > >> 0xFE00 0000 - 0xFEFF FFFF        channel-type specific,
> > "bar%example.com@localhost" gets to use this range.  Others may choose to also use
> > "bar%example.com@localhost" and honor the associated codes.  These are not
> > registered with the IANA.
>
> Ok. Values in this range are defined in the specification for the
> corresponding channel type.
>
> > > > >> > >> 0xFF00 0000 - 0xFFFF FFFF        private range, used any way
> > No one cares what is used in this range and it will not be honored by
> > others.  There's also nothing to register with the IANA.
>
> Ok.
>
> Regards,
> /Niels
>

Thanks,
Chris