RFC 1116

Telnet Linemode option

📅 published August 1989, from ietf

RFC 1116: Telnet Linemode Option 🎀

part 1 of 5 🦋

Okay bestie, let's start with the header 📄. This is RFC 1116, called "Telnet Linemode Option." It came from the Network Working Group and the Internet Engineering Task Force, specifically the Telnet Linemode Working Group. The editor is D. Borman from Cray Research, Inc., and it's dated August 1989 🗓️. It's a proposed elective standard, so it's giving "optional, but hosts that do Linemode are expected to adopt it." The header doesn't list any RFCs that it obsoletes or updates ✨.

Status of this Memo 💅

This RFC describes a proposed elective standard for the Internet community. Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this standard. Distribution of this memo is unlimited 🌈.

Overview 🦋

Okay, so Linemode Telnet is a way of doing terminal character processing on the client side of a Telnet connection 💻. While you're in Linemode with editing enabled for the local side, network traffic drops to a couple of packets per command line, instead of a couple of packets per character you type. Main character energy 👑.

This is super useful for long delay networks, because the user gets local response time while typing the command line and only deals with the network delays after the command is typed 🫶. It also helps lower costs on networks that charge per packet 💸.

Table of Contents 🧚

1.   Command Names and Codes                                        2
2.   Command Meanings                                               3
2.1  The LINEMODE function                                          3
2.2  LINEMODE suboption MODE                                        3
2.3  LINEMODE suboption FORWARDMASK                                 4
2.4  LINEMODE suboption SLC, Set Local Characters                   5
2.5  New control characters                                         8
3.   Default Specification                                          9
4.   Motivation                                                     9
5.   Implementation Rules                                          11
5.1  User Interface                                                11
5.2  End of line terminators                                       12
5.3  Output processing                                             12
5.4  A terminal driver in Telnet?                                  12
5.5  Setting of Local Characters                                   12
5.6  FORWARDMASK and SLC_FORW1 and SLC_FORW2                       13
5.7  Valid and invalid modes and values.                           14
5.8  Flushing input and output                                     14
5.9  State diagram for SLC                                         16
5.10 Example of a connection                                       17
6.   Other Telnet options and RFCs                                 20

1. Command Names and Codes ✨

    LINEMODE        34
        MODE             1
            EDIT             1
            TRAPSIG          2
            MODE_ACK         4
        FORWARDMASK      2
        SLC              3
            SLC_SYNCH        1
            SLC_BRK          2
            SLC_IP           3
            SLC_AO           4
            SLC_AYT          5
            SLC_EOR          6
            SLC_ABORT        7
            SLC_EOF          8
            SLC_SUSP         9
            SLC_EC          10
            SLC_EL          11
            SLC_EW          12
            SLC_RP          13
            SLC_LNEXT       14
            SLC_XON         15
            SLC_XOFF        16
            SLC_FORW1       17
            SLC_FORW2       18

            SLC_DEFAULT      3
            SLC_VALUE        2
            SLC_CANTCHANGE   1
            SLC_NOSUPPORT    0
            SLC_LEVELBITS    3

            SLC_ACK        128
            SLC_FLUSHIN     64
            SLC_FLUSHOUT    32
    EOF            236
    SUSP           237
    ABORT          238

2. Command Meanings 🍓

2.1 The LINEMODE function 💖

IAC WILL LINEMODE

The sender of this command REQUESTS permission to begin sub-negotiation of the editing/signaling status. This should only be sent by the client side of the connection 🙈.

IAC WONT LINEMODE

The sender of this command DEMANDS that sub-negotiation of the editing/signaling status not be allowed. Hard no, bestie 🚫.

IAC DO LINEMODE

The sender of this command REQUESTS that the remote side begin subnegotiation of the editing/signaling status. This should only be sent by the server side of the connection 🧚.

IAC DONT LINEMODE

The sender of this command DEMANDS that the remote side not begin subnegotiation of the editing/signaling status. Also a hard no 💀.

2.2 LINEMODE suboption MODE 🌸

IAC SB LINEMODE MODE mask IAC SE

The sender of this command CONFIRMS, or REQUESTS permission for, a switch to the mode defined by "mask" 🔥.

The "mask" is a bit mask of the various modes the connection can be in. Under normal operation, the server side initiates mode changes, and the client confirms them. The currently defined modes are:

  • EDIT: When set, the client side of the connection should process all input lines, performing any editing functions, and only send completed lines to the remote side. When unset, the client side should not process any input from the user, and the server side should take care of all the character processing that needs doing ✍️.
  • TRAPSIG: When set, the client side should translate the appropriate interrupts/signals to their Telnet equivalent. (These would be IP, BRK, AYT, ABORT, EOF, and SUSP.) When unset, the client should pass interrupts/signals through as their normal ASCII values 🦋.
  • FLOW: Logically, this belongs in the "mask." However, it would overlap the Telnet TOGGLE-FLOW-CONTROL option, so the Telnet TOGGLE-FLOW-CONTROL option is used instead. When DO/WILL LINEMODE is negotiated, DO/WILL TOGGLE-FLOW-CONTROL should also be negotiated. See RFC 1080, "Telnet Remote Flow Control", for correct usage 🌊.
  • ECHO: Logically, this belongs in the "mask." However, it would overlap the Telnet ECHO option, so the Telnet ECHO option is used instead. The client side should never negotiate "WILL ECHO." When the server has negotiated "WILL ECHO," the client should not echo the data the user types back to the user. When the server has negotiated "WONT ECHO," the client is responsible for echoing the data the user types back to the user. See RFC 857, "Telnet ECHO OPTION," for a complete discussion of how the Telnet ECHO option is used 🎀.

When the client side of a connection receives a MODE command, it MUST agree with at least the state of the EDIT and TRAPSIG bits. If a MODE command is received with a mode mask that is currently in use (ignoring the MODE_ACK bit), the MODE command is ignored. If a MODE command is received that is different from the current mode mask, then a reply is sent with either the new mode mask and the MODE_ACK bit set, or a subset of the new mode mask. The only exception is that if the server receives a MODE with either the EDIT or TRAPSIG bits not set, it may set the EDIT and TRAPSIG bits in the response. And if the client receives a MODE with the EDIT or TRAPSIG bits set, it may not clear them in the response 💅.

When a MODE command is received with the MODE_ACK bit set, and the mode is different from what the current mode is, the client will ignore the new mode, and the server will switch to the new mode. This makes sure both sides of the connection resolve to the same mode 🤝. In all cases, a response is never generated to a MODE command that has the MODE_ACK bit set. No replies to replies, periodt 🙌.

2.3 LINEMODE suboption FORWARDMASK 🦄

IAC SB LINEMODE DO FORWARDMASK mask0 mask1 ... mask31 IAC SE

The sender of this command requests that the other side send any buffered data when any of the ASCII characters defined by the bit mask are received 📬. Only the side of the connection that sent DO LINEMODE (the server side) may negotiate this. The mask is up to 32 octets long, and each octet represents 8 ASCII character codes. The high order bit of mask0 corresponds to an ASCII code of 0. The low order bit of mask0 corresponds to an ASCII code of 7. The high order bit of mask1 corresponds to an ASCII code of 8. The low order bit of mask1 corresponds to an ASCII code of 15, and so on 🔢. The mask list may be terminated before the end of the list, in which case all the rest of the mask octets are assumed to be reset (equal to zero). When the server side is in DONT TRANSMIT-BINARY mode, only the first 16 octets of the mask (ASCII codes 0 through 127) are used. If any individual octet of the mask is equal to IAC, it must be sent as a double IAC 🚨.

IAC SB LINEMODE DONT FORWARDMASK IAC SE

The sender of this command requests that the other side stop using the forward mask to determine when to send buffered data. Let it go 🫠.

IAC SB LINEMODE WILL FORWARDMASK IAC SE

This command is sent in response to a DO FORWARDMASK command. It indicates that the forward mask will be used to determine when to send buffered data 🧁.

IAC SB LINEMODE WONT FORWARDMASK IAC SE

This command is sent in response to a DO FORWARDMASK command. It indicates that the forward mask will not be used to determine when to send buffered data 🌷.

2.4 LINEMODE suboption SLC, Set Local Characters 💅

okay so the SLC suboption is basically a list of octet triplets 🎀 Each triplet is three octets. The first octet says which function, the second octet holds the modifiers for that function, and the third octet is the ASCII character for it ✨

IAC SB LINEMODE SLC <list of octet triplets> IAC SE

bestie, the sender of this command requests that the list of octet triplets gets used to set the local character that gets sent to perform the specified function 💖

there are four levels a function can be set to. SLC_NOSUPPORT is the lowest, SLC_CANTCHANGE is the next one up, SLC_VALUE is above that, and SLC_DEFAULT is the highest 👑

if the SLC_LEVELBITS in the second octet are equal to SLC_DEFAULT, then this particular function SHOULD use the system default on the other side of the connection 🌸

if the SLC_LEVELBITS in the second octet are equal to SLC_VALUE, then this function is supported, and the current value is specified by the third octet 🦋

if the SLC_LEVELBITS in the second octet are equal to SLC_CANTCHANGE, then this is a function that is supported, but the value for this function (the one in the third octet) can't be changed 🙈

if the SLC_LEVELBITS in the second octet are equal to SLC_NOSUPPORT, then this particular function is not supported and SHOULD be disabled by the other side 💀

if this is a response to a previous request to change a special character, and we're agreeing to the change, then the SLC_ACK bit MUST be set in the second octet 🫶

if the SLC_FLUSHIN bit is set in the second octet, then whenever this function is sent, a Telnet "sync" SHOULD be sent at the same time to flush the input stream 🌈

if the SLC_FLUSHOUT bit is set in the second octet, then whenever this function is sent, output data SHOULD be flushed 🧚

only the client MAY send an octet triplet with the first octet equal to zero. In that case, the SLC_LEVELBITS MAY only be set to SLC_DEFAULT or SLC_VALUE, and the third octet does not matter 🍓

when the server receives 0 SLC_DEFAULT 0, it SHOULD switch to its system default special character settings, and send all of those special characters to the client. When the server receives 0 SLC_VALUE 0, it SHOULD just send its current special character settings ✨

Heads up: if the server doesn't support some of the editing functions, they SHOULD be sent as XXX SLC_DEFAULT 0, rather than as XXX SLC_NOSUPPORT 0. That way the client MAY choose to use its own values for those functions, instead of having to disable them even if it supports them 👑

if any of the octets in the list of octet triplets is equal to IAC, it MUST be sent as a double IAC 💅

when a connection is established, it's the client's job to either request the remote default values for the special characters, or to send across what all the special characters SHOULD be set to 🎀

the function values can be sorted into two groups. The first group is functions that get translated to their Telnet equivalents before being sent across the Telnet connection. The second group is functions that get recognized and processed locally 💖

first up, the characters that get mapped into their Telnet equivalents:

  • SLC_SYNCH Synch. See RFC 854, "TELNET PROTOCOL SPECIFICATION", for a complete description.
  • SLC_BRK Break. See RFC 854, "TELNET PROTOCOL SPECIFICATION", for a complete description.
  • SLC_IP Interrupt Process. See RFC 854, "TELNET PROTOCOL SPECIFICATION", for a complete description.
  • SLC_AO Abort Output. See RFC 854, "TELNET PROTOCOL SPECIFICATION", for a complete description.
  • SLC_AYT Are You There. See RFC 854, "TELNET PROTOCOL SPECIFICATION", for a complete description.
  • SLC_EOR End of Record. See RFC 885, "TELNET END OF RECORD OPTION" for a complete description.
  • SLC_ABORT Abort. See section 2.5 for a complete description.
  • SLC_EOF End of File. See section 2.5 for a complete description.
  • SLC_SUSP Suspend. See section 2.5 for a complete description.

next, the locally interpreted functions 🦋

  • SLC_EC Erase Character. This is the character that's typed to erase one character from the input stream. See RFC 854, "TELNET PROTOCOL SPECIFICATION", for a complete description.
  • SLC_EL Erase Line. This is the character that's typed to erase the entire contents of the current line of input. See RFC 854, "TELNET PROTOCOL SPECIFICATION", for a complete description.
  • SLC_EW Erase Word. This is the character that's typed to erase one word from the input stream. When backing up in the input stream, a word is defined to be (optionally) whitespace (tab or space characters), and a string of characters up to, but not including, whitespace or line delimiters.
  • SLC_RP Reprint Line. This is the character that's typed to cause the current line of input to be reprinted, leaving the cursor at the end of the line.
  • SLC_LNEXT Literal Next. This is the character that's typed to indicate that the next character is to be taken literally. No character processing should be done with it, and if it's a special character that would normally get mapped into a Telnet option, that mapping SHOULD NOT be done.
  • SLC_XON Start Output. This is the character that's sent to resume output to the user's terminal.
  • SLC_XOFF Stop Output. This is the character that's sent to stop output to the user's terminal.
  • SLC_FORW1 Forwarding character. This is a character that SHOULD cause all data currently being buffered, and this character, to be sent immediately.
  • SLC_FORW2 Forwarding character. This is another character that is to be treated in the same manner as SLC_FORW1.

2.5 New control characters ✨

okay, three shiny new control characters 🧚

IAC ABORT

Abort. It's similar to IAC IP, but it only means to abort or terminate the process the NVT is connected to. (The Telnet spec says IP MAY "suspend, interrupt, abort or terminate" the process.) If a system doesn't have two methods of interrupting a process, then ABORT and IP SHOULD have the same effect 🙈

IAC SUSP

Suspend. This suspends the execution of the current process attached to the NVT in such a way that another process takes over control of the NVT, and the suspended process can be resumed later. If the receiving system doesn't support this functionality, it SHOULD be ignored 💅

IAC EOF

End Of File. The recipient SHOULD notify the process connected to the NVT that an end of file has been reached. This is meant for systems that let the user type in an EOF character at the keyboard 🌸

3. Default Specification 🎀

the default specification for this option is:

WONT LINEMODE
DONT LINEMODE

which basically means there won't be any subnegotiation of the mode of the connection 🫶

if WILL LINEMODE is negotiated, the defaults are:

IAC SB LINEMODE MODE 0 IAC SE
IAC SB LINEMODE WONT FORWARDMASK IAC SE

if DO LINEMODE is negotiated, the defaults are:

IAC SB LINEMODE MODE 0 IAC SE
IAC SB LINEMODE DONT FORWARDMASK IAC SE

and character values for SLC default to SLC_NOSUPPORT 🍓

4. Motivation 💖

okay so, as Telnet got more and more popular, it became SO clear that doing command line processing on your local machine and then sending the finished lines to the remote machine is a feature that's needed in a bunch of environments 🧚. First, if you're connecting over long delay equipment, it's honestly so frustrating to watch your typing echo back after several whole seconds 💀. Second, some supercomputers aren't built for handling single character input 🖥️. It's way better to let the front end computer do the character processing and keep the supercomputer's cycles free for vectorized number crunching 🧮💅.

People have tried to make local line editing work with the EXISTING Telnet specs 🙄. The 4.3 BSD tape even ships a version of Telnet that tries it by checking the state of the ECHO and SUPPRESS-GO-AHEAD options, and other implementations do the checking purely through ECHO.

But honestly, both methods have problems 😬. Using just ECHO gives you no way to turn echo to the user off while keeping local character processing on, like when you're typing a password 🔐.

The whole SUPPRESS-GO-AHEAD thing comes from reading RFC 858, which says:

"In many TELNET implementations it will be desirable to couple the SUPRESS-GO-AHEAD option to the echo option so that when the echo option is in effect, the SUPPRESS-GO-AHEAD option is in effect simultaneously: both of these options will normally have to be in effect simultaneously to effect what it commonly understood to be character at a time echoing by the remote computer."

Reading that backwards, if you have neither ECHO nor SUPPRESS-GO-AHEAD on, you're in line at a time mode, which implies local line editing. The obvious problem? That's not what SUPPRESS-GO-AHEAD is supposed to mean 🙃.

Other shortcomings: Telnet isn't rich enough to handle all the special characters that some current operating systems support 😤. For example, the ECHO/SGA setup gives you two ways to interrupt a process, and it borrows the BRK option for the second one. Some implementations even used EOR to send an End-Of-File. Obviously that's using things for stuff they weren't meant for 💀, and the correct fix is to define new options.

Another issue: some line mode implementations buffer up your input until the end of the line, then send the whole thing across, editing characters and all. So no local editing actually happened 😭.

After looking at a bunch of implementations, it's giving "the correct move is new options." The goal is to upgrade the current Telnet spec so it can do local line editing in a reasonable, reliable, and consistent way ✨.

There are three states we care about 👑:

  1. Local line editing and local signal trapping
  2. Remote line editing, local signal trapping
  3. Remote line editing, remote signal trapping

Local line editing plus remote signal trapping? Not a very interesting combo 🥱. You don't recognize the signals, so you can't send them to the remote side until the line is completed. Plus, special signals usually mess with line editing, so if they aren't trapped locally, the desired action just won't happen.

Local line editing means all the normal command line character processing, like "Erase Character" and "Erase Line", happens on your machine 💅. The edited data only gets sent to the remote system once "CR LF" (or some other special character) shows up.

Signal trapping: say you type the character tied to the IP function. Then IAC IP gets sent to the remote side instead of the character you typed 🎯. Remote signal trapping is the opposite vibe: IAC IP is not sent, and the actual character you typed goes to the remote side instead 🙈.

5. Implementation Rules ✨

It is expected that any implementation that supports the Telnet LINEMODE option will support all of this specification. So if you support LINEMODE, you're expected to support the whole thing 🫶.

5.1 User Interface

Normally the entire user interface is up to the implementor 💅. BUT there's some functionality the user SHOULD be able to specify on the client side of the connection 👀. During a session, the client side SHOULD give the user some mechanism for sending commands to the local Telnet process. Those commands SHOULD at least let the user:

  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.
  2. Import or export SLC. The user SHOULD be able to tell the local Telnet process whether they want to use the local, or the current or default remote, definitions of the special characters.
  3. Manually send options. The user SHOULD be able to tell the local Telnet process to explicitly send any of the Telnet options (like IP, ABORT, AYT, etc.).

5.2 End of line terminators

When LINEMODE is on and you're in EDIT mode, whatever normal line terminator your client OS uses SHOULD be transmitted as CR LF ✨. When EDIT mode is off, a carriage return SHOULD be sent as CR NUL, a line feed SHOULD be sent as LF, and any other key that can't be mapped to an ASCII character but still means "line done" (like a DOIT or ENTER key) SHOULD be sent as CR LF.

5.3 Output processing

No matter which mode got negotiated, the server side is responsible for ALL output processing 🖥️. Specifically, it SHOULD send CR LF when it wants the "newline" function, CR NUL when it wants just a carriage return, and LF when it wants just a linefeed.

5.4 A terminal driver in Telnet?

Conforming implementations need not do all the line editing themselves 🧘. Letting the system terminal driver handle it is totally fine. The driver edits the line and hands the completed, edited line to the Telnet application, which then sends it to the remote system 💖.

5.5 Setting of Local Characters

When this RFC was being cooked 🍳, the original plan was that both sides would use their own defaults for the special characters, even if those defaults didn't match. But if that scheme were used, the user would think their local special characters were in use and that the remote settings don't matter 🙃. So it was decided that the client side SHOULD be in control of the character settings 👑.

Once LINEMODE is negotiated, the client MUST either export its local character settings to the server, or send a request (SLC 0 SLC_DEFAULT 0) to import the server's special characters 📤📥. Usually a client on a full fledged computer would export its characters, and a client where there are no local defaults (like some terminal servers) would import them ✨.

When an SLC command comes in, the action taken SHOULD be:

  1. Ignore it if it is the same as the current settings.
  2. If the SLC_LEVELBITS are the same as the current level bits, but the value is different and the SLC_ACK bit is set, no reply is generated. On the server side, the command is ignored, and on the client side, a switch is made to the new value. This is so that if a request to change the same character is generated by both the server and the client, they will both settle on the client's requested value.
  3. If we agree with the new setting, we switch to it and reply with the same value, but also set the SLC_ACK bit.
  4. If we don't agree, we send a response with what we think the value SHOULD be. The SLC_ACK bit is NOT set in this case. You MAY only disagree with a value by sending a different value at a lower level.

If the remote system doesn't support some of the line editing characters, but the front end does, then the front end MAY use the local definitions for those characters when in line mode. In this case, the server SHOULD send SLC xxx SLC_DEFAULT 0 in response to a SLC 0 SLC_DEFAULT 0 request, and just ack whatever value the client requests to set the function to.

The SLC_FORW2 character SHOULD only be used if SLC_FORW1 is already in use.

5.6 FORWARDMASK and SLC_FORW1 and SLC_FORW2

To ease the amount of work needed to implement the client side, two methods of setting forwarding characters are provided 🧁. SLC_FORW1 and SLC_FORW2 let you set two additional characters on which to forward buffered input data. Since many terminal drivers can set one or more line delimiters, it's fairly easy to support these without implementing through the local terminal driver, instead of putting a whole terminal driver into Telnet. If the local terminal driver has functionality that maps easily into the FORWARDMASK, it can be supported easily too. If the local terminal driver doesn't support that, it would require more work to support FORWARDMASK.

Also note that the client side is REQUIRED to forward data when it sees one of SLC_FORW1, SLC_FORW2, or FORWARDMASK characters, or when any normal line termination or special signal is encountered 📣. The client side is also free to forward on other characters that it chooses. For example, say the server side sent a FORWARDMASK asking for data to be forwarded on the first 20 control characters (ASCII codes 1 through 024). If the client side can't have its local terminal driver forward on just those first 20 control characters, but it can have the driver forward on any control character (ASCII codes 1 through 039), then the client side could validly accept the FORWARDMASK and forward on any control character 🌈.

When in EDIT mode, care SHOULD be taken not to forward at random times, since once data is forwarded, no more editing on the forwarded part of the line can be done 😱. The only time (other than the normal times) that data SHOULD be forwarded when in EDIT mode is if a single input line is too long to handle locally.

5.7 Valid and invalid modes and values

At no time SHOULD DO LINEMODE be negotiated in both directions of the Telnet connection 🚫. The side that is the DO LINEMODE side is considered to be the server side, and the side that is WILL LINEMODE is the client side 🫶.

At no time SHOULD SB LINEMODE DO/DONT FORWARDMASK be sent unless DO LINEMODE has been previously negotiated. At no time SHOULD SB LINEMODE WILL/WONT FORWARDMASK be sent unless WILL LINEMODE has been previously negotiated 🙈.

If an ABORT, EOF or SUSP comes in and the system doesn't support that functionality, it MAY just be ignored 🫠.

5.8. Flushing input and output ✨

okay so when an IP, BRK or ABORT gets sent, it's usually super desirable to flush the input stream AND flush the output going to the user until that IP, BRK, or ABORT actually gets processed 💅. That's what the SLC_FLUSHIN and SLC_FLUSHOUT bits are for, they tell you what action to take 🫶. These bits are advisory only, but they should be honored if possible, bestie 💀. The standard way to handle SLC_FLUSHIN is the Telnet "Synch" signal, and SLC_FLUSHOUT gets handled with the TIMING-MARK option ✨. If you're sending both, the IAC DM goes out first, before the DO TIMING-MARK. So the sender would send IAC XXX IAC DM IAC DO TIMING-MARK, where XXX can be IP, BRK, ABORT, or any other special character 🎀.

The IAC DM gets sent as TCP urgent data, with the DM as the last (or only) data octet, and that's what flushes the input stream 🌊. The IAC DO TIMING-MARK is how you know when to stop flushing output. Once it's sent, all data gets discarded until an IAC WILL TIMING-MARK or an IAC WONT TIMING-MARK is received 🧚.

Since SLC_FLUSHIN and SLC_FLUSHOUT are only advisory, the user interface should give the user a way to override sending (or not sending) the "Synch" and TIMING-MARK 💖. The default, though, should just be to send them based on the SLC_FLUSHIN and SLC_FLUSHOUT bits. no notes, just vibes 🌸

Whenever an IAC AO is received, a Synch must be returned 🔥. Whenever a Synch is being processed (by the TCP connection going into Urgent mode), all data must be discarded (but not Telnet commands!) until an IAC DM is found and the connection goes out of Urgent mode 😭. See RFC 854, "TELNET PROTOCOL SPECIFICATION", for a complete description of the Synch signal 📚.

5.9. State diagram for SLC 🦋

Okay this diagram is a lot, but it's giving main character energy 👑. The * marks client side only, and the # marks server side only 🌈.

   +---------------------------------------------------------------+
   |                                IDLE                           |
   +----------------------+------+------+-------+-------+---------++
    ^      ^     ^        |      | ^    | ^     | ^     |       ^ |
    |      |     |        v      v |    | |     | |     v       | |
    |      |     |    +------+ +---+--+ | |     | | ########### | |
    |      |     |    | Get  | | Send | | |     | | #   Get   # | |
    |      |     |    | SPC0 | | SPC0 | | |     | | # 0,DEF,0 # | |
    |      |     |    +---+--+ +------+ | |     | | ########### | |
    |      |     |        |       ^     | |     | |     |       | |
    |      |     |        v       |     v |     | |     v       | |
    |      |     |       / \      | *********** | | ########### | |
    |      |     |     /     \    | *  Send   * | | # Switch  # | |
    | ********** |Yes/ Same as \  | * 0,VAL,0 * | | # to      # | |
    | * Change * +--<  current? > | *********** | | # default # | |
    | * to new *     \         /  |             v | ########### | |
    | * value  *       \     /    |     ***********     |       | |
    | **********         \ /      |     *  Send   *     v       | |
    |      ^              |No     |     * 0,DEF,0 *  #########  | |
    |      |Yes           v       |     ***********  # Send  #--+ |
    |     / \            / \      |                  # SPC-A #    |
    |   /     \        /     \    |                  #########    |
    | / Is ACK  \ Yes/  Same   \  |                     ^         |
    |< bit set?  ><-<  level as > |                     |         |
    | \         /    \ current?/  |                 ###########   |
    |   \     /        \     /    |                 #   Get   #<--+
    |     \ /            \ /    +-+---+             # 0,VAL,0 #
    |      |No            |No   | Set |             ###########
    |      +--------------+     | ACK |
    |                     v     | bit |      * - Client side only
    |                    / \    +-----+      # - Server side only
    |   +------+       /     \      ^
    |   | Send |  No /  Do we  \ Yes|
    +---| SPC1 |<---<   agree?  >---+
        +------+     \         /
                       \     /
                         \ /

Next up are the legend and the level and flag names, which are the key to reading the diagram 💜.

           SPC0    Initial setting for a special character
           SPC1    A changed special character < SPC0
           SPC-A   All current special character settings
           VAL     SLC_VALUE level
           DEF     SLC_DEFAULT level

   Levels: DEFAULT, VALUE, CANT_CHANGE, NOSUPPORT
   Flags: ACK

And this table is where the real magic happens 🎀. It shows what comes in and what goes back out 🫶.

           Receive                 Response
           -------                 --------
           f,SLC_DEFAULT,x         f,SLC_VALUE,v
                                   f,SLC_CANTCHANGE,v
                                   f,SLC_NOSUPPORT,x

           f,SLC_VALUE,v           f,SLC_ACK|SLC_VALUE,v
                                   f,SLC_CANTCHANGE,w
                                   f,SLC_NOSUPPORT,x

           f,SLC_CANTCHANGE,v      f,SLC_ACK|SLC_CANTCHANGE,v
                                   f,SLC_NOSUPPORT,x

           f,SLC_NOSUPPORT,x       f,SLC_ACK|SLC_NOSUPPORT,x

           x,SLC_ACK|x,x           no response

5.10. Examples of a connection 💅

Okay so in these examples, the symbolic names are used instead of the actual values, so they're way easier to read 🧚. When two or more symbolic names are joined by a |, it means the actual value is the logical "or" of those names' values ✨. For clarity, the leading IAC and IAC SB sequences and the trailing IAC SE sequences have been left out. The SLC_ prefix is also left off wherever it would normally show up 🌸.

       CLIENT                        SERVER
       ------                        ------
                                     DO TOGGLE-FLOW-CONTROL
                                     DO LINEMODE
       WILL TOGGLE-FLOW-CONTROL
       WILL LINEMODE
       [ Subnegotiation may now proceed in both directions.  The client
         sends of the list of special characters.  ]
       LINEMODE SLC SYNCH DEFAULT 0
       IP VALUE|FLUSHIN|FLUSHOUT 3 AO
       VALUE 15 AYT DEFAULT 0 ABORT
       VALUE|FLUSHIN|FLUSHOUT 28 EOF
       VALUE 4 SUSP VALUE|FLUSHIN 26
       EC VALUE 127 EL VALUE 21 EW
       VALUE 23 RP VALUE 18 LNEXT
       VALUE 22 XON VALUE 17 XOFF
       VALUE 19
       [ Now that linemode is enabled,  the  server  sets  the  initial

         mode, and acknowledges the special characters.  ]
                                     LINEMODE MODE EDIT

                                     LINEMODE SLC SYNCH NOSUPPORT 0 IP
                                     VALUE|FLUSHIN|FLUSHOUT|ACK 3 AO
                                     NOSUPPORT 0 AYT NOSUPPORT 0 ABORT
                                     VALUE|FLUSHIN|FLUSHOUT|ACK 28 EOF
                                     VALUE|ACK 4 SUSP NOSUPPORT 0 EC
                                     VALUE|ACK 127 EL VALUE|ACK 21 EW
                                     VALUE|ACK 23 RP VALUE|ACK 18 LNEXT
                                     VALUE|ACK 22 XON VALUE|ACK 17 XOFF
                                     VALUE|ACK 19
       [ The client gets the mode and ack of the special characters,
         and acks the mode and any special characters that the server
         changed.  ]
       LINEMODE MODE EDIT|MODE_ACK

       LINEMODE SLC SYNCH
       NOSUPPORT|ACK 0 AO
       NOSUPPORT|ACK 0 AYT|ACK NOSUP-
       PORT 0 SUSP NOSUPPORT|ACK 0
                                     "Login:"
       "my_account"
       [ Turn off echo to the user.  ]
                                     WILL ECHO
       DO ECHO
                                     "Password:"
       "my_password"
       [ Turn back on echo to the user.  ]
                                     WONT ECHO
       DONT ECHO
       [ User does some stuff, and then runs an application that wants
         to use single character mode, doing its own echoing of
         characters, but keep signal trapping on.  ]
                                     WILL ECHO
       DO ECHO
                                     LINEMODE MODE TRAPSIG
       LINEMODE MODE TRAPSIG|MODE_ACK
       [ Application finishes.  ]
                                     WONT ECHO
       DONT ECHO
                                     LINEMODE MODE EDIT|TRAPSIG
       LINEMODE MODE
       EDIT|TRAPSIG|MODE_ACK
       [ Another application, that wants full control of everything.  ]
                                     WILL ECHO
       DO ECHO
                                     LINEMODE MODE 0

       LINEMODE MODE 0|MODE_ACK
       [ Application finishes.  ]
                                     WONT ECHO
       DONT ECHO
                                     LINEMODE MODE EDIT|TRAPSIG
       LINEMODE MODE
       EDIT|TRAPSIG|MODE_ACK
       [ The user changes his erase character to ^H.  ]
                                     LINEMODE SLC EC VALUE 8
       LINEMODE SLC EC VALUE|ACK 8
       [ The user decides to revert to all the original client side
         special characters.  ]
       LINEMODE SLC SYNCH DEFAULT 0
       IP VALUE|FLUSHIN|FLUSHOUT 3 AO
       VALUE 15 AYT DEFAULT 0 ABORT
       VALUE|FLUSHIN|FLUSHOUT 28 EOF
       VALUE 4 SUSP VALUE|FLUSHIN 26
       EC VALUE 127 EL VALUE 21 EW
       VALUE 23 RP VALUE 18 LNEXT
       VALUE 22 XON VALUE 17 XOFF
       VALUE 19
                                     LINEMODE SLC SYNCH NOSUPPORT 0 AO
                                     NOSUPPORT 15 AYT NOSUPPORT 0 SUSP
                                     NOSUPPORT|FLUSHIN 26 EC VALUE|ACK
                                     127 EW VALUE|ACK 23 RP VALUE|ACK
                                     18 LNEXT VALUE|ACK 22 XON
                                     VALUE|ACK 17 XOFF VALUE|ACK 19
       LINEMODE SLC SYNCH
       NOSUPPORT|ACK 0 AO
       NOSUPPORT|ACK 15 AYT
       NOSUPPORT|ACK 0 SUSP
       NOSUPPORT|ACK|FLUSHIN 26
       [ The user decides to import the remote sides default special
         characters.  ]
       LINEMODE SLC 0 DEFAULT 0
                                     LINEMODE SLC IP
                                     VALUE|FLUSHIN|FLUSHOUT 3 ABORT
                                     VALUE|FLUSHIN|FLUSHOUT 28 EOF
                                     VALUE 4 EC VALUE 127 EL VALUE 21
       [ Since these are the same as the current local settings, no
         response is generated.  ]
       [ This next example is what would happen if an editor was fired
         up, that wanted to let the client side do the echoing and
         buffering of characters, but did not want it to do any line
         editing, and only forward the data when got a control
         character.  Note that we have preceded all the the 0377s in the
         forward mask with an IAC.  ]
                                     LINEMODE MODE 0
                                     LINEMODE DO FORWARDMASK IAC 0377
                                     IAC 0377 IAC 0377 IAC 0377 0 0 0 0
                                     0 0 0 0 0 0 0 01
       LINEMODE MODE 0
       LINEMODE WILL FORWARDMASK
       [ Application runs to completion, and then things are to be set
         back to what they were before.  ]
                                     LINEMODE MODE EDIT|TRAPSIG
                                     LINEMODE DONT FORWARDMASK
       LINEMODE MODE EDIT|TRAPSIG
       LINEMODE WONT FORWARDMASK

6. Other Telnet options and RFCs ✨

okay bestie, this is the reading list 📚💅 these are the Telnet options and RFCs you should support alongside LINEMODE, so it's giving full set 🎀

  1. Postel, J. and J. Reynolds, "TELNET PROTOCOL SPECIFICATION", RFC 854, USC/Information Sciences Institute, May 1983.
  2. Postel, J. and J. Reynolds, "TELNET OPTION SPECIFICATIONS", RFC 855, USC/Information Sciences Institute, May 1983.
  3. Postel, J. and J. Reynolds, "TELNET BINARY TRANSMISSION", RFC 856, USC/Information Sciences Institute, May 1983.
  4. Postel, J. and J. Reynolds, "TELNET ECHO OPTION", RFC 857, USC/Information Sciences Institute, May 1983.
  5. Postel, J. and J. Reynolds, "TELNET SUPRESS GO AHEAD OPTION", RFC 858, USC/Information Sciences Institute, May 1983.
  6. Postel, J. and J. Reynolds, "TELNET TIMING MARK OPTION", RFC 860, USC/Information Sciences Institute, May 1983.
  7. VanBokkeln, J., "Telnet Terminal-Type Option", RFC 1091, FTP Software, Inc., February 1989.
  8. Waitzman, D., "Telnet Window Size Option", RFC 1073, BBN STC, October 1988.
  9. Hedrick, C., "Telnet Remote Flow Control Option", RFC 1080, Rutgers University, November, 1988.
  10. Hedrick, C., "Telnet Terminal Speed Option", RFC 1079, Rutgers University, December, 1988.

ngl the next batch is the bonus pack 🌈 you don't have to support these for LINEMODE, but they'd seriously level up any TELNET implementation ✨

  1. Postel, J. and J. Reynolds, "TELNET STATUS OPTION", RFC 859, USC/Information Sciences Institute, May 1983.
  2. Postel, J. and J. Reynolds, "TELNET END OF RECORD OPTION", RFC 885, USC/Information Sciences Institute, December 1983.
  3. Silverman, S., "OUTPUT MARKING TELNET OPTION", RFC 933, MITRE-Washington, January 1985.
  4. Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie Mellon University, March 1989.

Author's Address 🎀

Dave Borman
Cray Research Inc.
1440 Northland Drive
Mendota Heights, MN 55120

Phone: (612) 681-3398

EMail: dab@CRAY.COM
📦 where this page comes from