IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Open Issues from Recent Comments



Hi,

On Wed, 12 Jan 2005, [iso-8859-1] Niels Möller wrote:

> Chris Lonvick <clonvick%cisco.com@localhost> writes:
>
> > 4)  SSH_DISCONNECT_* descriptions
>
> ...
>
> > Proposed Resolution:  Can I get some feedback on this?  I was under the
> > assumption that the "descriptions" are the standardized text to send in
> > the "description" field.  I too felt that was a bit redundant but figured
> > that it was setting the precendence for the descriptions associated with
> > local namespaces.  What's the right thing to do here?
>
> The description is an arbitrary human readably strings describing the
> reason for the disconnection in some more detail. The text in will
> usually end up on the users terminal or in the servers log file
> (perhaps only when running in verbose mode).
>
> I think the text in draft-ietf-secsh-transport-22.txt is ok, it's just
> the table header that must be changed, to something like
>
>    Reason code   Symbolic name
>    1             SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT
>
> Or actually, the table is duplicated in NUMBERS, section 4.2.2, so
> perhaps it could be deleted all together.

Got it.  I'm assuming that this will then also apply to
SSH_EXTENDED_DATA_STDERR in [CONNECT] ("data" as the table header will
become "Symbolic name"), and the SSH_MSG_CHANNEL_OPEN_FAILURE table also
in [CONNECT].  Let me know if anyone disagrees with this.

>
> It would be desirable with a table describing under what circumstances
> each value should be used, but perhaps we can live without that. Most,
> but not all, of the symbolic names are self-explanatory.

If we can't come to consensus on UTF8, I'll have plenty of time to work on
that.  :(

Thanks,
Chris



Home | Main Index | Thread Index | Old Index