RFC 1053

Telnet X.3 PAD option

📅 published April 1988, from ietf

RFC 1053: Telnet X.3 PAD Option 🎀

Okay bestie, let's go! 💖 This is RFC 1053 from the Network Working Group, written by S. Levy and T. Jacobson at the Minnesota Supercomputer Center, dated April 1988. It's a proposal for a brand-new Telnet option ✨. It doesn't list anything it obsoletes or updates, so no drama there 🙈.

Status of This Memo 🧾

Okay so this part is the official-ish bit, but it's actually simple 💅. This RFC proposes a new option to Telnet for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. Distribution of this memo is unlimited, so share it with everyone 🌈.

1. Command name and code 💖

The option is called X.3-PAD, and its code is 30 🧚. Here's the whole thing in one glance:

   X.3-PAD                30

2. Command meanings 🦋

Okay this is the part where the telnets actually talk to each other, and it's giving very specific vibes 💀. There are four command combos, and each one has its own meaning.

When a telnet sends IAC DO X.3-PAD, it's asking its peer to perform the X.3-PAD functions, or it's accepting an offer to do them 🙌.

   IAC  DO     X.3-PAD

When a telnet sends IAC DON'T X.3-PAD, it's demanding that its peer stop performing the X.3-PAD functions, or cease performing them if it already is 🚫.

   IAC  DON'T  X.3-PAD

When a telnet sends IAC WILL X.3-PAD, it's offering to perform the X.3-PAD functions, or confirming that it will do so ✨.

   IAC  WILL   X.3-PAD

When a telnet sends IAC WON'T X.3-PAD, it's refusing to perform the X.3-PAD functions, or saying it's wrapping up and no longer handling them 😭.

   IAC  WON'T  X.3-PAD

Typically a server (host) telnet uses DO and DON'T, while a client (user) telnet uses WILL and WON'T 👑. For convenience, in the rest of this RFC, "host" and "user" telnets refer to those saying "DO X.3-PAD" or "WILL X.3-PAD" respectively 🧠.

Both telnet peers can use this option without confusion, because every message clearly says whether it came from the host ("DO") or the user ("WILL") side. No mixed-up energy here 💜.

Once DO and WILL have been exchanged, the host ("DO") telnet can send these messages 💌:

   IAC SB  X.3-PAD  SET           <param1> <value1> ...  IAC SE
   IAC SB  X.3-PAD  RESPONSE-SET  <param1> <value1> ...  IAC SE
   IAC SB  X.3-PAD  SEND          IAC SE

And the user ("WILL") telnet can send these 🌸:

   IAC SB  X.3-PAD  IS            <param1> <value1> ...  IAC SE
   IAC SB  X.3-PAD  RESPONSE-IS   <param1> <value1> ...  IAC SE

Here are the codes for each of those message types, bestie 🍓:

   The code for SET          is 0
   The code for RESPONSE-SET is 1
   The code for IS           is 2
   The code for RESPONSE-IS  is 3
   The code for SEND         is 4

Messages that list parameter-value pairs can hold any number of those pairs, including zero, so you can be chatty or super quiet 🤫. Each parameter and each value takes up one octet, but there's a plot twist: 255 (IAC) gets doubled every time it shows up 🙈💅.

5. Description of the option ✨

Okay so, lots of X.3 services are super meaningful for remote terminal stuff 🖥️, but not all of them! For some, it's iconic to let the user still control things locally while the server host can't take over (not remote control, just local vibes 💅). Some functions might not exist at all, or only work in a limited way, depending on the implementation. So the Telnet energy here is: ask for the service you want, but keep functioning somehow if it's not available 🫶.

Negotiations are asymmetrical 🙃. The user telnet handles the local character stuff while you're in the session with the remote host, so the X.3 parameters "belong" to the user side. The host telnet asks for parameter changes with SET or RESPONSE-SET messages. Those requests might come on behalf of an application program, like turning off local echo while someone types a password 🔐. The user telnet should give its "best effort" to accommodate them, but it guarantees nothing except accurate status reporting.

A user telnet may let the local user request parameter changes too, though this RFC doesn't say how ✨.

When requests conflict, or the user telnet can't satisfy one, the user telnet has the last word 👑, since it's the one doing the relevant character processing. It may allow control from the host only, from the user only, or look for a compromise, and so on, totally up to the implementor's discretion 💖.

Host ("DO") telnets may also ask the user telnet to SEND its current parameter values. The user ("WILL") telnet must reply to each SEND with a RESPONSE-IS listing the values of all the parameters it knows about. It is strongly recommended that every parameter known to the telnet implementor be in that list, even if the values can't be changed 🧚. The goal is to give the host telnet the most complete info possible about the style of interaction the user telnet is providing.

If possible, user telnets should also tell the server host (with an IS message) whenever local conditions (like user requests) change a parameter's state 📣. This might not be feasible in some situations, and that behavior is negotiable. See the discussion of parameter 0.

Note that there are no "error" messages defined in section 2 🙈. Almost every detectable error (using a nonexistent parameter, or an undefined value for a known parameter) looks exactly like a valid use of an option that only one peer knows about. Hosts will normally want to poll the user telnet's state after making a request anyway, so error responses don't really seem needed 💅.

The protocol messages from section 2 are used like this 🎀:

  • SET and RESPONSE-SET ask the user telnet to change its values for the given X.3 parameters. The user telnet ignores unrecognized parameters and sends no reply. The host sends SET to begin a negotiation, when something on the host side changes the desired set of parameters. The host sends RESPONSE-SET to keep the negotiation going, when it's unhappy with the parameter choice the user telnet indicated in a RESPONSE-IS message. Typically, the host will test the user telnet's chosen behavior by sending a SEND after the SET or RESPONSE-SET, though the user telnet should not rely on that 👀.
  • SEND demands that the user telnet send RESPONSE-IS 📩.
  • IS and RESPONSE-IS tell the host telnet the current states of some or all of the user telnet's parameters 🍓. The user telnet sends IS when it changes a parameter for some local reason, like a request from the (human) user. An IS message may list all the parameters, but it doesn't have to. It might just list the ones that changed.

The user telnet sends RESPONSE-IS in answer to each SEND request from the host. Every RESPONSE-IS should list ALL X.3-PAD parameters known to the user telnet implementor, even the ones that can't be changed. Any host requests (SET or RESPONSE-SET) that arrive before a SEND should be processed before the answering RESPONSE-IS goes out, so their effects show up in the values listed there ⭐.

To keep everything in sync (which SEND is this an answer to?), the user telnet should count SEND messages and send exactly one RESPONSE-IS per SEND 🔢.

You might think this protocol could work with just SET, SEND and IS messages. But the seemingly redundant RESPONSE-SET and RESPONSE-IS codes are needed so both the user and host telnets can tell new peer requests apart from attempts to renegotiate earlier actions, while also preventing potential infinite negotiation loops 🔁.

SET and IS messages are sent when the host or user telnet wants to tell its peer about a change in the X.3 processing mode desired by some higher-level entity 🌈. This might happen at initialization, or on user or application-program request. The important thing is that these messages are NOT sent merely in response to another X.3-PAD message from the peer.

RESPONSE-SET and RESPONSE-IS should be sent in reply to a peer's [RESPONSE-]IS or SEND message. They reflect negotiation at the telnet level, not changes in the higher-level environment. A host that sends a SEND may complain about the status in the answering RESPONSE-IS by sending RESPONSE-SET but not SET 💬.

Under this scheme, one possible rule for preventing infinite negotiations would be for the host to send at most zero, one, or some fixed number of RESPONSE-SET messages after receiving one IS message or one higher-level host-side request. After that, the host telnet simply accepts the user telnet's last offer as well as it can 🫠. Only the host needs to worry about loop prevention, since it's the one doing all the asking.

A given parameter should not be listed more than once in a single message.

A sample negotiation might look like this. (Line breaks don't mean anything here. ASCII carriage returns and line feeds are shown as <CR> and <LF>, and everything else stands for itself. In the IAC SB octet values.) 🍿

         Host:   <CR><LF>%
                                          (User types "cd gibber<CR>")
         User:   cd gibber<CR><LF>
         Host:   Password required.<CR>LF>
                                               (Host disables echoing)
              IAC SB X.3-PAD SET 2 0 IAC SE
                                               (Host polls for status)
              IAC SB X.3-PAD SEND IAC SE
         User:                        (User telnet has disabled local
                                       echo.  Note that some
                                       parameters (e.g., 9, 10, 11)
                                       are not present, presumably
                                       unimplemented, and a few
                                       extension parameters
                                       (129, 134) in extension
                                       set 1 are also defined.)
               IAC SB X.3-PAD RESPONSE-IS 1 29 2 0 3 2 4 0 5 0 7 17 8 0
                                         12 0 13 3 15 1 16 8 17 21 18 0
                                         128 1 129 23 134 1 IAC SE
         Host:    password:
                                              (User types "squeak<CR>",
         User:    squeak<CR><LF>                  which is not echoed.)
         Host:                                (Host re-enables echoing)
                  IAC SB X.3-PAD SET 2 1 IAC SE
                                              (Host polls for status)
                  IAC SB X.3-PAD SEND IAC SE
         User:
                IAC SB X.3-PAD RESPONSE-IS 1 29 2 1 3 2 4 0 5 0 7 17 8 0
                                          12 0 13 3 15 1 16 8 17 21 18 0
                                          128 1 129 23 134 1 IAC SE

6. Parameters 🎀

In outline, the X.3-PAD option uses these parameters:

  • Parameter 0 indicates whether the user telnet tells the host about parameter changes made for local reasons 📝.
  • Parameters 1 through 22 are basically those of CCITT X.3, with some changes in interpretation. They're listed in detail below.
  • Parameters 23 through 127 are reserved for potential extensions to CCITT's X.3 definition 🔮.
  • Parameter 128 selects an "extension set", which decides what parameters 129 through 255 mean. One extension set is proposed in this RFC, and others may be added. The extension mechanism is explained under parameter 128's description.
  • Parameters 129 through 255 only mean something when they're defined in the extension set picked by the current value of parameter 128 ✨.

It should NOT be assumed that every implementation supports every parameter defined here, or every value of those parameters 🙅. Supported parameter/value combinations, however, should behave as described here.

The following parameter is specific to this Telnet option.

Parameter 0 -- Notify host of user-initiated parameter changes

  • Code 0 -- Host is not notified.
  • Code 1 -- User telnet notifies host by sending IS message.

If the user telnet changes a parameter for some local reason, should it send an IS message to the host? This is desirable, since the host telnet otherwise can't be sure of the user telnet's current status 🧐. On the other hand, some user telnets may be unable to send notification. Picture a user calling from an X.25 PAD through an X.25-to-telnet gateway. The user can change local PAD parameters freely, but normal PADs send no message when that happens, so the gateway can't tell the host telnet. Plus, some sloppy host telnets may not want to know about user parameter changes at all 🙄.

In normal usage, the host asks to SET parameter 0 to its preferred state on initialization. The user telnet accepts the setting if it can, and then the host polls (using SEND) for the user telnet's decision. A disappointed host might poll for changes periodically, nag the (human) user not to change parameters, or stay quiet and just work weirdly if changes get made 💀.

The following parameters are as defined by the 1984 CCITT X.3 standard.

Numbers are in decimal 🔢.

Parameter 1 -- Character to escape to local telnet command mode

  • Code 0 -- No ASCII character performs this function (though some special mechanism, e.g., a function key, still may).
  • Code 1 -- DLE (ASCII code 16).
  • Codes 32 through 126 -- ASCII code of the character.

Codes 2 through 31 aren't defined by X.3, but they might also be read as the matching ASCII control characters. X.3 seems unable to name SOH (control-A) as a command escape character 🙃.

Parameter 2 -- Local echo of characters typed by the user

  • Code 0 -- No local echo.
  • Code 1 -- Local echo.

There are several echoing styles 🪞. Parameter 13 picks whether a carriage return echoes as itself or as CR LF. Parameter 20 may suppress echoing of particular ASCII characters. The extension parameter 134 picks a style for echoing non-printing characters such as ESC 🎀.

Parameter 3 -- Set of forwarding characters 🦋

okay so this one is giving "pick your favourite characters and I'll wait" 💅 The value is bit-encoded, which means each nonzero bit picks out a set of characters. The user telnet collects characters from the user's keyboard into a buffer until it gets any of the specified characters (or until some other forwarding condition is met, see below), and only then sends the buffer to the host ✨

It's allowed to forward earlier if it has to, like if it runs out of buffer space 🙈 but it MUST eventually forward after it receives one of the indicated characters, no cap 🫶

Code 0 -- No forwarding characters.
Code 1 -- Alphanumeric characters (a-z, A-Z, 0-9).
Code 2 -- CR.
Code 4 -- ESC, BEL, ENQ, ACK.
Code 8 -- DEL, CAN, DC2.
Code 16 -- ETX, EOT.
Code 32 -- HT, LF, VT, FF.
Code 64 -- ASCII character codes 0 through 31 not listed above.

ngl, the big thing to know is that there's no way to forward on printable, non-alphanumeric characters (punctuation marks) here 💀 so punctuation just sits in the buffer vibing. You can add codes together to select the union of the sets, periodt 👑

Parameter 4 -- Forward after idle time ⏰

When this parameter is nonzero, the user telnet sends its input buffer to the host after a stretch where nobody types anything, even if no forwarding character showed up 🌸

Code 0 -- Infinite time limit.
Codes 1 through 255 -- Time limit in 1/20 second units.

The value "1" can be taken to mean "forward immediately" if timed input is a hassle to set up 🧚 For other values, if timing exists but the exact number you asked for doesn't, rounding up to larger delays is suggested. And if timing is requested but none is available, immediate forwarding on every character is much preferred over an infinite time limit, bestie 😭

Note the interaction with parameter 15, Local editing, and the notes made under that heading 🎀

Parameter 5 -- Flow control of user-to-host data 🌈

A user telnet can get overwhelmed by the stuff the user types 😩 If parameter 5 is 1, it may output X-OFF (DC3, ASCII code 19) to ask the user to pause input, and X-ON (DC1, ASCII code 17) when the user is allowed to start typing again.

Code 0 -- X-OFF and X-ON considered normal output data.
Code 1 -- X-OFF and X-ON used to control user input.

The extension parameters 130 and 131, if defined, can specify other codes to use instead of ASCII DC3 and DC1 ✨

Parameter 6 -- Not relevant here 🙈

Parameter 6, referring to messages sent from the PAD to the user, does not seem to be relevant in this context. Moving on, no drama 💅

Parameter 7 -- Function of Break, Interrupt, Attention, etc. 💥

This one handles some special key or other character on the user's keyboard, and what that character does is up to the implementation 🔑 It's bit-encoded, so you can add codes to select multiple functions, and those functions can run in any order. Any messages that get generated should be promptly sent to the host 📨

Code 0 -- No action.
Code 1 -- Send interrupt packet (Telnet IAC IP).
Code 2 -- Reset (break Telnet connection).
Code 4 -- Discard input from user not yet consumed by host.
Code 8 -- Escape to local Telnet command mode.
Code 16 -- Discard output from host (see parameter 8).

The X.25 'Interrupt', 'Reset', and 'Indication of Break' messages get translated to their Telnet equivalents here 🦋 See section 8 for suggestions on discarding input and output.

Parameter 8 -- Discarding output from host 🙉

This parameter is basically a flag that tells you whether host output is being ignored 🚫

Code 0 -- Host output is sent to user.
Code 1 -- Host output is discarded.

It's normally used together with parameter 7 when the 16's bit (Discard output on Break/Interrupt/Attention) is set. An implementation is suggested in section 8 of this RFC 🫶

Note that if a signal from the user changes parameter 8 and parameter 0 is set to 1, an X.3-PAD IS message should be sent to the host 📬

Parameter 9 -- Padding after carriage return 🍓

This parameter picks how many ASCII NUL padding characters get inserted after each carriage return 🧁

Codes 0 through 7 -- Insert that many padding characters.

Parameter 10 -- Line folding 📏

Output lines can get folded (for example, by inserting a carriage return and line feed) once they go past a set width ✂️

Code 0 -- No output line folding.
Codes 1 through 255 -- Fold lines after that many characters.

Parameter 11 -- Bit rate 🐢

This parameter tells you the serial data rate of the user's terminal, if there is one 🔌 CCITT X.3 treats this parameter as read-only, but it can be meaningful to let the host set it as well as read it, which means the host can change the user's line speed on the fly. Iconic behaviour, honestly ⚡

Code 0 -- 110 bps            Code 10 -- 50 bps
Code 1 -- 134.5 bps          Code 11 -- 75 bps in, 1200 out
Code 2 -- 300 bps            Code 12 -- 2400 bps
Code 3 -- 1200 bps           Code 13 -- 4800 bps
Code 4 -- 600 bps            Code 14 -- 9600 bps
Code 5 -- 75 bps             Code 15 -- 19200 bps
Code 6 -- 150 bps            Code 16 -- 48000 bps
Code 7 -- 1800 bps           Code 17 -- 56000 bps
Code 8 -- 200 bps            Code 18 -- 64000 bps
Code 9 -- 100 bps

Parameter 12 -- Flow control of host-to-user data 🌊

When this parameter is 1, the user may type X-OFF (DC3, ASCII code 19) to pause printing output, and X-ON (DC1, ASCII code 17) to get the output going again ▶️

Code 0 -- X-OFF and X-ON are sent as data to host.
Code 1 -- X-OFF and X-ON control output.

See also the extension parameters 130, 131 and 132 🎀

Parameter 13 -- Line feed insertion; Telnet CR LF vs CR NUL 🧩

Okay, this one is a whole thing, so buckle up 🫠 The CCITT uses this parameter to decide whether a typed CR gets sent as CR or CR-LF, whether an output CR gets a LF printed after it, and whether an echoed CR gets echoed with an LF tagging along. Here, it sorts out the mapping between the Telnet CR-LF sequence and single ASCII codes. Like, when the user hits the carriage return key, should CR LF or CR NUL go to the host? And when the host sends CR LF, should the user see CR LF or just CR? 🤔

The value is bit-encoded, and you can add codes to select multiple functions ✨

Code 0 -- No line feed insertion
               (typed CR sent as CR NUL; host CR LF printed as CR).
Code 1 -- Add line feed on output (host CR LF printed as CR LF).
Code 2 -- Add line feed on input (typed CR sent as CR LF to host).
Code 4 -- When echoing a typed CR locally, echo as CR LF.

Note the interaction with the TRANSMIT-BINARY Telnet option [5]. If the host has said WILL TRANSMIT-BINARY, then CR has no special meaning on output. It always stands for the single character CR, no matter what this parameter is set to. And if the user telnet has said WILL TRANSMIT-BINARY, a typed CR should likewise always be sent as itself, not as CR LF or CR NUL 💖

Parameter 14 -- Output padding after line feed 🌷

This gives the number of ASCII NUL padding characters to send to the user's terminal after each output line feed 🪶

Codes 0 through 7 -- Send that many padding characters.

Parameter 15 -- Local editing ✏️

If this parameter is 1, the character delete, line delete and line reprint functions (parameters 16, 17 and 18), if they're implemented, should be enabled 🛠️ Data should be sent to the host when a forwarding character (see parameter 3) gets typed, or in case the user telnet's input buffer becomes full.

Note the interaction with parameter 4, Forward after idle time. User telnets need not handle the case where idle-time forwarding and local editing are both enabled. In other words, the host should explicitly request changing parameter 4 to 0 along with setting parameter 15 to 1 🙌

Code 0 -- No input editing.  Any editing characters are considered
          data.
Code 1 -- Input editing.  Editing characters edit the input buffer.

Parameter 16 -- Character-delete character ⌫

While local editing (parameter 15) is enabled, typing this character erases the last character in the editing buffer, if there is one 🫧 When editing is disabled, this character doesn't get any special treatment.

Code 0 -- No character has this function.
Codes 1 through 127 -- ASCII code of character-delete character.

See also parameter 19.

Parameter 17 -- Line-delete character 🗑️

While local editing (parameter 15) is enabled, this character erases the entire contents of the editing buffer, all at once 💥 When editing is disabled, it doesn't get special treatment either.

Code 0 -- No character has this function.
Codes 1 through 127 -- ASCII code of line-delete character.

See also parameter 19.

Parameter 18 -- Line-display character 👀

While local editing (parameter 15) is enabled, typing this character prints the current contents of the editing buffer on the user's terminal. Nothing gets sent to the host, so it's just for the user to peek 🫣 When editing is disabled, this character isn't treated specially.

Code 0 -- No character has this function.

Codes 1 through 127 -- ASCII code of line-display character.

Parameter 19 -- Editing service signals 📣

This decides what gets echoed to the user when local editing is enabled and the character-delete or line-delete character is entered 🎙️

Code 0 -- Nothing is echoed.
Code 1 -- Editing style is suitable for printing terminals.
Code 2 -- Editing style is suitable for display terminals.
Codes 8 and 32-126 -- Echo that ASCII character for
          character-delete.

X.3 is very specific about handling character and line deletion 🧐 If parameter 19 is 1, character-delete echoes as a "line delete with three X's followed by CR LF. If it's 2, a character-delete echoes BS SPACE BS, while a line delete echoes enough BS SPACE BS's to erase the entire line. If it's 8 or 32-126, character-delete echoes that character, and line delete echoes XXX CR LF. An extension parameter could override these and select other styles if desired, though none is proposed here.

Parameter 20 -- Echo mask 🙈

When local echoing (parameter 2) is enabled, each nonzero bit in this bit-encoded parameter's value suppresses echoing of some subset of ASCII characters. Adding values suppresses echo for the union of the specified subsets 🪄

Code 0   --  all ASCII characters are echoed.
Code 1   --  CR is not echoed.
Code 2   --  LF is not echoed.
Code 4   --  VT, HT, and FF are not echoed.
Code 8   --  BEL and BS are not echoed.
Code 16  --  ESC and ENQ are not echoed.
Code 32  --  ACK, NAK, STX, SOH, EOT, ETB and ETX are not echoed.
Code 64  --  Editing characters are not echoed.
Code 128 --  other non-printing ASCII characters, and DEL, not
             echoed.

Nothing is echoed when parameter 2 is 0. Some characters should not be echoed regardless of parameter 20. If any of parameters 5, 12, or 22 are enabled (non-zero), then the XON and XOFF characters should not be echoed. Nor should the escape-to-local command mode character (parameter 1) be echoed 🚫

Parameter 21 -- Parity 🛡️

This parameter decides whether parity is checked on user input and generated on output to the user. You can add values to select both ✨

Code 0 -- Parity neither generated nor checked.
Code 1 -- Even parity checked on input.
Code 2 -- Even parity generated on output.

Parameter 22 -- Page wait.

okay so if this one is turned on 📖, the user telnet pauses after every N lines of output, like it just got an X-OFF 🛑. Output starts back up once you type X-ON ✨.

  • Code 0 -- No pause.
  • Codes 1-255 -- Pause after output of that many line feeds.

See also parameters 130, 131 and 132 🫶

These next ones aren't part of CCITT X.3 🧚, but they use the extension mechanism that was proposed for this Telnet option, so they're basically the extra-credit crew 💅.

Parameter 128 -- Extension set number.

This parameter picks one of a potentially large number of "extension sets" 🎀. Think of them as more or less coherent bundles of parameters bolted onto the basic X.3 family. A user telnet can support several extension sets at once 💖. The host MAY figure out whether a particular one is supported by trying to set parameter 128. The user telnet SHOULD accept the value if it provides some or all of the parameters in that set.

Extension sets could be made for things like Berkeley UNIX tty emulation, VMS emulation, Telenet's extended parameters, French national PDN parameters, and so on 🌈.

Initial values don't need to be specified for extension parameters. That means a host SHOULD explicitly negotiate for their values after picking a set 💅. It is RECOMMENDED that default settings give service that resembles normal CCITT X.3 behavior where possible ✨.

Extension sets are mutually exclusive. Different sets can use the same parameters (from 129 through 255) for different purposes 🦋.

Only one extension set is in effect at a time 👑. So if a host asks for service X from extension set A, then switches to extension set B and asks for its service Y, it SHOULD NOT expect that service X is still being provided. 🙈

Some values of this parameter are reserved:

  • Code 0 -- Null extension set. Only (a subset of) the basic CCITT X.3 parameters is provided. Every user telnet SHOULD accept this setting.
  • Code 1 -- (A subset of) the extension set 1 parameters described below is provided.
  • Code 255 -- Reserved for purely local (e.g., to a site), non-standard collections of extensions.

Other extension sets MAY be proposed and assigned set numbers in the range 2 through 254 🍓.

Set numbers are registered with the Internet Assigned Numbers Coordinator at USC-ISI. Please contact:

     Joyce K. Reynolds
     USC Information Sciences Institute
     Suite 1001
     4676 Admiralty Way
     Marina del Rey, CA  90292-6695

     213-822-1511   JKReynolds@ISI.EDU

Okay, now for the extension set 1 goodies 🎀✨.

Parameter 129, extension set 1 -- Word-delete character.

Typing this character while local editing is enabled erases the last word in the editing buffer. There are several definitions of a "word" in common use, and this RFC doesn't pick one 🤷‍♀️. There SHOULD be an indication to the user of what was erased. When editing is disabled, this character isn't treated specially.

  • Code 0 -- No character has this function.
  • Codes 1 through 127 -- ASCII code of word-delete character.

Parameter 130, extension set 1 -- Flow control OFF character.

Parameter 131, extension set 1 -- Flow control ON character.

Typing these characters while parameter 12 is enabled suspends or resumes output, respectively 🛑➡️✅. The user telnet MAY send them to the user while parameter 5 is enabled, to ask the user to cease or resume supplying input.

If defined, these parameters SHOULD have default values of 19 (ASCII DC3) for parameter 130, and 17 (ASCII DC1) for parameter 131 💜.

  • Code 0 -- No character has this function.
  • Codes 1 through 127 -- Function performed by that ASCII code.

Parameter 132, extension set 1 -- Host-to-user flow control convention.

Some flow control styles only accept a particular character (e.g., X-ON) to resume output. Others resume on receipt of any character 🤔. This parameter picks which one to use. The default SHOULD be zero, since this matches the X.3 convention.

  • Code 0 -- Resume output only when correct character is received.
  • Code 1 -- Resume output when any character is received.

Parameter 133, extension set 1 -- Alternate Attention, etc., character.

This character is a synonym for the Break, Attention, etc., key, whose function is given by parameter 7 🔑.

  • Code 0 -- No ASCII character has this function (there may still be a special key or other mechanism).
  • Codes 1 through 127 -- ASCII code of the character.

Parameter 134, extension set 1 -- Local echo style.

This parameter picks how non-printing characters get echoed when parameter 2 is set to 1 🪞. The default SHOULD be zero, where all characters are simply echoed as themselves (except possibly carriage return; see parameter 13).

  • Code 0 -- All characters echo as themselves.
  • Code 1 -- Non-editing control characters echo as ^X for some printable character X.

See also parameters 2, Local echo, and 20, Echo mask, which may suppress echo of some or all characters regardless of this parameter 🙅‍♀️.

Parameter 135, extension set 1 -- Accept following character as data.

After you type this character, the next character you enter is accepted as data for transmission to the host, even if it would normally have a special meaning 🎯.

The default SHOULD be zero.

  • Code 0 -- No character has this function.
  • Codes 1 through 127 -- ASCII code of the character.

Parameter 136, extension set 1 -- Character to toggle discarding output.

Typing this character flips the state of parameter 8 (discarding host-to-user output) between 0 and 1 🔁. So an indeterminate amount of host output, received between successive instances of this character, gets discarded.

As usual, the host SHOULD be notified of each change if parameter 0 is set to 1. The host might wish to send SET messages at appropriate points (e.g., preceding command prompts) to re-enable output 📨.

The default SHOULD be zero.

  • Code 0 -- No character performs this function (though another mechanism still may do so).
  • Codes 1 through 127 -- Typing that character toggles parameter 8.

Parameter 137, extension set 1 -- User-to-host bits per character.

Parameter 138, extension set 1 -- Host-to-user bits per character.

These parameters decide things like whether you get a full 8-bit input or output data path, or whether the most significant bit(s) of input or output data gets stripped 🧼. Typical values would be 7 or 8.

Note that an 8-bit data path doesn't, by itself, mean transparent input/output. CR -> CR LF translation, XON/XOFF interpretation, parity and so on MUST also be disabled to achieve this 🚫.

7. Subsets, Extensions and Conflicts ✨

An option this complex (and this easy to extend) needs a policy for which subsets and extensions are allowed, plus some recommendations for getting through a maze of partial implementations 🌀. So what does it even mean to say DO or WILL X.3-PAD? 🤨

A basic principle is that, since hardly any user telnet implementation will provide every possible feature, a host can't expect to get exactly any kind of service it wants 🥲.

[This may be an arguable point. The CCITT defines a mandatory subset of supported values for each X.3 parameter, with further values optional. For example, the set of forwarding characters, parameter 4, MUST accept at least the values 0 (none), 2 (carriage return), and 126 (any control character or DEL). Though it would be possible to adopt the CCITT's set of mandatory values there, I don't think that would be desirable for two reasons. First, some of the features specified (e.g., timed input) may be hard to implement in some environments, and may well not be necessary for many applications. Second, this option provides for definition of entirely new parameters. Unlike the X.3 case, one peer may use parameters whose very existence is unknown to the other. So one cannot specify mandatory or default values for ALL parameters.]

On the other hand, a host is at least entitled to know what kind of service is being provided to the ultimate user 👀. A user telnet's status report may be incomplete (not describing features its implementor did not know of). It may not describe the style of interaction the host (or user, or application) would wish for, but it SHOULD at least describe reality 💯.

For telnet parameters with a range of possible values, if a user telnet implements only one "enabled" and one "disabled" value, it SHOULD choose the "enabled" value when asked for a setting it can't supply 🫠. A VMS telnet, for example, might allow only DEL or nothing as the character-delete code. If a host asks it to use "backspace", it SHOULD choose DEL rather than nothing. The host MAY then interpret this contrary behavior as indicating a preferred value 🕵️‍♀️.

The problem of conflicting parameters is a serious one 😭. That's where several parameters control overlapping services and may conflict. The extension set scheme (see parameter 128) is meant to limit the problem 🧹. Each extension set's parameters SHOULD be selfconsistent and consistent with the CCITT X.3 parameters, but separate extension sets needn't worry about each other's parameters.

Where parameters might conflict, it's important to specify priority as part of the parameters' description 📋. For example, among parameters 2 (Local echo), 20 (Echo mask), and extension set 1's 134 (Local echo style), Echo mask only matters if Local echo is enabled, and Local echo style only applies to characters selected for echoing by the first two parameters 🧠.

This option's functions overlap with those of some existing Telnet options. For example, ECHO (which can be interpreted to affect local echo and possibly local line editing), NAOCRD and NAOLFD [6] (specifying padding after output carriage returns and line feeds), TRANSMIT-BINARY, Remote Controlled Transmission and Echo [3], and SUPDUP [4] 🔁.

Where X.3-PAD completely subsumes the function of another option, as for ECHO, NAOCRD and NAOLFD, it's probably best to let the X.3-PAD option, where acceptable to both sides, supplant them, and to refuse the other option 🙅‍♀️.

The TRANSMIT-BINARY option can change (actually suppress) the interpretation of some bits of parameter 13 related to Telnet newline encoding, as mentioned under that parameter. As such, it's compatible with this option but MUST be kept in mind 🧠💭.

RCTE would be a much more difficult case, since its service doesn't fit into this option's scheme and vice versa. However, it probably is unimportant because of the scarcity of RCTE implementations 🥹.

Some existing Telnet options can serve related but complementary functions, for example NAOHTS [7] for output tab handling, or TERMINAL-TYPE [8] 🌸.

8. Implementation suggestions 🛠️✨

It is strongly recommended that a user telnet support at least the combination with parameters 2=0, 3=126, and 4=1 (no local echo, forward immediately or nearly so on any input character) so that a dissatisfied host has the option of backing off and doing its own character handling. 🫶 Keep this combo around so the host can take over the character handling if it's not vibing with the defaults. Main character energy for the host 👑

The "discard output" function, which gets invoked by the Break, Interrupt, Attention, etc., key if the 16's bit is set in parameter 7, may be implemented as follows. 🙈

  1. When the key is pressed, set parameter 8 to 1, begin discarding output, and send IAC SB X.3-PAD IS 8 1 IAC SE to notify the host. (It may not need to know, but the message should be sent for consistency.) 💅
  2. Send IAC DO TIMING-MARK. 🧚
  3. Send any other messages associated with the key (e.g., IAC IP). 🎀
  4. Eventually, the host should send either IAC WILL TIMING-MARK or IAC WON'T TIMING-MARK, even if it knows nothing about the TIMING-MARK option. It will probably appear close, in the output stream, to the point where the host recognized any associated messages (e.g., IP). 🦋

When the TIMING-MARK arrives, reset parameter 8 to 0 and cease discarding output. Send IAC SB X.3-PAD IS 8 0 IAC SE. ✨

The Telnet SYNCH mechanism (see [2]) may be employed in concert with such a scheme. A closed-loop flush, though, will be more effective at discarding excess output than SYNCH used alone. Provision of some such mechanism for discarding unwanted output, e.g., after interrupting the host, is heartily recommended. 💖

Discarding input is less clear cut. 🤔 Certainly, any buffered data not yet sent should be discarded. One might also use SYNCH to encourage the host telnet to discard more.

9. References 📚

  1. Recommendation X.3, from International Telecommunications Union CCITT Red Book, volume VIII, fascicle VIII.2, 1984.
  2. Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC-854, USC Information Sciences Institute, May 1983.
  3. Postel, J., and D. Crocker, "Remote Controlled Transmission and Echoing Telnet Option", RFC-726 and NIC-39237, SRI-ARC, March 1977.
  4. Crispin, M., "SUPDUP Protocol", RFC-734 and NIC-41953, SU-AI October 1977; Crispin, M., "Telnet SUPDUP Option", RFC-736 and NIC-42213, SU-AI, October 1977; also Greenberg, B., "Telnet SUPDUP-OUTPUT Option", RFC-749 and NIC-45499, MIT-Multics, September 1978.
  5. Postel, J., and J. Reynolds, "Telnet Binary Transmission Option", RFC-856, USC Information Sciences Institute, May 1983.
  6. Crocker, D., "Telnet Output Linefeed Disposition Option", RFC-658 and NIC-31161, UCLA-NMC, October 1974; and "Telnet Output Carriage Return Disposition Option", RFC-652 and NIC-31155, UCLA-NMC, October 1974.
  7. Crocker, D., "Telnet Output Horizontal Tab Stops Option", RFC-653 and NIC-31156, UCLA-NMC, October 1974. [RFC numbers 652 through 658 (NIC 31155 through 31161) are in a similar vein.]
  8. Solomon, M., and E. Wimmers, "Telnet Terminal Type Option", RFC-884, University of Wisconsin - Madison, December 1983.
that's the whole doc bestie 🎀 the references are where the real lore lives 📚
📦 where this page comes from