Re: telnet client enhancement proposal

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
>> 
>>