RFC 4256, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", January 2006Source of RFC: secsh (sec)
See Also: RFC 4256 w/ inline errata
Errata ID: 1678
Publication Format(s) : TEXT
Reported By: Frank Cusack
Date Reported: 2009-02-03
Verifier Name: Pasi Eronen
Date Verified: 2009-02-16
Section 3.2 says:
The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. Instead, the server SHOULD select the language used based on the tags communicated during key exchange [SSH-TRANS]. If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent.
It should say:
The language tag MAY be the empty string. If acceptable/preferable languages were communicated during key exchange [SSH-TRANS], or in the SSH_MSG_USERAUTH_REQUEST message, the language tag SHOULD be the language selected by the server for the SSH_MSG_USERAUTH_INFO_REQUEST message.
As originally pointed out by Alfred Hoenes (errata ID 758), this text
was incorrectly copy-pasted from Section 3.1.
The Information Request is sent from the server to the client, and it
already contains strings that make use of the particular
language/locale. The language tag in this message specifies the
language/locale used for building the 'instruction' and 'prompt'
strings in the request. This parallels the use of the language tag
in, e.g., the Disconnection Message of the SSH Transport Layer