Hi, At the risk of wading into a discussion that I haven't followed closely: the SSH protocol does include a language negotiation mechanism that allows the server and client to agree on a language at KEXINIT time. Per RFC4253 section 7.1 > languages > This is a name-list of language tags in order of preference > [RFC3066]. Both parties MAY ignore this name-list. If there > are no language preferences, this name-list SHOULD be empty as > defined in Section 5 of [SSH-ARCH]. Language tags SHOULD NOT > be present unless they are known to be needed by the sending > party. Very few implementations have ever used this (maybe SunSSH did once?) and OpenSSH doesn't attempt language negotiation at all. It might be possible to work this protocol feature up to a proposal for how it could be practically used to the problems mentioned in this thread. Most of the OpenSSH developers lack the expertise needed to do this, so if it ever happens then it will probably need to come from the community. IMO preparing an internet-draft would be a good way for someone interested to start this conversation, since you'll want a standards document at the end of the process to convince implementators to adopt it. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
