IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: WG Chair Copyediting for draft-ietf-secsh-break-02
> The ssh(d) module may can't control it, but some other piece of the
> system (serial chipset, device driver, serial i/o subsystem, etc.)
> may be the entity which controls it in an
> implementation-of-that-piece-of-the-system-defined manner.
Exactly. I knew what you meant. But since there is "the implementation of
sshd" and the "implementation of the drivers" and the "implementation of the
UART/chipset," I want to be clear that implementation specific is not the
responsibility of the writer of the SSHD
"If the SSH server responsible for sending the break has no control over the
hardware that sends break length (as in an opaque UART driver), or has no
way to pass break length information (as in an SSH to telnet gateway), the
implementation MAY (MUST?) still send a BREAK signal, omitting the length
information. Sending a break signal without the length information is still
considered a successful sending of a BREAK."
Bottom line: Break length is a SUGGESTION, which may be used by the
receiver if it is so capable..
Home |
Main Index |
Thread Index |
Old Index