Re: Question about linemode implementation...

"David A. Borman" <> Tue, 26 April 1994 21:01 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa15317; 26 Apr 94 17:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15313; 26 Apr 94 17:01 EDT
Received: from by CNRI.Reston.VA.US id aa18969; 26 Apr 94 17:01 EDT
Received: from ( by (Bob mailer 1.2) id AA17239; Tue, 26 Apr 94 15:40:40 CDT
Received: by (5.0/CRI-5.14 Sdiv) id AA09355; Tue, 26 Apr 1994 15:40:33 +0600
Received: from ( by (5.0/CRI-5.14 Sdiv) id AA09345; Tue, 26 Apr 1994 15:40:29 +0600
Received: from ( by (Bob mailer 1.2) id AA17211; Tue, 26 Apr 94 15:40:26 CDT
Received: by id AA01970; 4.1/CRI-5.6; Tue, 26 Apr 94 15:42:21 CDT
Date: Tue, 26 Apr 94 15:42:21 CDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "David A. Borman" <>
Message-Id: <>
Subject: Re: Question about linemode implementation...
Content-Length: 2507

> In rfc1184 there is this text:
> +    Normally, the entire user interface is left up to the implementor.
> +    However, there is functionality that the user should be able to
> +    specify on the client side of the connection.  During a Telnet
> +    session, the client side should allow some mechanism for the user to
> +    give commands to the local Telnet process.  These commands should at
> +    least allow the user to:
> +       1)  Change the mode of the connection.  The user should be able to
> +           attempt to turn EDIT, FLOW, TRAPSIG, and ECHO on and off.  The
> +           server may refuse to change the state of the EDIT and TRAPSIG
> +           bits.
> My question is about the last sentence above.  I certainly can see how
> it is good to require clients to attempt to negotiate these options
> when the user requests.

The goal of this section was to ensure that the client provided a way
for the user to make the request.  It was assumed that the client would
turn the request into the appropriate telnet command.

> However, nowhere does this make clear when and
> why a server might refuse these state changes.  
> To me, it seems clear that the server would refuse to negotiate those
> options if they were in conflict with the present state of the "pty"
> set by the application.  For example, if the application has set the
> pty into "raw" mode, negotiating remote edit should probably be refused.
> (And I think I can make similar arguments about flow, trapsig and echo.)

On a typical UNIX based system, you can do things like "stty -echo".
This would change the state of the pty, which notifies the telnetd
of the state change, and it then sends a MODE command to the client
to let it know of the change.  The telnet client interface allows
the opposite to happen.  The client sends the MODE command to the
server, it takes the new mode and sends it to the pty, which then
becomes apparent to any application that looks at the pty state.

It was assumed that there might be some systems where the state
of the pty couldn't be changed by the server, and we didn't want
to make it impossible to implement linemode telnet on those systems.

> Is it correct that a reasonable and compliant linemode server would
> refuse mode changes in that way?
> Cheers,
> 	~sparker

The server shouldn't refuse to change the state of these bits unless
there is a valid restriction in the pty driver that precludes changing

			-David Borman,