RFC relevance of terminal

As per Relevance of the word terminal, we have this rfc below:

Network Working Group J.
Request for Comments: 1921 Bull S.A
Category: Informational March 1996

TNVIP

Status of this

This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited

The goal of this document specifies a Telnet profile to support
terminal emulation allowing the access to the BULL hosts
through a TCP/IP network

Table of

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

Dujonc Informational [Page 1]

RFC 1921 TNVIP Protocol March 1996

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 . . . . . . . . . . . . . . . . . . 30

1.

P200 [7] and 7800 [8] VIP (Visual Information Projection)
differ mainly from NVT terminals [1] in that they work in block
and have the capability to manage an associated printer. Generally
a DSA (Distributed Systems Architecture) network they are
through the VIP transmission line procedure (character oriented).
That is the reason why they are generically referred as
terminals

This document specifies the options to be modified successfully,
pass from the NVT terminal emulation supported on a
connection, to a VIP terminal emulation. It defines also the
of the messages exchanged between the server and the client when
TNVIP protocol is successfully negotiated

Dujonc Informational [Page 2]

RFC 1921 TNVIP Protocol March 1996

2.

VIP terminal family includes a broad range of different
types. They work in block mode with an ASCII or 8 binary bits set
characters

The Bull terminals in the DSA network environment use the services
a Terminal Manager (TM) [2]. It is generally installed in
communication processor (as a Datanet or Mainway system) where
assures the connection with the BULL host application
through a DSA session

The Terminal Manager is in charge to present the terminal station
to manage the session connection to the host computer. It
generally a possibility of dialog with the terminal to allow the
to modify the connection parameters, to manage the
(connection request, abort, etc ..). The set of commands
responses used is called "TM Local Dialog".

3. Telnet Options and Commands

The mandatory telnet parameters to be negotiated successfully
the "TNVIP server" and the "TNVIP client" are :

- the Terminal-Type option [3] to define a VIP terminal model
if necessary a Mailbox name to request a specific access point
the "TNVIP server",

- the End Of Record option [4] to delimit the TNVIP message at
Telnet level. As the End Of Record (EOR) code indicates the end
an effective data unit, Telnet should attempt to send the data
to and including the EOR code together to promote
efficiency

Others Telnet parameters, can be optionally negotiated as :

- the Binary Transmission option [5], when the terminal
uses a 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
turn or the ISO session token is needed

When the two parties (the "TNVIP server" and the "TNVIP client")
negotiated successfully a TNVIP terminal type and the EOR
option, that means they agree to respect the TNVIP protocol (
TNVIP message format and the exchange rules).

Dujonc Informational [Page 3]

RFC 1921 TNVIP Protocol March 1996

3.1 Terminal type

IAC DO TERMINAL-

Sender (the "TNVIP server" party) is willing to receive
type information in a subsequent sub-negotiation

IAC WILL TERMINAL-

Sender (the terminal "TNVIP client" party) is willing to
terminal-type information in a subsequent sub-negotiation

3.1.1 Subnegotiation of the Terminal

IAC SB TERMINAL-TYPE SEND IAC

Sender (the "TNVIP server" party) requests the receiver
transmit his next terminal-type, and switch emulation modes (
more than one terminal type is supported).

IAC SB TERMINAL-TYPE IS tnvip-terminal-model@MB-name IAC

Sender (the terminal "TNVIP client" party) is stating the name
his current (or only) terminal-type. Optionally, a mailbox
can be added to request a particular access point in the "
server". By default, the "TNVIP server" uses a generic
point

3.1.2 Terminal-types supported by the TNVIP

The TNVIP terminal type string given at the Telnet negotiation
formatted as follows :

terminal-model> [ <@ character> ]

The @ character is used as separator between the VIP-terminal-
and the Mailbox-name

Dujonc Informational [Page 4]

RFC 1921 TNVIP Protocol March 1996

3.1.3 TNVIP terminal

The valid TNVIP terminal models are the following ASCII
strings. (The table gives for each terminal model string
hexadecimal number indicating the associated DSA model number
in the DSA terminal presentation protocols ).

P200 family 7800
-------------------------------- --------------------------------
! 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 character at the end of the string indicates that the
supports the Remote Forms function [9]. It is the capability to
forms in the terminal allowing the host application to display a
stored in the terminal sending a short length command without
all the data of the form. This function is usually supported by
terminal concentrators

3.1.4 Mailbox

The mailbox name allows the "TNVIP client" to request a
access point referenced by this name in the "TNVIP server". It is
ASCII character string. Its presence in the Telnet terminal
string is optional. When not present, a generic (default) access
be provided by the "TNVIP server".

When the "TNVIP server" is a gateway to DSA hosts, the mailbox
defines the DSA session access point of the terminal in the server
Its length is limited to 12 characters. Lower case characters
allowed but are processed as upper case. This string is
used to identify a specific terminal station (having a printer
example) or to use a particular declaration of this terminal in
"TNVIP server".

Dujonc Informational [Page 5]

RFC 1921 TNVIP Protocol March 1996

3.2 End of Record

VIP device communications are block oriented. That is, each
buffers data until an entire "message" has been built, at which
the data are sent to the other side. The end of a message
understood to be the last byte transmitted. The Telnet EOR command
used to delimit these natural blocks of TNVIP data within the
data stream. An is sent at the end of each TNVIP message,
both directions

IAC WILL END-OF-

The sender of this command requests permission to
transmission of the Telnet END-OF-RECORD (EOR) code
transmitting data characters, or the sender of this
confirms it will now begin transmission of EORs with
data characters

IAC DO END-OF-

The sender of this command requests that the sender of data
transmitting the EOR code when transmitting data, or the sender
this command confirms that the sender of data is expected
transmit EORs

3.3 Binary Transmission

According to the character set used by the emulation, the "
client" and the "TNVIP server" can be led to negotiate the
binary transmission option

If either side wishes to transmit the decimal value 255 and have
interpreted as data, it must "double" this byte. In other words,
single occurrence of decimal 255 will be interpreted by the
side as an IAC, while two successive bytes containing decimal 255
will be treated as one data byte with a value of decimal 255.

IAC DO TRANSMIT-

Sender requests that sender of the data starts transmitting
confirms that the sender of data is expected to
characters that are to be interpreted as 8 bits of binary data
the receiver

IAC WILL TRANSMIT-

Sender requests permission to begin transmitting, or confirms
will now begin transmitting binary data

Dujonc Informational [Page 6]

RFC 1921 TNVIP Protocol March 1996

IAC WON'T TRANSMIT-

If the connection is already being operated in binary
mode, the sender of this command demands to begin
data characters which are to be interpreted as standard NVT
characters by the receiver of the data. If the connection is
already being operated in binary transmission mode, the sender
this command refuses to begin transmitting characters which are
be interpreted as binary characters by the receiver of the
(i.e., the sender of the data requests to continue
characters in its present mode).

IAC DON'T TRANSMIT-

If the connection is already being operated in binary
mode, the sender of this command requests that the sender of
data start transmitting characters which are to be interpreted
standard NVT ASCII characters by the receiver of the
(i.e.,the party sending this command). If the connection is
already being operated in binary transmission mode, the sender
this command requests that the sender of data
transmitting characters which are to be interpreted in the
mode

3.4 Suppress Go Ahead

The "TNVIP client" can use the receiving of the Telnet
command as the signal allowing the terminal operator to
data. That can allow the synchronisation between the data
from the terminal and the DSA "turn".

When the Suppress Go Ahead option is not negotiated, the "
server" must send the Telnet Go Ahead command (GA) when its
message queue (from the "TNVIP client") is empty and the DSA turn
at the terminal side, to invite the terminal to transmit some data

To suppress this mechanism, the "TNVIP client" can request the
sending of the Telnet GoAhead commands by the "TNVIP server",
negotiating the Suppress GO Ahead option of the Telnet Protocol

In this case, the terminal transmission to the "TNVIP server"
synchronised on the transport credit

Note: The Telnet GA command never need to be sent by the "
client" even if the telnet Suppress Go Ahead has not
negotiated

Dujonc Informational [Page 7]

RFC 1921 TNVIP Protocol March 1996

IAC DO SUPPRESS-GO-

The sender of this command (the "TNVIP client" party) requests
the sender of data starts suppressing GA when transmitting data

IAC WILL SUPPRESS-GO-

The sender of this command (the "TNVIP server" party) confirms
will now begin suppressing transmission of GAs with
data characters

IAC DON'T SUPPRESSS-GO-

The sender of this command (the "TNVIP client" party)
that the receiver of the command start transmitting GAs
transmitting data

IAC WON'T SUPPRESS-GO-

The sender of this command (the "TNVIP server" party) confirms
will now begin transmitting the GA character when
data characters

4. TNVIP

The TNVIP protocol allows the following functions :

- Support of a VIP terminal emulation addressing the screen and
associated printer .

- Selection of the terminal type model at the connection time

- Specific or generic access to the "TNVIP server" by referencing
not a Mailbox name

- TNVIP protocol independent of the terminal data
protocol (7800 or P200).

- Support of the DSA End To End Acknowledgement

- Support of the DSA Terminal Manager local attention

- Support of the DSA turn to the terminal side

- Support of the DSA secret read

- Control of the hard copy

Dujonc Informational [Page 8]

RFC 1921 TNVIP Protocol March 1996

4.1 TNVIP terminal

The "TNVIP client" acts as the interface adapter between the
connection and an application program. The "TNVIP client" is
defined to support a VIP terminal emulation program but can be
by other else program using the TNVIP protocol

A VIP terminal emulation manages

- a screen buffer

- a printer buffer if it supports the associated printer

- the interface with the communication

and runs using the following rules

When the VIP terminal emulation exchanges a message on
communication line, it is in the BUSY state until the end of
message exchange. That means when the VIP terminal is sending
message it can't receive and when it is receiving a message it can'
send

Note: If a VIP terminal works in the half duplex mode, as the
protocol uses a Telnet connection it allows a full
mode processing

4.1.1 Local and online

The VIP terminal has the capability to switch between these
states. The LOCAL state is generally used to process local
tests or to modify the configuration. In this state, the data
from the line are ignored

The LOCAL state allows the "TNVIP client" to request to the
the screen and printer data flows to be suspended

The ONLINE state indication allows the "TNVIP server" to resume
screen and printer flows

For these reasons the TNVIP protocol differentiates the screen
printer flows from the screen copy printing flow and defines
report the two states to the "TNVIP server".

Dujonc Informational [Page 9]

RFC 1921 TNVIP Protocol March 1996

4.1.2 Data

When a VIP terminal emulation receives a data message from the line
according to the address given in the header message,it sends data
the screen buffer or to the printer buffer

A message received at the screen or printer address is deleted
ignored if the terminal emulation is in the LOCAL state and a
status is returned

The printer buffer is busy when the terminal is transmitting the
from the printer buffer to the printer device. A data message for
printer is deleted and ignored if the terminal is in the
state and a BUSY status is returned

When a BUSY state is encountered, the "TNVIP client" according to
type of message received (request or indication) reports or not
BUSY acknowledgement to the "TNVIP server".

4.1.3 Data

A VIP terminal emulation can send message even if the terminal is
the LOCAL state

4.2 TNVIP Server

4.2.1 VIP Terminal

Its function is to act as a gateway between the VIP terminal and
VIP application. Generally the application is a remote
application

It manages the screen and printer devices of the VIP
station

Dujonc Informational [Page 10]

RFC 1921 TNVIP Protocol March 1996

In the following example figure, the "TNVIP server" is a DSA
and manages three VIP terminal units TU1, TU2 and TU3.

Generic
--------------
!----> LD 1S ----> DV 1S (screen) ---->!
MB 1 --> SN 1 TU 1
!----> LD 1P ----> DV 1P (printer) ---->!

Specific
-----------------
!----> 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
devices (DV objects). The Terminal Manager maps this
representation to a logical representation where the station (
object) is the logical representation of a terminal unit, and
logical device (LD) object a logical representation of the
device

- TU1 will be chosen by default on generic request (without
name) or by the MB1 name addressing on specific request. It
manage the associated printer device

- MB2 will be addressed to access the TU2 terminal unit. TU2
defined in a specific way because it will be presented to the
application as a station composed of a screen (the TU2 one's)
a printer (the TU3 one's).

- MB3 will be addressed to access TU3 terminal unit. TU3 is
defined in a specific way because the printer device is shared
several logical stations (SN2 and SN3) and must be
identified

Dujonc Informational [Page 11]

RFC 1921 TNVIP Protocol March 1996

5. TNVIP Messages

Each TNVIP message is delimited by the Telnet EOR command

Therefore, a TNVIP message has the following format

<parameters>
The TNVIP header is mandatory and have a fixed length of two bytes

Some TNVIP messages need no parameter. In this case, the
message has the following construction

It is strongly recommended that Telnet commands (other than IAC IAC
should be sent between TNVIP messages, with no TNVIP header and
trailing IAC EOR. If a TNVIP data message containing any other IAC
command sequence (other than IAC IAC) is received, it
implementation dependent when the IAC-command sequence will
processed, but it must be processed. The receiver may process
immediately, which in effect causes it to be processed as if it
been received before the current TNVIP message, or the processing
be deferred until after the current TNVIP message has been processed
It is because of this ambiguity that the presence of Telnet
within a TNVIP message is not recommended; neither "TNVIP client"
nor "TNVIP server"s should send such data

The TNVIP header contains 2 bytes. The first one indicates
address and the second the command .

5.1 Address

The 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
flow

A request message with an unknown or unsupported address will
discarded by the receiver which replies with a NOT-AVAILABLE
message

Dujonc Informational [Page 12]

RFC 1921 TNVIP Protocol March 1996

5.2 Command

The command field is mandatory and defined on one byte

The command byte is structured as follows

- The Command-Type fills the six most significant bits of the byte. The most significant bit is always 0.

Its value is ranged from 0 to 31 included. It defines the
associated to the message for the flow identified by the
field

- The Message-Type fills the two less significant bits of the byte

0 = Indication message. No response message is expected.
indication message with an undefined command type or with
unknown address is deleted and ignored

1 = Request message. The sender of a request message is
for a response message having the same address value. When
request message is sent for a given address, it is not allowed
send another request to the same address before the
response. If an end point receives a request before having
the response of the previous request, it deletes the
request but have to send back a PROTOCOL-VIOLATION response
the response of the first request. A request message with a
defined address is replied to by a NOT-AVAILABLE response message
A request message with an unknown or unsupported command
this address will be deleted by the receiver and replied to by
UNKNOWN-COMMAND response message

2 = Response message. This message is the response to the
request message. The receiver of this message is allowed to
another request message on the flow defined by the ADR field

3 = Response and request message. This message is a
response to the current request message sent by the receiver,
is also a request message

Dujonc Informational [Page 13]

RFC 1921 TNVIP Protocol March 1996

The following table gives the commands list with
hexadecimal

Command Indication Request Response Resp/
--------------------------------------------------------
DATA 00 01
PASSW 04 05
ACK 0
ERROR 0
BUSY 12
ABORTED 16
PURGED 1
NOT-AVAILABLE 1
PROTOCOL-VIOLATION 22
UNKNOWN-COMMAND 26
PURGE 28
LOCAL-STATE 2
ONLINE-STATE 30
STATE-REQ 35
READY 3
STANDBY 3
COPY-REQ 41
LOCAL-COPY 47

5.3 Parameter

This field has a variable length and its content is depending on
two previous fields (address and command).

6. The screen

All the following messages contain the value SCREEN = 96 (0x60)
the ADR field

6.1 Screen data

These messages are defined to transport in the parameter field of
TNVIP message, the data in the terminal presentation negotiated
the "Terminal Type" telnet command

The parameter has the following format

< screen data

- The FC1, FC2 bytes are the functions codes of the VIP
transmission [9]. Their values are comprised between 32 (0x20)
included and 127 (0x7F) included

Dujonc Informational [Page 14]

RFC 1921 TNVIP Protocol March 1996

- The STX byte is defined by the value 2 and acts as the
of the screen data

A screen data message can be sent in a request or in an
message. The command values are defined as follows

= DATA indication = 0

= DATA request = 1

= PASSWORD indication = 4

= PASSWORD request = 5

Generally, the "TNVIP server" only sends indication messages to
screen. The request message is used mainly for the printer device
But a DSA/TNVIP gateway server should use the screen data
message when it processes a DSA end to end acknowledgement
from the DSA application and synchronizes the response
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'
emulate terminal. In this way, they have the indication that a
read (password acquisition) is requested by the "TNVIP server".
the program is a terminal emulation this information is not
because the data contains the terminal presentation command
request this secret read

6.2 Local state monitoring

Before to switch in the local state, the "TNVIP client" sends
LOCAL-STATE request message to the "TNVIP server". This last
sends back an acknowledgement message and suspends the screen
printer data flow until it receives a LINE-STATE indication message

Note: In the local state, only the messages from the "TNVIP server
to the screen or printer devices are deleted. The
from the "TNVIP client" screen device or the
associated to others addresses are allowed

The following command values are defined as

= LOCAL-STATE request = 45 (0x2D). It is sent by the "
client". There is no parameter field

Dujonc Informational [Page 15]

RFC 1921 TNVIP Protocol March 1996

= ONLINE-STATE indication = 48 (0x30). It is sent by
"TNVIP client" to indicate the "TNVIP server" is allowed to
the screen data flow. There is no parameter field

6.3 Screen response

These messages are indications used to respond to the screen
request previously received

The command values are defined as follows

= ACK response indication = 10 (0x0A). The screen
previously received has been well processed or the LOCAL STATE
acknowledged by the "TNVIP server". There is no parameter field

= ERR response indication = 14 (0x0E). The screen
previously received has not been correctly processed. There is
parameter field

= BUSY response indication = 18 (0x12). The screen
previously received has been deleted because the terminal is in
local state. There is no parameter field

= ABORTED response indication = 22 (0x16). The receipt of
screen data request has been aborted by a reset terminal command
There is no parameter field

= PURGED response indication = 26 (0x1A). The processing
the screen data request has been aborted by a purge
message. There is no parameter field

= NOT-AVAILABLE response indication = 30 (0x1E). The
device is not supported. Normally this command has never to
generated because the screen device should always be present.
is no parameter field

= PROTOCOL-VIOLATION response indication = 34 (0x22).
screen request received has been deleted because an other
request is already in process. That means several screen
messages have been sent without waiting for the response. It is
consequence of the non-compliance of the protocol. There is
parameter field

= UNKNOWN-COMMAND response indication = 38 (0x26). The
request received has been deleted because the field value
unknown. It is a consequence of the non-compliance of the protocol
There is no parameter field

Dujonc Informational [Page 16]

RFC 1921 TNVIP Protocol March 1996

6.3.1 Page overflow

The page overflow processing is not supported through the
protocol to avoid the retransmission of the message. That leads
"TNVIP client" side to process it locally. When a data
induces a page overflow, the terminal emulation alerts the
possibly requesting (in manual mode) an "enter" action
clearing the screen and reprocessing the data received

Note: When the "TNVIP client" is processing a page overflow ,
terminal emulation should be in the BUSY state and
stop getting message from the line ("TNVIP server") until
page overflow processing is complete

6.4 Screen data purge indication

This message is used to purge the current screen request message
When the side which receive the message has not already
the screen request, it tries to abort the processing of the
and returns a screen purged response message. If it has
replied, it ignores and deletes the message

The following command value is defined as

= PURGE indication = 40 (0x28). There is no parameter field

7. The printer

All the following messages contain the PRINTER value 104 (0x68)
the ADR field. The support of this address is optional. If the "
server" doesn't address this device, no message with this
will be exchanged. If the "TNVIP client" receives a request
with this address and does not support the printer, it replies with
printer NOT-AVAILABLE response message

7.1 Printer data

These messages are defined to transport the printer data in
parameter field of the TNVIP message. These messages are only
from the "TNVIP server" to the "TNVIP client".

The parameter has the following format

- The FC1, FC2 bytes are the function codes of the VIP
transmission. Their values are ranged from 32 (0x20) to 127
(0x7F) included

Dujonc Informational [Page 17]

RFC 1921 TNVIP Protocol March 1996

- The STX byte is defined by the value 2 and acts as the
of the printer data

To manage correctly the printer device, the protocol only
request message. Whereas the "TNVIP server" is ensured than
"TNVIP client" processes a screen data message only when the
one have been processed. When it receives a printer data message,
"TNVIP client" transfers it in the printer buffer. The terminal
busy only during this transfer. So, if the "TNVIP client"
another printer data it deletes them because the previous
(transfer between the printer buffer and the printer) is not ended

The printer data structure depends on the terminal
family (P200 or 7800). The two presentations define two modes
printing. The first one needs the printer data are in
presentation of the screen (7800 or P200 commands) and data
converted by the terminal in the printer presentation (TTY, SDP
copy. The second mode allows to give the printer data in the
presentation of the printer. For this reason it is
"transparent print".

In the P200 terminal presentation, transparent print data
introduced by the sequence of the two ASCII characters ESC Z (0x1
0x5A ). P200 formatted print are introduced by the sequence of
ASCII characters ESC X (0x1B 0x58) or ESC Y (0x1B 0x59).

In the 7800 terminal presentation, transparent print data
introduced by the command PTD (Print Transparent Data). 7800
formatted print are introduced by the command PHD (Print Host Data).

= DATA request = 1 (0x01).

7.2 Printer response

These messages are used to report the printing end status of
printer data request previously received

The following command values are defined as

= ACK response indication = 10 (0x0A). The printer
previously received have been well processed

= ERR response indication = 14 (0x0E). The printer
previously received have not been correctly processed (
command, buffer overflow , printer off...)

= BUSY response indication = 18 (0x12). The printer
received have been deleted because the previous printing request

Dujonc Informational [Page 18]

RFC 1921 TNVIP Protocol March 1996

not ended. Several printer data request messages have been
without waiting for the response

= ABORTED response indication = 22 (0x14). The printing
been aborted by the terminal operator

= PURGED response indication = 26 (0x18). The printing
has been aborted by a printer data purge indication message

= NOT-AVAILABLE response indication = 30 (0x1E). The
device is not supported

= PROTOCOL-VIOLATION response indication = 34 (0x22).
printer request received has been deleted because an other
request is already in process. That means several printer
messages have been sent without waiting for the response. It is
consequence of the non-compliance of the protocol. There is
parameter field

= UNKNOWN-COMMAND response indication = 38 (0x26).
printer request received has been deleted because of an
field value. It is a consequence of the non-compliance of
protocol. There is no parameter field

For all the above commands, the parameter field may
specific terminal status if one was requested in the printer
received (response to PDENQ 7800 terminal presentation command).

7.3 7800 printer status

When emulating a 7800 terminal [8], the "TNVIP client" takes
of adding to the printer data the printer differed status
(PDENQ 7800 command) to synchronize the printing end with the
of the printer acknowledgement response

Some DSA applications are written to manage the 7800 printer status
so they send themselves the printer status request at the
of the printer data. That is the reason why when the "TNVIP client
receives this command at the beginning of the printer data, it
send back the 7800 status response in the parameter field of
printer data response message

The 7800 terminal presentation defines also immediate printer
request and response (PENQ which allows to get an immediate
indicating the current printer status). These commands have to
exchanged in the TNVIP screen data flow

Dujonc Informational [Page 19]

RFC 1921 TNVIP Protocol March 1996

7.4 Printer state request

This message is sent by the "TNVIP server" to know the printer
of the "TNVIP client" without sending printer data

The following command value is defined as

= STATE-REQ request = 53 (0x35). There is no parameter field

7.5 Printer state response

These messages are sent by the "TNVIP client" in order to report
printer state to the "TNVIP server".

The following command values are defined as

= READY response indication = 58 (0x3A). The printer state
ready to print. There is no parameter field

= STANDBY response indication = 62 (0x3E). The printer
is in standby and is temporarily unavailable. There is no
field

= PURGED response indication = 26 (0x1A). The printer
request has been aborted by a printer state purge
message. There is no parameter field

= NOT-AVAILABLE response indication = 30 (0x1E). The
device is not supported. There is no parameter field

= PROTOCOL-VIOLATION response indication = 34 (0x22).
printer state request received has been deleted because an
printer request is already in process. That means several
request messages have been sent without waiting for the response.
is a consequence of the non-compliance of the protocol. There is
parameter field

= UNKNOWN-COMMAND response indication = 38 (0x26). The
state request received has been deleted because the
value is unknown. It is a consequence of the non-compliance of
protocol. There is no parameter field

7.6 Printer purge indication

This message is used by the "TNVIP server" to purge the
printer request message. When the "TNVIP client" receives
message, if it has not already acknowledged the printer data,
aborts the printing and returns a printer data purge

Dujonc Informational [Page 20]

RFC 1921 TNVIP Protocol March 1996

response message. If it has already replied, it ignores and
the message

The printer purge command value is defined as

= PURGE indication = 40 (0x28). There is no parameter field

8. The Screen Copy Printing

All the following messages contain the SCPM address value 105 (0x69)
in the ADR field. The support of this address is mandatory

8.1 Screen copy request

As the printer device can be used by the "TNVIP server", if
terminal user wishes a screen copy printing, the "TNVIP" client
to synchronize the user request with the "TNVIP server" printing .

The TNVIP protocol defines that the "TNVIP client" has to inform
"TNVIP server" when it wants to print a screen copy and waits for
authorization before

The following command values are defined as

= COPY-REQ request = 65 (0x41). It is used from the "
client" to the "TNVIP server" to request a screen copy printing

= LOCAL-COPY response and request = 71 (0x47). It is sent
the "TNVIP server" to acknowledge the COPY-REQ message
the screen copy can be done locally. It is also a request
because it is equivalent to a screen copy data request message
the "TNVIP server" is waiting for a screen copy response
from the "TNVIP client" but on the SCPM flow. There is no
field

8.2 Screen copy data

They are defined in order to transport in the parameter of
message the screen copy data in the terminal presentation. It is
by the "TNVIP client" when it wants to send the screen copy
directly to the DSA application (a VIP terminal using a
transmission procedure indicates this special request by the STA
=PRT=0x1A).

Dujonc Informational [Page 21]

RFC 1921 TNVIP Protocol March 1996

The parameter field has the following format

- The FC1, FC2 bytes are the functions codes of the VIP
transmission. Their values are ranged from 32 (0x20) to 127
(0x7F) included

- The STX byte is defined by the value 2 and acts as the
of the screen data

Screen copy data message can be sent in a request or
message

The command values are defined as follows

= DATA indication = 0

= DATA request = 1

8.3 Screen copy response

These messages are sent by the "TNVIP client" (local copy) to
the end of printing status of the screen copy

The ACK response is also used by the "TNVIP server" to acknowledge
screen copy data request sent to the host application

The ERR message is also used by the server to refuse a COPY-
message

The following command values are defined as

= ACK response indication = 10 (0x0A). The "TNVIP client
reports the screen copy has been well printed or the "TNVIP server
acknowledges the screen copy data request. There is no
field

= ERR response indication = 14 (0x0E). The screen copy has
been correctly printed (invalid command, buffer overflow ...) or
been refused by the "TNVIP server". It can optionally contain
reason code value defined on one byte

- 1 : The printer is busy, retry later

= BUSY response indication = 18 (0x12). The screen copy
not been correctly printed because the printer device is
printing. There is no parameter field

Dujonc Informational [Page 22]

RFC 1921 TNVIP Protocol March 1996

= ABORTED response indication =22 (0x16). The screen copy
been aborted by the terminal operator. There is no parameter field

= PURGED response indication = 26 (0x1A). The screen
request message has been aborted by a purge indication message
There is no parameter field

= NOT-AVAILABLE response indication = 30 (0x1E). The
copy has not been correctly printed because the printer device
not supported. There is no parameter field

= PROTOCOL-VIOLATION response indication = 34 (0x22).
screen copy request received has been deleted because an
screen copy request is already in process. That means several
copy request messages have been sent without waiting for
response. It is a consequence of the non-compliance of the protocol
There is no parameter field

= UNKNOWN-COMMAND response indication = 38 (0x26). The
copy request received has been deleted because the field
is unknown. It is a consequence of the non-compliance of
protocol. There is no parameter field

8.4 Screen copy purge indication

This message is used to purge the current screen copy
message. When the "TNVIP server" or the "TNVIP client" receives
message, if it has not already acknowledged the request message,
returns a screen copy purge acknowledgement message. If it
already replied, it ignores and deletes the message

The following command value is defined as

= PURGE indication = 40 (0x28).There is no parameter field

9. The TM

The TM attention is the signal used to activate the local dialog
the DSA Terminal Manager

The Telnet Abort Output (AO) command [1] is the mechanism used
implement the TM attention key support in TNVIP

IAC AO (0xFF 0xF5)

In order to implement the TM attention key support, "TNVIP clients
should provide a key (or combination of keys) that is identified
mapping to the TM attention key. When the user presses this key(s),

Dujonc Informational [Page 23]

RFC 1921 TNVIP Protocol March 1996

the "TNVIP client" should transmit a Telnet AO command to the "
server".

Upon receipt of the AO command, a "TNVIP server" that implements
DSA Terminal Manager should enter in what will be loosely termed "
Local Dialog", suspending the eventual DSA host connection, else
should simply ignore it

10. The Break

Generally, there is no break key on the real VIP terminal. The
signal is transmitted to the host application through a TM
dialog command ($*$BRK for example

On "TNVIP client" emulating VIP terminal, it is often possible to
the break signal on a special key combination or by other way (
mouse ...).

The Telnet Break (BRK) command [1] is used to map the Break signal
the TNVIP

IAC BRK (0xFF 0xF3)

11. The Logout

The Telnet Interrupt Process (IP) command [1] can be used to map
logout command of the TM Local Dialog ($*$LO for example) if it
implemented on the "TNVIP server".

IAC IP (0xFF 0xF4)

12. TNVIP messages

All the TNVIP commands are summarized here after (and the values
given in hexadecimal).

12.1 Screen

Data request (allowed in the two ways

SCREEN DATA-REQ STX [] IAC
60 01 02 [] FF

- Allowed responses to the screen Data request

SCREEN ACK IAC
60 0A FF

Dujonc Informational [Page 24]

RFC 1921 TNVIP Protocol March 1996

SCREEN ERROR IAC
60 0E FF

SCREEN BUSY IAC
60 12 FF

SCREEN ABORTED IAC
60 16 FF

SCREEN PURGED IAC
60 1A FF

Password request (only from the "TNVIP server" to the "TNVIP client")

SCREEN PASSW-REQ STX [] IAC
60 05 02 [] FF

- Allowed responses to the password request

SCREEN ACK IAC
60 0A FF

SCREEN ERROR IAC
60 0E FF

SCREEN BUSY IAC
60 12 FF

SCREEN ABORTED IAC
60 16 FF

SCREEN PURGED IAC
60 1A FF

Local state request (only from the "TNVIP client" to the "
server").

SCREEN LOCAL-ST IAC
60 2D FF

- Allowed responses to the Local state request

SCREEN ACK IAC
60 0A FF

SCREEN PURGED IAC
60 1A FF

Dujonc Informational [Page 25]

RFC 1921 TNVIP Protocol March 1996

Responses to request violating the TNVIP protocol (allowed in the
ways

SCREEN NOT-AVAIL IAC
60 0E FF

SCREEN PROT-VIOL IAC
60 22 FF

SCREEN UNKN-CDE IAC
60 26 FF

Indications (allowed in the two ways

SCREEN DATA-IND STX [] IAC
60 00 02 [] FF

SCREEN PURGE IAC
60 28 FF

Password indication (only from the "TNVIP server" to the "
client").

SCREEN PASSW-IND STX [] IAC
60 04 02 [] FF

On line state indication (only from the "TNVIP client" to the "
server").

SCREEN ONLINE-ST IAC
60 30 FF

12.2 Printer

Data request (only from the "TNVIP server" to the "TNVIP client")

PRINTER DATA-REQ STX [] IAC
68 01 02 [] FF

- Allowed responses to the printer data request

PRINTER ACK [] IAC
68 0A [] FF

PRINTER ERROR [] IAC
68 0E [] FF

Dujonc Informational [Page 26]

RFC 1921 TNVIP Protocol March 1996

PRINTER BUSY [] IAC
68 12 [] FF

PRINTER ABORTED [] IAC
68 16 [] FF

PRINTER PURGED [] IAC
68 1A [] FF

PRINTER NOT-AVAIL [] IAC
68 1E [] FF

State request (only from the "TNVIP server" to the "TNVIP client")

PRINTER STATE-REQ IAC
68 35 FF

- Allowed responses to the state request

PRINTER READY IAC
68 3A FF

PRINTER STANDBY IAC
68 3E FF

PRINTER PURGED IAC
68 1A FF

PRINTER NOT-AVAIL IAC
68 1E FF

Responses to request violating the TNVIP protocol (allowed in the
ways

PRINTER PROT-VIOL IAC
68 22 FF

PRINTER UNKN-CDE IAC
68 26 FF

Indication (only from the "TNVIP server" to the "TNVIP client")

PRINTER PURGE IAC
68 28 FF

Dujonc Informational [Page 27]

RFC 1921 TNVIP Protocol March 1996

12.3 Screen Copy Printing messages

Copy request (only from the "TNVIP client" to the "TNVIP server")

SCPM COPY-REQ IAC
69 41 FF

- Allowed responses to the copy request (from the "TNVIP server"
the "TNVIP client")

SCPM ERROR IAC
69 0E FF

SCPM PURGED IAC
69 1A FF

SCPM NOT-AVAIL IAC
69 1E FF

SCPM LOCAL-COPY-RQ IAC
69 47 FF

Local copy request (only from the "TNVIP server" to the "
client" )

SCPM LOCAL-COPY-RQ IAC
69 47 FF

- Allowed responses to the local copy request (from the "
client" to the "TNVIP server").

SCPM ACK IAC
69 0A FF

SCPM ERROR IAC
69 0E FF

SCPM BUSY IAC
69 12 FF

SCPM ABORTED IAC
69 16 FF

SCPM PURGED IAC
69 1A FF

SCPM NOT-AVAIL IAC
69 1E FF

Dujonc Informational [Page 28]

RFC 1921 TNVIP Protocol March 1996

Data request. (only from the "TNVIP client" to the "TNVIP server")

SCPM DATA-REQ STX [] IAC
69 01 02 [] FF

- Allowed responses to the data

SCPM ACK IAC
69 0A FF

SCPM PURGED IAC
69 1A FF

SCPM NOT-AVAIL IAC
69 1E FF

Responses to request violating the TNVIP protocol (allowed in the
ways

SCPM PROT-VIOL IAC
69 22 FF

SCPM UNKN-CDE IAC
69 26 FF

Indications (allowed in the two ways

SCPM DATA-IND STX [] IAC
69 00 02 [] FF

SCPM PURGE IAC
69 28 FF

13. Security

Security issues are not addressed in this document. It
anticipated that once authentication mechanisms have become
established, use of them can be made by TNVIP. One of the
uses of authentication would be to answer the question of whether
not a given user should be allowed to "use" a specific terminal

Dujonc Informational [Page 29]

RFC 1921 TNVIP Protocol March 1996

14.

[1] Postel, J., and J. Reynolds, "Telnet Protocol Specification",
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,
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",
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

Jean-Yves
BULL S.A
rue Jean
78340 Les Clayes-sous-

Phone: 1 30 80 62 95
Fax: 1 30 80 65 40
EMail: J.Y.Dujonc@frcl.bull.

Dujonc Informational [Page 30]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX