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