Hi!
So far, I have only tested this with PuTTY, which, to my surprise, is
not
willing to enable EOR in any direction either. I was hoping it would
support EOR
because it does support many others.
The EOR reference specification says that "as the EOR code indicates the
end of
an effective data unit, Telnet should attempt to send the data up to and
including the EOR code together to promote communication efficiency."
This
leaves room for interpretation as to what exactly would constitute an
effective
outgoing data unit for the Inetutils telnet client. However, perhaps we
can gain
inspiration from how the EOR is utilized in other applications.
This option is often used by multi-user dungeon (MUD) servers to
indicate the
end of the command prompt (https://tintin.mudhalla.net/protocols/eor/).
MUDs are
utilizing the EOR sequence for the sake of client implementation
convenience.
Without it, a MUD client would not know when the server has finished
sending the
last line as the prompt does not immediately end with the newline
character.
However, the client needs to know where the prompt line ends in order to
process
incoming text substitutions and actions.
As we can see, the prompt end ambiguity in the context of MUDs is much
like the
escape key end ambiguity in the context of TTY applications. Therefore,
while I
am currently not aware of any telnet client implementations that could
send the
EOR sequence, the MUD servers often do have this option implemented and
should
serve as a worthy example.
For context, I am in a very early stage of developing a TTY-based
computer game,
and I am taking special effort to make it also available over telnet.
This can
easily be done with the help of the tool named tcpserver. It waits for
connections from TCP clients, and for each connection, it runs a custom
program,
with descriptor 0 reading from the network and descriptor 1 writing to
the
network.
As part of my research, I did implement the proposed EOR mechanism in my
own
custom telnet client for the game, and it works as expected. If the game
reads
just a single escape character, it remains waiting for more incoming
data. If
the following data begins with the IAC EOR sequence, then the game
interprets it
as the user just pressed the ESC key.
In other keyboard input cases, the IAC EOR sequence serves no known
purpose, but
in my opinion, it should still be sent by the client for the sake of the
RFC 885
specification (https://datatracker.ietf.org/doc/html/rfc885). It would
make the
most sense to me if the IAC EOR sequence is sent after any keystroke if
the
transmission is in character mode. If the transmission is not in
character mode,
then perhaps line endings would be the right spot where to inject the
EOR.
Erich
On 2026-01-12 09:56, Simon Josefsson wrote:
Hi! Interesting, how do other telnet clients behave wrt to this? Is
your suggested solution implemented by any other client? I'm not sure
if we should introduce a implementation difference like this without
serious consideration and (attempts to) discussion with other
implementers.
/Simon
[email protected] writes:
Hi!
I recently came across an ancient issue related to the ambiguity in
interpreting
the escape key in terminal applications. The problem lies in
distinguishing the
escape key "\x1b" from ANSI escape sequences (e.g., "\x1b[A" for the
up arrow).
Traditionally, this issue has been addressed by measuring the time gap
between
receiving the initial escape character "\x1b" and the following
"[A". If there
is a noticeable delay between them, they are considered as separate
keys (ESC,
'[', and 'A'). Otherwise, they are treated as a single up arrow key
press.
While this time-based approach works well for locally executed
terminal
applications, telnet applications are still affected by network
latency issues.
To tackle this, I suggest enabling the negotiation of the Telnet End
of Record
Option in the Inetutils telnet client. Currently, the client does not
seem to
support this option effectively. Although some handling exists in the
source
code, it appears to be activated only when the TN3270 macro is
defined.
If the telnet client could send an IAC EOR 2-octet sequence after each
key
press, the ambiguity could be easily resolved, at least in character
mode
transmission.
Erich
