RFC 1921
TNVIP Protocol
Status of this Memo ✨
okay so this memo is just giving info to the Internet community 🌸 it is NOT a standard of any kind, and you can share it as much as you want (distribution is unlimited) 💖
Abstract 🫶
the goal here is a Telnet profile that lets VIP terminals emulate and reach BULL host applications over a TCP/IP network 🖥️✨ basically it makes Telnet speak VIP so the terminal can get to the BULL hosts 💅
Table of Contents 📚
1. Motivation . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . 3
3. Telnet Options and Commands Used . . . . . . . . . . . 3
3.1. Terminal type option . . . . . . . . . . . . . . . . 4
3.1.1. Subnegotiation of the Terminal Type . . . . . . . . 4
3.1.2. Terminal-types supported by the TNVIP protocol . . 4
3.1.3. TNVIP terminal models . . . . . . . . . . . . . . . 5
3.1.4. Mailbox name . . . . . . . . . . . . . . . . . . . 5
3.2. End of Record Option . . . . . . . . . . . . . . . . 6
3.3. Binary Transmission option . . . . . . . . . . . . . 6
3.4. Suppress Go Ahead option . . . . . . . . . . . . . . 7
4. TNVIP functions . . . . . . . . . . . . . . . . . . . 8
4.1. TNVIP terminal station . . . . . . . . . . . . . . . 9
4.1.1. Local and online states . . . . . . . . . . . . . . 9
4.1.2. Data receiving . . . . . . . . . . . . . . . . . 10
4.1.3. Data sending . . . . . . . . . . . . . . . . . . 10
4.2. TNVIP Server functions . . . . . . . . . . . . . . 10
4.2.1. VIP Terminal Manager . . . . . . . . . . . . . . 10
5. TNVIP Messages Format . . . . . . . . . . . . . . . 12
5.1. Address Field . . . . . . . . . . . . . . . . . . . 12
5.2. Command field . . . . . . . . . . . . . . . . . . . 13
5.3. Parameter field . . . . . . . . . . . . . . . . . . 14
6. The screen flow . . . . . . . . . . . . . . . . . . 14
6.1. Screen data messages . . . . . . . . . . . . . . . 14
6.2. Local state monitoring messages . . . . . . . . . . 15
6.3. Screen response messages . . . . . . . . . . . . . 16
6.3.1 Page overflow processing . . . . . . . . . . . . . 17
6.4. Screen data purge indication message . . . . . . . 17
7. The printer flow . . . . . . . . . . . . . . . . . . 17
7.1. Printer data messages . . . . . . . . . . . . . . . 17
7.2. Printer response messages . . . . . . . . . . . . . 18
7.3. 7800 printer status management . . . . . . . . . . 19
7.4. Printer state request message . . . . . . . . . . 20
7.5. Printer state response messages . . . . . . . . . . 20
7.6. Printer purge indication message . . . . . . . . . 20
8. The Screen Copy Printing flow . . . . . . . . . . . 21
8.1. Screen copy request messages . . . . . . . . . . . 21
8.2. Screen copy data message . . . . . . . . . . . . . 21
8.3. Screen copy response messages . . . . . . . . . . . 22
8.4. Screen copy purge indication message . . . . . . . 23
9. The TM attention . . . . . . . . . . . . . . . . . . 23
10. The Break Key . . . . . . . . . . . . . . . . . . . 24
11. The Logout Key . . . . . . . . . . . . . . . . . . . 24
12. TNVIP messages list . . . . . . . . . . . . . . . . 24
12.1. Screen Flow . . . . . . . . . . . . . . . . . . . . 24
12.2. Printer flow . . . . . . . . . . . . . . . . . . . 26
12.3. Screen Copy Printing messages flow . . . . . . . . 28
13. Security Considerations . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . 30
15. Author's Address . . . . . . . . . . . . . . . . . . 301. Motivation 🌈
P200 [7] and 7800 [8] VIP (Visual Information Projection) terminals are different from NVT terminals [1] mainly because they work in block mode and can manage an attached printer 🖨️✨ in a DSA (Distributed Systems Architecture) network they're controlled over the VIP transmission line procedure, which is character oriented 💜 that's why they're called VIP terminals in general 🧚
this doc spells out the options you need to change, so a connection can go from NVT terminal emulation over Telnet to VIP terminal emulation 🦋 it also defines the format of the messages the server and client swap once TNVIP has been successfully negotiated 💌
2. Background 🌸
the VIP terminal family is huge, with lots of different terminal types 💅 they work in block mode using ASCII or 8 binary bits worth of characters 🔥
Bull terminals in a DSA network use a Terminal Manager (TM) [2] 🧠 it usually lives in a communication processor (like a Datanet or Mainway system), where it keeps the connection to the BULL host application going, usually through a DSA session 🫶
the Terminal Manager is in charge of presenting the terminal station and managing the session connection to the host 👑 it generally gives you a way to talk to the terminal so the user can change connection parameters and manage the session (connection request, abort, etc.) ✨ the set of commands and responses used for that is called "TM Local Dialog" 💖
3. Telnet Options and Commands Used 🎀
the mandatory telnet parameters that the "TNVIP server" and "TNVIP client" have to negotiate successfully are:
- the Terminal-Type option [3], to define a VIP terminal model and, if needed, a Mailbox name to request a specific access point in the "TNVIP server" 🍓
- the End Of Record option [4], to delimit the TNVIP message at the Telnet level. Since the End Of Record (EOR) code marks the end of an actual data unit, Telnet should attempt to send the data up to and including the EOR code together, to promote communication efficiency 🚀
other Telnet parameters can be optionally negotiated, like:
- the Binary Transmission option [5], when the terminal emulation uses an 8 binary bits set of characters 💜
- the Suppress Go Ahead option [6], when no synchronisation of data transmission from the "TNVIP client" with the DSA session turn or the ISO session token is needed 🦋
when the two parties (the "TNVIP server" and the "TNVIP client") have successfully negotiated a TNVIP terminal type and the EOR telnet option, that means they agree to follow the TNVIP protocol (the TNVIP message format and the exchange rules) 🫶💅
3.1 Terminal type option 🧚
IAC DO TERMINAL-TYPEthe Sender (the "TNVIP server" party) is willing to receive terminal type information in a later sub-negotiation 💖
IAC WILL TERMINAL-TYPEthe Sender (the terminal "TNVIP client" party) is willing to send terminal-type information in a later sub-negotiation ✨
3.1.1 Subnegotiation of the Terminal Type 🌷
IAC SB TERMINAL-TYPE SEND IAC SEthe Sender (the "TNVIP server" party) asks the receiver to send its next terminal-type, and to switch emulation modes (if more than one terminal type is supported) 🔄
IAC SB TERMINAL-TYPE IS tnvip-terminal-model@MB-name IAC SEthe Sender (the terminal "TNVIP client" party) states the name of its current (or only) terminal-type 💜 optionally, a mailbox name can be added to request a particular access point in the "TNVIP server". by default, the "TNVIP server" uses a generic access point 🌈
3.1.2 Terminal-types supported by the TNVIP protocol 💌
the TNVIP terminal type string given during Telnet negotiation is formatted like this:
<TNVIP-terminal-model> [ <@ character> <Mailbox-name> ]the @ character is the separator between the VIP-terminal-model and the Mailbox-name 🎀
3.1.3 TNVIP terminal models 🍒
the valid TNVIP terminal models are these ASCII character strings. (the table gives, for each terminal model string, the hexadecimal number of the matching DSA model number defined in the DSA terminal presentation protocols 📋)
P200 family 7800 family
-------------------------------- --------------------------------
! TNVIP model ! DSA code ! ! TNVIP model ! DSA code !
-------------------------------- --------------------------------
! VIP7700 ! 33 ! ! VIP7804 ! 3E !
! VIP7760 ! 3A ! ! VIP7804V ! 4A !
! DKU7005 ! 3D ! ! VIP7814 ! 47 !
! DKU7007D ! 40 ! ! HDS7 ! 4D !
! DKU7105 ! 41 ! ! VIP8800 ! 4F !
! DKU7107D ! 42 ! --------------------------------
! DKU7211 ! 45 !
! DKU7211D ! 4E !
--------------------------------the D at the end of a model string means the terminal supports the Remote Forms function [9] 🧾 that's the ability to store forms in the terminal, so the host application can display a stored form by sending a short-length command instead of sending all the form's data 💫 this function is usually supported by terminal concentrators 🖥️
3.1.4 Mailbox name 🦋
the mailbox name lets the "TNVIP client" ask for a specialized access point that's referenced by this name in the "TNVIP server" 💖 it's an ASCII character string, and including it in the Telnet terminal type string is optional. when it's not there, the "TNVIP server" can give a generic (default) access instead 🫶
when the "TNVIP server" is a gateway to DSA hosts, the mailbox name defines the DSA session access point of the terminal in the server 🌸 its length is limited to 12 characters 🙈 lower case characters are allowed, but they get processed as upper case 🔠 this string is usually used to identify a specific terminal station (one with a printer, for example), or to use a particular declaration of that terminal in the "TNVIP server" 👑
3.2 End of Record Option 🌊
VIP device communications are block oriented 🧱 each partner buffers data until a whole "message" has been built, and only then sends it to the other side 📦 the end of a message is understood to be the last byte transmitted 💅 the Telnet EOR command is used to delimit these natural blocks of TNVIP data inside the Telnet data stream ✨ an <EOR> is sent at the end of each TNVIP message, in both directions 💖
IAC WILL END-OF-RECORDthe sender of this command asks for permission to begin transmitting the Telnet END-OF-RECORD (EOR) code when transmitting data characters, or the sender confirms that it will now start transmitting EORs with its data characters 🙌
IAC DO END-OF-RECORDthe sender of this command asks that the sender of data starts transmitting the EOR code when transmitting data, or the sender confirms that the sender of data is expected to transmit EORs 🌈
3.3 Binary Transmission option 🦋
Okay so, depending on the character set the emulation is using, the "TNVIP client" and the "TNVIP server" can be led to negotiate the Telnet binary transmission option. Binary mode, bestie! 💜
If either side wants to send the decimal value 255 and have it read as data, it must "double" this byte. In other words, a single 255 gets read by the other side as an IAC, while two 255s in a row get treated as one data byte with a value of 255. Plot twist, right? 😭
Here's how the three-ish main commands play out:
IAC DO TRANSMIT-BINARYThe sender is asking the sender of the data to start transmitting, or confirming that the data sender is expected to transmit characters that the receiver should interpret as 8 bits of binary data. ✨
IAC WILL TRANSMIT-BINARYThe sender is asking permission to begin transmitting, or confirming that it will now begin transmitting binary data. 🌸
IAC WON'T TRANSMIT-BINARYIf the connection is already running in binary transmission mode, the sender of this command demands to start transmitting data characters that the receiver should interpret as standard NVT ASCII characters. If the connection is not already in binary mode, the sender is refusing to start transmitting characters that the receiver would interpret as binary. (In other words, the data sender wants to keep transmitting in its current mode.) Main character energy, no cap. 💅
IAC DON'T TRANSMIT-BINARYIf the connection is already in binary transmission mode, the sender of this command is asking the data sender to start transmitting characters that the receiver (aka the person sending this command) should interpret as standard NVT ASCII characters. If the connection is not already in binary mode, the sender is asking the data sender to keep transmitting in the mode it's already using. 🎀
3.4 Suppress Go Ahead option 🧚
The "TNVIP client" can use receiving the Telnet GoAhead command as the signal that lets the terminal operator transmit data. This can keep the data coming from the terminal in sync with the DSA "turn". Iconic synchronisation moment. 🫶
When the Suppress Go Ahead option is not negotiated, the "TNVIP server" must send the Telnet Go Ahead command (GA) when its input message queue (the one filled by the "TNVIP client") is empty and the DSA turn is on the terminal side. This invites the terminal to transmit some data. 💌
To turn that mechanism off, the "TNVIP client" can ask the "TNVIP server" not to send Telnet GoAhead commands, by negotiating the Suppress GO Ahead option of the Telnet Protocol. 🙈
In that case, the terminal's transmission to the "TNVIP server" is synchronised on the transport credit. ✨
Note: The Telnet GA command never need to be sent by the "TNVIP client" even if the telnet Suppress Go Ahead has not been negotiated. 💀
Here are the four commands for this option:
IAC DO SUPPRESS-GO-AHEADThe sender of this command (the "TNVIP client" party) is asking the data sender to start suppressing GA when it transmits data. 👑
IAC WILL SUPPRESS-GO-AHEADThe sender of this command (the "TNVIP server" party) confirms that it will now begin suppressing GA transmission with its data characters. 🌈
IAC DON'T SUPPRESSS-GO-AHEADThe sender of this command (the "TNVIP client" party) is asking the receiver of the command to start transmitting GAs when it transmits data. 🍓
IAC WON'T SUPPRESS-GO-AHEADThe sender of this command (the "TNVIP server" party) confirms that it will now begin transmitting the GA character when it transmits data characters. 💖
4. TNVIP functions ✨
The TNVIP protocol lets you do all of these fun things: 🌸
- Support a VIP terminal emulation that addresses the screen and its associated printer.
- Select the terminal type model when the connection is made.
- Get specific or generic access to the "TNVIP server", by referencing a Mailbox name or not.
- Keep TNVIP independent of the terminal data presentation protocol (7800 or P200), so it's not tied to one of them. Flexible, bestie! 🦋
- Support the DSA End To End Acknowledgement.
- Support the DSA Terminal Manager local attention.
- Support the DSA turn to the terminal side.
- Support the DSA secret read.
- Control the hard copy.
4.1 TNVIP terminal station 💻
The "TNVIP client" acts as the interface adapter between the TNVIP connection and an application program. It's mainly defined to support a VIP terminal emulation program, but other programs that use the TNVIP protocol can use it too. 💜
A VIP terminal emulation manages:
- a screen buffer,
- a printer buffer if it supports the associated printer,
- the interface with the communication line
and runs by the following rules:
When the VIP terminal emulation exchanges a message on the communication line, it is in the BUSY state until the message exchange ends. That means that while the VIP terminal is sending a message it can't receive, and while it's receiving a message it can't send. Just like a phone call, you can't talk and listen at the same time (without getting awkward) 🙈
Note: If a VIP terminal works in half duplex mode, the TNVIP protocol uses a Telnet connection, which allows full duplex mode processing. Lowkey a plot twist! 🔥
4.1.1 Local and online states 🌙
The VIP terminal can switch between these two states. The LOCAL state is generally used to run local terminal tests or to change the configuration. In this state, data coming from the line is ignored. 🙃
The LOCAL state lets the "TNVIP client" ask the server to suspend the screen and printer data flows.
The ONLINE state indication lets the "TNVIP server" resume the screen and printer flows. ✨
For these reasons, the TNVIP protocol tells the screen and printer flows apart from the screen copy printing flow, and it defines a way to report the two states to the "TNVIP server". 🎀
4.1.2 Data receiving 📥
When a VIP terminal emulation receives a data message from the line, it sends the data to the screen buffer or the printer buffer, depending on the address in the header message. 💌
A message received at the screen or printer address is deleted and ignored if the terminal emulation is in the LOCAL state, and a BUSY status is returned. 🫠
The printer buffer is busy while the terminal is transmitting data from the printer buffer to the printer device. A data message for the printer is deleted and ignored if the terminal is in the printing state, and a BUSY status is returned. 🖨️
When a BUSY state is encountered, the "TNVIP client" decides, based on the type of message received (request or indication), whether or not to report the BUSY acknowledgement to the "TNVIP server". Choices, choices! 💅
4.1.3 Data sending 📤
A VIP terminal emulation can send a message even if the terminal is in the LOCAL state. Bestie, it's giving freedom! 🦋
4.2 TNVIP Server functions 🖥️
4.2.1 VIP Terminal Manager 👑
Its job is to act as a gateway between the VIP terminal and the VIP application. Usually the application is a remote DSA application. 🌐
It manages the screen and printer devices of the VIP terminal station.
In the following example figure, the "TNVIP server" is a DSA server and manages three VIP terminal units: TU1, TU2 and TU3. Let's look at the diagram, obsessed 😭
Generic access
--------------
!----> LD 1S ----> DV 1S (screen) ---->!
MB 1 --> SN 1 TU 1
!----> LD 1P ----> DV 1P (printer) ---->!
Specific accesses
-----------------
!----> LD 2S ----> DV 2S (screen) ---->TU 2
MB 2 --> SN 2
!----> LD 2P ----> !
!
!----> LD 3P ----> DV 3S (printer) ---->!
MB 3 --> SN 3 TU 3
!----> LD 3S ----> DV 3P (screen) ---->!Each Terminal Unit (TU object) is declared as containing one or two devices (DV objects). The Terminal Manager maps this physical setup to a logical one, where the station (SN object) is the logical representation of a terminal unit, and the logical device (LD) object is the logical representation of the real device. Layers, bestie! 🧅
- TU1 is chosen by default for a generic request (without a mailbox name), or by addressing the MB1 name for a specific request. It can manage the associated printer device. 🎀
- MB2 is addressed to access the TU2 terminal unit. TU2 is defined in a special way, because it's presented to the host application as a station made up of a screen (the TU2 one's) and a printer (the TU3 one's). ✨
- MB3 is addressed to access the TU3 terminal unit. TU3 is also defined in a special way, because its printer device is shared by several logical stations (SN2 and SN3), so it has to be clearly identified. 🌈
5. TNVIP Messages Format 💌
Each TNVIP message is delimited by the Telnet EOR command. ✨
So a TNVIP message has the following format:
<TNVIP Header> <parameters> <IAC EOR>The TNVIP header is mandatory and has a fixed length of two bytes. 🔥
Some TNVIP messages don't need any parameters. In that case, the TNVIP message is built like this:
<TNVIP Header> <IAC EOR>It is strongly recommended that Telnet commands (other than IAC IAC) be sent between TNVIP messages, with no TNVIP header and no trailing IAC EOR. If a TNVIP data message containing any other IAC-command sequence (other than IAC IAC) is received, it is implementation dependent when that IAC-command sequence gets processed, but it must be processed. The receiver may process it immediately, which in effect causes it to be processed as if it had been received before the current TNVIP message, or the processing may be deferred until after the current TNVIP message has been processed. 🫨
Because of this ambiguity, having Telnet commands inside a TNVIP message is not recommended, so neither "TNVIP client"s nor "TNVIP server"s should send such data. Keep it clean, babe! 🧼
The TNVIP header contains 2 bytes. The first one indicates the address <ADR>, and the second one indicates the command <CDE>. 💖
5.1 Address Field 📮
The <ADR> address field is mandatory and is defined on one byte. 🌷
The TNVIP protocol defines 3 addresses:
- ADR = SCREEN = 96 (0x60) for the screen commands flow,
- ADR = PRINTER = 104 (0x68) for the printer commands flow,
- ADR = SCPM = 105 (0x69) for the screen copy printing commands flow.
A request message with an unknown or unsupported address will be discarded by the receiver, which replies with a NOT-AVAILABLE response message. Ghosted, and it's giving rejection 💀
5.2 Command field ✨
okay so the <CDE> command field is mandatory 💅 and it's exactly one byte, no more, no less. bestie, this byte is literally the boss of the message. Its layout looks like this:
<Command-Type><Message-Type>- The Command-Type fills the six most significant bits of the
<CDE>byte. The most significant bit is always0. Its value ranges from0to31included, and it defines the command associated to the message for the flow identified by the address field. 🦋 - The Message-Type fills the two less significant bits of the
<CDE>byte. There are four flavours:0= Indication message. No response message is expected. An indication message with an undefined command type or with an unknown address is deleted and ignored. 🫶1= Request message. The sender of a request message is waiting for a response message having the same address value. When a request message is sent for a given address, it is not allowed to send another request to the same address before the receiving response. If an end point receives a request before having sent the response of the previous request, it deletes the second request but has to send back a PROTOCOL-VIOLATION response after the response of the first request. A request message with a not defined address is replied to by a NOT-AVAILABLE response message. A request message with an unknown or unsupported command<CDE>for this address will be deleted by the receiver and replied to by an UNKNOWN-COMMAND response message. 🙈2= Response message. This message is the response to the current request message. The receiver of this message is allowed to send another request message on the flow defined by the ADR field. 💖3= Response and request message. This message is a positive response to the current request message sent by the receiver, but is also a request message. 🔥
The following table gives the <CDE> commands list with their hexadecimal values. the vibes are very organised here 🍓
Command Indication Request Response Resp/Req
--------------------------------------------------------
DATA 00 01
PASSW 04 05
ACK 0A
ERROR 0E
BUSY 12
ABORTED 16
PURGED 1A
NOT-AVAILABLE 1E
PROTOCOL-VIOLATION 22
UNKNOWN-COMMAND 26
PURGE 28
LOCAL-STATE 2D
ONLINE-STATE 30
STATE-REQ 35
READY 3A
STANDBY 3E
COPY-REQ 41
LOCAL-COPY 475.3 Parameter field 🎀
This field has a variable length, and what's in it depends on the two previous fields (address and command). it's giving "it depends on the vibe" energy 🌸
6. The screen flow ✨
All the following messages contain the value SCREEN = 96 (0x60) in the ADR field. the screen is the main character here 👑
6.1 Screen data messages 💻
These messages are defined to carry, in the parameter field of the TNVIP message, the data in the terminal presentation negotiated by the "Terminal Type" telnet command.
The parameter has the following format:
<FC1> <FC2> <STX> < screen data>- The FC1 and FC2 bytes are the function codes of the VIP procedure transmission [9]. Their values are comprised between
32 (0x20)included and127 (0x7F)included. ✨ - The STX byte is defined by the value
2and acts as the introducer of the screen data. 🧚
A screen data message can be sent in a request or in an indication message. The command values are defined as follows:
<CDE> = DATA indication = 0
<CDE> = DATA request = 1
<CDE> = PASSWORD indication = 4
<CDE> = PASSWORD request = 5Generally, the "TNVIP server" only sends indication messages to the screen. The request message is used mainly for the printer device. But a DSA/TNVIP gateway server should use the screen data request message when it processes a DSA end to end acknowledgement request from the DSA application, and it synchronizes the response message receipt with the DSA end to end acknowledgement. 🫶
The password request and the password indication message are defined to be used by the programs in the "TNVIP client" machine which don't emulate a terminal. That way, they know a secret read (password acquisition) has been requested by the "TNVIP server". When the program is a terminal emulation, this information isn't necessary, because the data contains the terminal presentation command to request this secret read. 🔐
6.2 Local state monitoring messages 🌈
Before switching into the local state, the "TNVIP client" sends a LOCAL-STATE request message to the "TNVIP server". This last one sends back an acknowledgement message and suspends the screen and printer data flow until it receives a LINE-STATE indication message. the handshake is giving polite bestie energy 🤝
Note: In the local state, only the messages from the "TNVIP server" to the screen or printer devices are deleted. The messages from the "TNVIP client" screen device, or the messages associated to other addresses, are allowed. 💅
The following command values are defined as:
<CDE> = LOCAL-STATE request = 45 (0x2D). It is sent by the "TNVIP client". There is no parameter field.<CDE> = ONLINE-STATE indication = 48 (0x30). It is sent by the "TNVIP client" to indicate the "TNVIP server" is allowed to resume the screen data flow. There is no parameter field. 🦋
6.3 Screen response messages 💌
These messages are indications used to respond to the screen data request previously received.
The command values are defined as follows:
<CDE> = ACK response indication = 10 (0x0A). The screen data previously received has been well processed, or the LOCAL STATE is acknowledged by the "TNVIP server". There is no parameter field. 💖<CDE> = ERR response indication = 14 (0x0E). The screen data previously received has not been correctly processed. There is no parameter field. 😭<CDE> = BUSY response indication = 18 (0x12). The screen data previously received has been deleted because the terminal is in the local state. There is no parameter field. 🙈<CDE> = ABORTED response indication = 22 (0x16). The receipt of the screen data request has been aborted by a reset terminal command. There is no parameter field. 💀<CDE> = PURGED response indication = 26 (0x1A). The processing of the screen data request has been aborted by a purge indication message. There is no parameter field. 🧹<CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The screen device is not supported. Normally this command never has to be generated, because the screen device should always be present. There is no parameter field. 🫠<CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The screen request received has been deleted because another screen request is already in process. That means several screen request messages have been sent without waiting for the response. It is a consequence of the non-compliance of the protocol. There is no parameter field. 🚫<CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The screen request received has been deleted because the<CDE>field value is unknown. It is a consequence of the non-compliance of the protocol. There is no parameter field. ❓
6.3.1 Page overflow processing 📄
The page overflow processing is not supported through the TNVIP protocol, to avoid retransmitting the message. That leads the "TNVIP client" side to process it locally. When a data message induces a page overflow, the terminal emulation alerts the user, possibly requesting (in manual mode) an "enter" action before clearing the screen and reprocessing the data received. 🙋
Note: When the "TNVIP client" is processing a page overflow, the terminal emulation should be in the BUSY state and should stop getting messages from the line ("TNVIP server") until the page overflow processing is complete. ⏸️
6.4 Screen data purge indication message 🧹
This message is used to purge the current screen request message. When the side that receives the message has not already acknowledged the screen request, it tries to abort the processing of the request and returns a screen purged response message. If it has already replied, it ignores and deletes the message. bestie, it's a clean-up crew 🫧
The following command value is defined as:
<CDE> = PURGE indication = 40 (0x28). There is no parameter field. 🍃
7. The printer flow 🖨️
All the following messages contain the PRINTER value 104 (0x68) in the ADR field. The support of this address is optional. If the "TNVIP server" doesn't address this device, no message with this address will be exchanged. If the "TNVIP client" receives a request message with this address and does not support the printer, it replies with a printer NOT-AVAILABLE response message. 🧸
7.1 Printer data messages 🖨️
These messages are defined to carry the printer data in the parameter field of the TNVIP message. These messages are only sent from the "TNVIP server" to the "TNVIP client".
The parameter has the following format:
<FC1> <FC2> <STX> <printer data>- The FC1 and FC2 bytes are the function codes of the VIP procedure transmission. Their values are ranged from
32 (0x20)to127 (0x7F)included. ✨ - The STX byte is defined by the value
2and acts as the introducer of the printer data. 🌷
To manage the printer device correctly, the protocol only defines a request message. Meanwhile, the "TNVIP server" is ensured that the "TNVIP client" processes a screen data message only when the previous one has been processed. When it receives a printer data message, the "TNVIP client" transfers it into the printer buffer. The terminal is busy only during this transfer. So, if the "TNVIP client" receives another printer data, it deletes them, because the previous printing (transfer between the printer buffer and the printer) has not ended yet. 🔁
The printer data structure depends on the terminal presentation family (P200 or 7800). The two presentations define two modes of printing. The first one needs the printer data to be in the presentation of the screen (7800 or P200 commands), and the data is converted by the terminal into the printer presentation (TTY, SDP, copy). The second mode allows the printer data to be given in the real presentation of the printer. For this reason, it is called "transparent print". 🪄
In the P200 terminal presentation, transparent print data are introduced by the sequence of the two ASCII characters ESC Z (0x1B 0x5A ). P200 formatted print is introduced by the sequence of two ASCII characters ESC X (0x1B 0x58) or ESC Y (0x1B 0x59). 💅
In the 7800 terminal presentation, transparent print data are introduced by the command PTD (Print Transparent Data). 7800 formatted print is introduced by the command PHD (Print Host Data). 🖤
The command value is defined as:
<CDE> = DATA request = 1 (0x01).7.2 Printer response messages 💌
okay bestie, these are the messages the printer uses to report how the printing went for the printer data request it got earlier 🖨️✨ here are the response values:
<CDE> = ACK response indication = 10 (0x0A): the printer data came through and was processed well 💖<CDE> = ERR response indication = 14 (0x0E): the printer data was not processed correctly 🙈 this can happen for an invalid command, a buffer overflow, or the printer being off (printer off...)<CDE> = BUSY response indication = 18 (0x12): the printer data got deleted because the previous printing request hasn't ended yet. this happens when several printer data request messages get sent without waiting for a response 😭<CDE> = ABORTED response indication = 22 (0x14): the terminal operator aborted the printing 🛑<CDE> = PURGED response indication = 26 (0x18): the printing request was aborted by a printer data purge indication message 🧹<CDE> = NOT-AVAILABLE response indication = 30 (0x1E): the printer device isn't supported 💀<CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22): the printer request got deleted because another printer request was already in process. that means several printer request messages were sent without waiting for the response. it's a consequence of not following the protocol, and there is no parameter field 🚫<CDE> = UNKNOWN-COMMAND response indication = 38 (0x26): the printer request got deleted because the<CDE>field had a value that isn't known. again, that's a consequence of not following the protocol, and there is no parameter field 🤨
for all of the above, the parameter field may hold specific terminal status if one was requested in the printer data received (the response to the PDENQ 7800 terminal presentation command) 🎀
7.3 7800 printer status management 🖨️💅
when a "TNVIP client" is emulating a 7800 terminal [8], it handles adding the printer differed status request (PDENQ 7800 command) to the printer data. this lines up the end of printing with sending the printer acknowledgement response, so everything stays in sync 🔁
some DSA applications manage the 7800 printer status themselves, so they send the printer status request at the start of the printer data. so when the "TNVIP client" sees this command at the beginning of the printer data, it must send the 7800 status response back in the parameter field of the printer data response message. main character energy for real 👑
the 7800 terminal presentation also has an immediate printer status request and response (PENQ, which gets an immediate answer showing the current printer status). those commands have to be exchanged in the TNVIP screen data flow 🦋
7.4 Printer state request message 🔍
this message is sent by the "TNVIP server" to check the printer state of the "TNVIP client" without sending any printer data 👀
the command value is:
<CDE> = STATE-REQ request = 53 (0x35): there is no parameter field 🧚
7.5 Printer state response messages 📋
these messages are sent by the "TNVIP client" to report the printer state back to the "TNVIP server" 💜
<CDE> = READY response indication = 58 (0x3A): the printer is ready to print ✅ there is no parameter field<CDE> = STANDBY response indication = 62 (0x3E): the printer device is on standby and temporarily unavailable 😴 there is no parameter field<CDE> = PURGED response indication = 26 (0x1A): the printer state request got aborted by a printer state purge indication message 🧹 there is no parameter field<CDE> = NOT-AVAILABLE response indication = 30 (0x1E): the printer device isn't supported 💀 there is no parameter field<CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22): the printer state request got deleted because another printer request was already in process. that means several printer request messages were sent without waiting for the response. it's a consequence of not following the protocol, and there is no parameter field 🚫<CDE> = UNKNOWN-COMMAND response indication = 38 (0x26): the printer state request got deleted because the<CDE>field value is unknown. it's a consequence of not following the protocol, and there is no parameter field 🤨
7.6 Printer purge indication message 🧹
the "TNVIP server" uses this message to purge the current printer request message 🫶 when the "TNVIP client" receives it, the client checks whether it has already acknowledged the printer data. if it hasn't, it aborts the printing and sends back a printer data purge acknowledgement response message. if it has already replied, it ignores the message and deletes it. iconic restraint 💅
the printer purge command value is:
<CDE> = PURGE indication = 40 (0x28): there is no parameter field ✨
8. The Screen Copy Printing flow 📸
every one of the following messages carries the SCPM address value 105 (0x69) in the ADR field. support for this address is mandatory 💖
8.1 Screen copy request messages 🖼️
the printer device can also be used by the "TNVIP server". so if the terminal user wants a screen copy printed, the "TNVIP" client has to line up the user's request with the "TNVIP server" printing 🤝
the TNVIP protocol says that the "TNVIP client" has to tell the "TNVIP server" when it wants to print a screen copy, and it waits for permission before starting 🚦
the command values are:
<CDE> = COPY-REQ request = 65 (0x41): sent from the "TNVIP client" to the "TNVIP server" to request a screen copy printing 📨<CDE> = LOCAL-COPY response and request = 71 (0x47): sent by the "TNVIP server" to acknowledge the COPY-REQ message, saying the screen copy can be done locally 🏠 it's also a request message, since it works like a screen copy data request message and the "TNVIP server" is waiting for a screen copy response message from the "TNVIP client", just on the SCPM flow 🔄 there is no parameter field
8.2 Screen copy data message 🌸
these messages carry the screen copy data in the terminal presentation inside the parameter of the message. the "TNVIP client" uses them when it wants to send the screen copy data straight to the DSA application (a VIP terminal using a VIP transmission procedure flags this special request with the STA byte =PRT=0x1A) 🎯
the parameter field looks like this:
<FC1> <FC2> <STX> <screen-copy-data>- the FC1 and FC2 bytes are the function codes of the VIP procedure transmission. their values range from 32 (0x20) to 127 (0x7F), included 🔢
- the STX byte is defined by the value 2 and acts as the introducer of the screen data 🚪
a screen copy data message can be sent in a request or an indication message 📬
the command values are:
<CDE> = DATA indication = 0<CDE> = DATA request = 1
8.3 Screen copy response messages 📑
these messages are sent by the "TNVIP client" (local copy) to report the end of printing status of the screen copy 🖨️
the ACK response is also used by the "TNVIP server" to acknowledge a screen copy data request sent to the host application 👍
the ERR message is also used by the server to refuse a COPY-REQ message 🙅
the command values are:
<CDE> = ACK response indication = 10 (0x0A): the "TNVIP client" reports the screen copy was printed well, or the "TNVIP server" acknowledges the screen copy data request 💖 there is no parameter field<CDE> = ERR response indication = 14 (0x0E): the screen copy wasn't printed correctly (invalid command, buffer overflow ...) or the "TNVIP server" refused it 😬 it can optionally contain a reason code value defined on one byte:1 : The printer is busy, retry later.
<CDE> = BUSY response indication = 18 (0x12): the screen copy wasn't printed correctly because the printer device is already printing ⏳ there is no parameter field<CDE> = ABORTED response indication =22 (0x16): the terminal operator aborted the screen copy 🛑 there is no parameter field<CDE> = PURGED response indication = 26 (0x1A): the screen copy request got aborted by a purge indication message 🧹 there is no parameter field<CDE> = NOT-AVAILABLE response indication = 30 (0x1E): the screen copy wasn't printed correctly because the printer device isn't supported 💀 there is no parameter field<CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22): the screen copy request got deleted because another screen copy request was already in process. that means several screen copy request messages were sent without waiting for the response. it's a consequence of not following the protocol, and there is no parameter field 🚫<CDE> = UNKNOWN-COMMAND response indication = 38 (0x26): the screen copy request got deleted because the<CDE>field value is unknown. it's a consequence of not following the protocol, and there is no parameter field 🤨
8.4 Screen copy purge indication message 🧹
this message purges the current screen copy request message 💅 when the "TNVIP server" or the "TNVIP client" receives it, it checks whether it has already acknowledged the request message. if not, it sends back a screen copy purge acknowledgement message. if it has already replied, it ignores and deletes the message.
the command value is:
<CDE> = PURGE indication = 40 (0x28).There is no parameter field.
9. The TM attention 🔔
the TM attention is the signal that activates the local dialog of the DSA Terminal Manager 🧚
the Telnet Abort Output (AO) command [1] is the mechanism used to implement TM attention key support in TNVIP 💫
IAC AO (0xFF 0xF5)to implement TM attention key support, "TNVIP clients" should provide a key (or combination of keys) that maps to the TM attention key. when the user presses that key or combo, the "TNVIP client" should send a Telnet AO command to the "TNVIP server" 🎹
when a "TNVIP server" that implements the DSA Terminal Manager gets the AO command, it should enter what we'll loosely call the "TM Local Dialog", suspending any DSA host connection that's going on. otherwise, it should simply ignore it 🙈
10. The Break Key 💥
okay so, the real VIP terminal generally doesn't have a break key 😭 the break signal gets sent to the host application through a TM local dialog command ($*$BRK for example) 🧠
on a "TNVIP client" emulating a VIP terminal, it's often possible to map the break signal to a special key combination, or some other way (using a mouse, for example) 🖱️
the Telnet Break (BRK) command [1] is used to map the Break signal of the TNVIP 🪄
IAC BRK (0xFF 0xF3)11. The Logout Key 🚪
the Telnet Interrupt Process (IP) command [1] can be used to map the logout command of the TM Local Dialog ($*$LO for example), if it's implemented on the "TNVIP server" 🌈
IAC IP (0xFF 0xF4)12. TNVIP messages list 📜
all the TNVIP commands are summarized right after this (and the values are given in hexadecimal) 🫧
12.1 Screen Flow ✨
Okay bestie, the screen flow is where the magic happens 💅 Every message goes through the same IAC EOR ending, so let's look at each one. 🎀
Data request (allowed in the two ways) 💖
SCREEN DATA-REQ <FC1> <FC2> STX [<screen-data>] IAC EOR
60 01 <FC1> <FC2> 02 [<screen-data>] FF EFAllowed responses to the screen Data request: 🦋
SCREEN ACK IAC EOR
60 0A FF EF
SCREEN ERROR IAC EOR
60 0E FF EF
SCREEN BUSY IAC EOR
60 12 FF EF
SCREEN ABORTED IAC EOR
60 16 FF EF
SCREEN PURGED IAC EOR
60 1A FF EFPassword request (only from the "TNVIP server" to the "TNVIP client") 🔐
SCREEN PASSW-REQ <FC1> <FC2> STX [<screen-data>] IAC EOR
60 05 <FC1> <FC2> 02 [<screen-data>] FF EFAllowed responses to the password request: 🌸
SCREEN ACK IAC EOR
60 0A FF EF
SCREEN ERROR IAC EOR
60 0E FF EF
SCREEN BUSY IAC EOR
60 12 FF EF
SCREEN ABORTED IAC EOR
60 16 FF EF
SCREEN PURGED IAC EOR
60 1A FF EFLocal state request (only from the "TNVIP client" to the "TNVIP server") 🧚
SCREEN LOCAL-ST IAC EOR
60 2D FF EFAllowed responses to the Local state request: ⭐
SCREEN ACK IAC EOR
60 0A FF EF
SCREEN PURGED IAC EOR
60 1A FF EFResponses to request violating the TNVIP protocol (allowed in the two ways) 💀
Oop, when something breaks the TNVIP rules, these are the ones that get sent back. Not me being dramatic, it's literally the protocol 😭
SCREEN NOT-AVAIL IAC EOR
60 0E FF EF
SCREEN PROT-VIOL IAC EOR
60 22 FF EF
SCREEN UNKN-CDE IAC EOR
60 26 FF EFIndications (allowed in the two ways) 🍓
SCREEN DATA-IND <FC1> <FC2> STX [<screen-data>] IAC EOR
60 00 <FC1> <FC2> 02 [<screen-data>] FF EF
SCREEN PURGE IAC EOR
60 28 FF EFPassword indication (only from the "TNVIP server" to the "TNVIP client") 🗝️
SCREEN PASSW-IND <FC1> <FC2> STX [<screen-data>] IAC EOR
60 04 <FC1> <FC2> 02 [<screen-data>] FF EFOn line state indication (only from the "TNVIP client" to the "TNVIP server") 💜
SCREEN ONLINE-ST IAC EOR
60 30 FF EF12.2 Printer flow 🖨️
The printer side is giving organized energy 👑 Same pattern: who can send what, and what they're allowed to get back.
Data request (only from the "TNVIP server" to the "TNVIP client") 🌈
PRINTER DATA-REQ <FC1> <FC2> STX [<printer-data>] IAC EOR
68 01 <FC1> <FC2> 02 [<printer-data>] FF EFAllowed responses to the printer data request: 🎀
PRINTER ACK [<status>] IAC EOR
68 0A [<status>] FF EF
PRINTER ERROR [<status>] IAC EOR
68 0E [<status>] FF EF
PRINTER BUSY [<status>] IAC EOR
68 12 [<status>] FF EF
PRINTER ABORTED [<status>] IAC EOR
68 16 [<status>] FF EF
PRINTER PURGED [<status>] IAC EOR
68 1A [<status>] FF EF
PRINTER NOT-AVAIL [<status>] IAC EOR
68 1E [<status>] FF EFState request (only from the "TNVIP server" to the "TNVIP client") 🫶
PRINTER STATE-REQ IAC EOR
68 35 FF EFAllowed responses to the state request: 🦋
PRINTER READY IAC EOR
68 3A FF EF
PRINTER STANDBY IAC EOR
68 3E FF EF
PRINTER PURGED IAC EOR
68 1A FF EF
PRINTER NOT-AVAIL IAC EOR
68 1E FF EFResponses to request violating the TNVIP protocol (allowed in the two ways) 🙈
PRINTER PROT-VIOL IAC EOR
68 22 FF EF
PRINTER UNKN-CDE IAC EOR
68 26 FF EFIndication (only from the "TNVIP server" to the "TNVIP client") 🔥
PRINTER PURGE IAC EOR
68 28 FF EF12.3 Screen Copy Printing messages flow 📄
This one is the copy-and-print combo, and it's so extra in the best way ✨
Copy request (only from the "TNVIP client" to the "TNVIP server") 🍓
SCPM COPY-REQ IAC EOR
69 41 FF EFAllowed responses to the copy request (from the "TNVIP server" to the "TNVIP client"): 🌸
SCPM ERROR <reason> IAC EOR
69 0E <reason> FF EF
SCPM PURGED IAC EOR
69 1A FF EF
SCPM NOT-AVAIL IAC EOR
69 1E FF EF
SCPM LOCAL-COPY-RQ IAC EOR
69 47 FF EFLocal copy request (only from the "TNVIP server" to the "TNVIP client") 🧚
SCPM LOCAL-COPY-RQ IAC EOR
69 47 FF EFAllowed responses to the local copy request (from the "TNVIP client" to the "TNVIP server"): 💖
SCPM ACK IAC EOR
69 0A FF EF
SCPM ERROR IAC EOR
69 0E FF EF
SCPM BUSY IAC EOR
69 12 FF EF
SCPM ABORTED IAC EOR
69 16 FF EF
SCPM PURGED IAC EOR
69 1A FF EF
SCPM NOT-AVAIL IAC EOR
69 1E FF EFData request (only from the "TNVIP client" to the "TNVIP server") 💅
SCPM DATA-REQ <FC1> <FC2> STX [<screen-data>] IAC EOR
69 01 <FC1> <FC2> 02 [<screen-data>] FF EFAllowed responses to the data request: 🦋
SCPM ACK IAC EOR
69 0A FF EF
SCPM PURGED IAC EOR
69 1A FF EF
SCPM NOT-AVAIL IAC EOR
69 1E FF EFResponses to request violating the TNVIP protocol (allowed in the two ways) 💀
SCPM PROT-VIOL IAC EOR
69 22 FF EF
SCPM UNKN-CDE IAC EOR
69 26 FF EFIndications (allowed in the two ways) 🌈
SCPM DATA-IND <FC1> <FC2> STX [<screen-data>] IAC EOR
69 00 <FC1> <FC2> 02 [<screen-data>] FF EF
SCPM PURGE IAC EOR
69 28 FF EF13. Security Considerations 🔒
Security issues are not addressed in this document. It is anticipated that once authentication mechanisms have become well established, use of them can be made by TNVIP. One of the important uses of authentication would be to answer the question of whether or not a given user should be allowed to "use" a specific terminal.
Okay, this one is serious bestie 😭 The doc literally says it doesn't cover security at all. Authentication is the thing they expect to plug in later, and the big question it would answer is who gets to actually use a particular terminal. Don't skip this part 🙏
14. References 📚
[1] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, USC/Information Sciences Institute, May 1983.
[2] "Communications. MainWay. Terminal Management. DNS-E", Ref : 39A213EB Rev00, BULL S.A.
[3] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP Software, Inc., February 1989.
[4] Postel, J., "Telnet End of Record Option", RFC 885, USC/Information Sciences Institute, December 1983.
[5] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD 27, RFC 856, USC/Information Sciences Institute, May 1983.
[6] Postel, J., and J. Reynolds, "Telnet Suppress Go Ahead Option", STD 29, RFC 858, USC/Information Sciences Institute, May 1983.
[7] "Affinity V2. DKU7107 Reference Manual" Ref : 40 A2 23 WA, BULL S.A.
[8] "Affinity V2. VIP7800 Reference Manual" Ref : 40 A2 24 WA, BULL S.A.
[9] "Bull Questar 200. TCS 7424 et TCS 7434. Transmission de donnees. Manuel de reference" Ref : 80 F2 41DC Rev0, BULL S.A.
15. Author's Address 💌
Jean-Yves Dujonc BULL S.A. rue Jean Jaures 78340 Les Clayes-sous-Bois France
Phone: 1 30 80 62 95 Fax: 1 30 80 65 40 EMail: J.Y.Dujonc@frcl.bull.fr
That's the whole thing, bestie! 🌈✨ You made it through every single message 🫶
📦 where this page comes from
- ietf: rfc1921 1996-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms