RFC 933

Output marking Telnet option

📅 published January 1985, from ietf

RFC 933: OUTPUT MARKING TELNET OPTION 💖

  • Series: Network Working Group 🫶
  • Number: RFC 933
  • Author: S. Silverman, MITRE-Washington ✨
  • Date: January 1985 📅
  • Category: not listed in the header 🤷‍♀️
  • Obsoletes / Updates: neither is listed in the header 🙈

Status of this Memo 📣

okay so this one proposes a new option for Telnet for the ARPA-Internet community, and it's literally asking everyone for discussion and suggestions for improvements 🗣️ distribution of this memo is unlimited, so share it with your whole group chat 🌈

Overview 🦋

this proposed option would let a Server-Telnet send a banner to a User-Telnet, so the banner shows up on the workstation screen no matter what application is running in the Server-Telnet 💜 the banner just lives on your screen, iconic ✨

1. Command Name and Code 🎀

the command is called OUTMRK and its code is 27 💅

OUTMRK    27

2. Command Meanings 💅

these are the sequences you'll see, and what each one means 🔥

IAC WILL OUTMRK

the sender is willing to send output marking information in a subsequent sub-negotiation 🫶

IAC WON'T OUTMRK

the sender refuses to send output marking information 💀

IAC DO OUTMRK

the sender is willing to receive output marking information in a subsequent sub-negotiation ✨

IAC DON'T OUTMRK

the sender refuses to accept output marking information 🙅‍♀️

IAC SB OUTMRK CNTL data IAC SE

the sender asks the receiver to use the data in this subnegotiation as a marking for the normally transmitted Telnet data until further notice 🍓 the CNTL octet tells you where the marking goes (more on that below) 🧚

IAC SB OUTMRK ACK IAC SE

the sender acknowledges the data and agrees to use it for output marking (see below) 🩷

IAC SB OUTMRK NAK IAC SE

the sender objects to using the data for output marking (see below) 😤

3. Default 🌸

both of these are the defaults, and they're the same vibe: no output marking information gets exchanged 💜

WON'T OUTMRK

output marking information will not be exchanged 🙃

DON'T OUTMRK

output marking information will not be exchanged 🙃

4. Motivation for the Option 🧚

some military systems have a security architecture that attaches a security level to each Telnet connection 🛡️ which means they need to show a security banner on visual display devices, obviously 👀 (Reference: Department of Defense Trusted Computer System Evaluation Criteria, Section 3.1.1.3.2.3, Labeling Human-Readable Output.)

right now the banner gets sent as data inside every single screen of data, which is kinda wasteful 😭 it'd be way more efficient to send the data once, with instructions, and let User-Telnet keep the banner up automatically with no extra work from the Server-Telnet 🌟 this also means the Server-Telnet doesn't have to know the output device page size, which is a whole mood 🫶

under this proposal, the Server-Telnet sends an option sequence containing the command, a control flag, and the banner to use 🎀 current systems put the banner at the top of the screen, but other systems might want it at the bottom or even the side, and that's exactly why the control flag exists 🌈

5. Description of the Option 👑

either side of the session can start the option, but normally it's the server side that kicks off the request to do output marking 💖 so either the Server-Telnet sends WILL OUTMRK, or the User-Telnet sends DO OUTMRK. whichever party gets the first WILL (or DO) replies with DO (or WILL) to accept the option ✨ then the Server-Telnet sends the marking data, in this format:

IAC SB OUTMRK CNTL data IAC SE
  • CNTL is the Control Flag, described below
  • the data is in ASCII 🔤

if that works for the User-Telnet, it replies like this:

IAC SB OUTMRK ACK IAC SE

ACK is the ASCII ACK (6) ✅

from this point on, the User-Telnet has to translate any command that uses cursor controls so the application data gets mapped onto the application part of the screen 🧠

if the data in the subnegotiation field is unacceptable to the User-Telnet, it replies with this:

IAC SB OUTMRK NAK IAC SE

NAK is the ASCII NAK (21) 😬

now it's up to the Server-Telnet to start the whole sequence over and try more acceptable data (or it could take other action, like terminating the connection) 💔

to end output marking, the Server-Telnet sends WON'T OUTMRK 🧹

if it's needed, the User-Telnet can tell the Server-Telnet about the new effective page size. then the User-Telnet maps the output data onto the usable space on the screen 📐

the User-Telnet may request OUTMRK data or start setting up this convention at anytime by sending DO OUTMRK 🙋‍♀️ if a WILL, DO OUTMRK exchange isn't followed by the OUTMRK subnegotiation of the marking data, the User-Telnet may end the output marking option by sending DON'T OUTMRK 🛑

Control Flag 🚩

the CNTL flag is defined as:

  • D = Default. The placement of the markings is up to the User-Telnet. This is the expected mode for most interactions 💜
  • T = Top. This banner is to be used as the top of the screen. If you want multiple output markings, then T and B (or R & L) are to be used 🔝
  • B = Bottom. This banner is to be used at the bottom of the screen 🔽
  • L = Left. Markings on the left. (The precise meaning of this is to be defined.) ⬅️
  • R = Right. Marking on right. (The precise meaning of this is to be defined.) ➡️

a Carriage Return and Line Feed (CRLF) is interpreted as an end of line in the marking banner text 📝 if the user wants a multiline banner, they put a CRLF between each line 🌸 there's no CRLF needed at the end of the marking data 🙌

to use multiple banners, all of them go into one subnegotiation command, in this form:

IAC SB OUTMRK CNTL data GS CNTL data IAC SE

where GS is the ASCII Group Separator (29) character 💫

the User-Telnet is responsible for positioning the marking banner data on the screen 🫶🦋

📦 where this page comes from