summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1921.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1921.txt')
-rw-r--r--doc/rfc/rfc1921.txt1683
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc1921.txt b/doc/rfc/rfc1921.txt
new file mode 100644
index 0000000..0f713bd
--- /dev/null
+++ b/doc/rfc/rfc1921.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group J. Dujonc
+Request for Comments: 1921 Bull S.A.
+Category: Informational March 1996
+
+
+ TNVIP Protocol
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ The goal of this document specifies a Telnet profile to support VIP
+ terminal emulation allowing the access to the BULL hosts applications
+ through a TCP/IP network.
+
+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
+
+
+
+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. Motivation
+
+ P200 [7] and 7800 [8] VIP (Visual Information Projection) terminals
+ differ mainly from NVT terminals [1] in that they work in block mode
+ and have the capability to manage an associated printer. Generally in
+ a DSA (Distributed Systems Architecture) network they are managed
+ through the VIP transmission line procedure (character oriented).
+ That is the reason why they are generically referred as VIP
+ terminals.
+
+ This document specifies the options to be modified successfully, to
+ pass from the NVT terminal emulation supported on a Telnet
+ connection, to a VIP terminal emulation. It defines also the format
+ of the messages exchanged between the server and the client when the
+ TNVIP protocol is successfully negotiated.
+
+
+
+
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 2]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+2. Background
+
+ VIP terminal family includes a broad range of different terminal
+ types. They work in block mode with an ASCII or 8 binary bits set of
+ characters.
+
+ The Bull terminals in the DSA network environment use the services of
+ a Terminal Manager (TM) [2]. It is generally installed in a
+ communication processor (as a Datanet or Mainway system) where it
+ assures the connection with the BULL host application generally
+ through a DSA session.
+
+ The Terminal Manager is in charge to present the terminal station and
+ to manage the session connection to the host computer. It offers
+ generally a possibility of dialog with the terminal to allow the user
+ to modify the connection parameters, to manage the session
+ (connection request, abort, etc ..). The set of commands and
+ responses used is called "TM Local Dialog".
+
+3. Telnet Options and Commands Used
+
+ The mandatory telnet parameters to be negotiated successfully between
+ the "TNVIP server" and the "TNVIP client" are :
+
+ - the Terminal-Type option [3] to define a VIP terminal model and
+ if necessary 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. As the End Of Record (EOR) code indicates the end of
+ an effective data unit, Telnet should attempt to send the data up
+ to and including the EOR code together to promote communication
+ efficiency.
+
+ Others Telnet parameters, can be optionally negotiated as :
+
+ - the Binary Transmission option [5], when the terminal emulation
+ uses a 8 binary bits set of characters,
+
+ - the Suppress Go Ahead option [6], when no synchronisation of the
+ 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
+ negotiated successfully a TNVIP terminal type and the EOR telnet
+ option, that means they agree to respect the TNVIP protocol (the
+ TNVIP message format and the exchange rules).
+
+
+
+
+Dujonc Informational [Page 3]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+3.1 Terminal type option
+
+ IAC DO TERMINAL-TYPE
+
+ Sender (the "TNVIP server" party) is willing to receive terminal
+ type information in a subsequent sub-negotiation.
+
+ IAC WILL TERMINAL-TYPE
+
+ Sender (the terminal "TNVIP client" party) is willing to send
+ terminal-type information in a subsequent sub-negotiation.
+
+3.1.1 Subnegotiation of the Terminal Type
+
+ IAC SB TERMINAL-TYPE SEND IAC SE
+
+ Sender (the "TNVIP server" party) requests the receiver to
+ transmit his next terminal-type, and switch emulation modes (if
+ more than one terminal type is supported).
+
+ IAC SB TERMINAL-TYPE IS tnvip-terminal-model@MB-name IAC SE
+
+ Sender (the terminal "TNVIP client" party) is stating the name of
+ his 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 at the Telnet negotiation is
+ formatted as follows :
+
+ <TNVIP-terminal-model> [ <@ character> <Mailbox-name> ]
+
+ The @ character is used as separator between the VIP-terminal-model
+ and the Mailbox-name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 4]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+3.1.3 TNVIP terminal models
+
+ The valid TNVIP terminal models are the following ASCII character
+ strings. (The table gives for each terminal model string the
+ hexadecimal number indicating the associated 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 character at the end of the string indicates that the terminal
+ supports the Remote Forms function [9]. It is the capability to store
+ forms in the terminal allowing the host application to display a form
+ stored in the terminal sending a short length command without sending
+ all the data of the form. This function is usually supported by the
+ terminal concentrators.
+
+3.1.4 Mailbox name
+
+ The mailbox name allows the "TNVIP client" to request a specialized
+ access point referenced by this name in the "TNVIP server". It is an
+ ASCII character string. Its presence in the Telnet terminal type
+ string is optional. When not present, a generic (default) access can
+ be provided by the "TNVIP server".
+
+ 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 are processed as upper case. This string is generally
+ used to identify a specific terminal station (having a printer for
+ example) or to use a particular declaration of this terminal in the
+ "TNVIP server".
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 5]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+3.2 End of Record Option
+
+ VIP device communications are block oriented. That is, each partner
+ buffers data until an entire "message" has been built, at which point
+ the data are sent 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 within the Telnet
+ data stream. An <EOR> is sent at the end of each TNVIP message, in
+ both directions.
+
+ IAC WILL END-OF-RECORD
+
+ The sender of this command requests permission to begin
+ transmission of the Telnet END-OF-RECORD (EOR) code when
+ transmitting data characters, or the sender of this command
+ confirms it will now begin transmission of EORs with transmitted
+ data characters.
+
+ IAC DO END-OF-RECORD
+
+ The sender of this command requests that the sender of data starts
+ transmitting the EOR code when transmitting data, or the sender of
+ this command confirms that the sender of data is expected to
+ transmit EORs.
+
+3.3 Binary Transmission option
+
+ According to the character set used by the emulation, the "TNVIP
+ client" and the "TNVIP server" can be led to negotiate the Telnet
+ binary transmission option.
+
+ If either side wishes to transmit the decimal value 255 and have it
+ interpreted as data, it must "double" this byte. In other words, a
+ single occurrence of decimal 255 will be interpreted by the other
+ 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-BINARY
+
+ Sender requests that sender of the data starts transmitting or
+ confirms that the sender of data is expected to transmit
+ characters that are to be interpreted as 8 bits of binary data by
+ the receiver.
+
+ IAC WILL TRANSMIT-BINARY
+
+ Sender requests permission to begin transmitting, or confirms it
+ will now begin transmitting binary data.
+
+
+
+Dujonc Informational [Page 6]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ IAC WON'T TRANSMIT-BINARY
+
+ If the connection is already being operated in binary transmission
+ mode, the sender of this command demands to begin transmitting
+ data characters which are to be interpreted as standard NVT ASCII
+ characters by the receiver of the data. If the connection is not
+ already being operated in binary transmission mode, the sender of
+ this command refuses to begin transmitting characters which are to
+ be interpreted as binary characters by the receiver of the data
+ (i.e., the sender of the data requests to continue transmitting
+ characters in its present mode).
+
+ IAC DON'T TRANSMIT-BINARY
+
+ If the connection is already being operated in binary transmission
+ mode, the sender of this command requests that the sender of the
+ data start transmitting characters which are to be interpreted as
+ standard NVT ASCII characters by the receiver of the data
+ (i.e.,the party sending this command). If the connection is not
+ already being operated in binary transmission mode, the sender of
+ this command requests that the sender of data continue
+ transmitting characters which are to be interpreted in the present
+ mode.
+
+3.4 Suppress Go Ahead option
+
+ The "TNVIP client" can use the receiving of the Telnet GoAhead
+ command as the signal allowing the terminal operator to transmit
+ data. That can allow the synchronisation between the data transmitted
+ from the terminal and the DSA "turn".
+
+ 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 (from the "TNVIP client") is empty and the DSA turn is
+ at the terminal side, to invite the terminal to transmit some data.
+
+ To suppress this mechanism, the "TNVIP client" can request the no
+ 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" 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.
+
+
+
+
+
+Dujonc Informational [Page 7]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ IAC DO SUPPRESS-GO-AHEAD
+
+ The sender of this command (the "TNVIP client" party) requests that
+ the sender of data starts suppressing GA when transmitting data.
+
+ IAC WILL SUPPRESS-GO-AHEAD
+
+ The sender of this command (the "TNVIP server" party) confirms it
+ will now begin suppressing transmission of GAs with transmitted
+ data characters.
+
+ IAC DON'T SUPPRESSS-GO-AHEAD
+
+ The sender of this command (the "TNVIP client" party) requests
+ that the receiver of the command start transmitting GAs when
+ transmitting data.
+
+ IAC WON'T SUPPRESS-GO-AHEAD
+
+ The sender of this command (the "TNVIP server" party) confirms it
+ will now begin transmitting the GA character when transmitting
+ data characters.
+
+4. TNVIP functions
+
+ The TNVIP protocol allows the following functions :
+
+ - Support of a VIP terminal emulation addressing the screen and its
+ associated printer .
+
+ - Selection of the terminal type model at the connection time.
+
+ - Specific or generic access to the "TNVIP server" by referencing or
+ not a Mailbox name.
+
+ - TNVIP protocol independent of the terminal data presentation
+ 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 station
+
+ The "TNVIP client" acts as the interface adapter between the TNVIP
+ connection and an application program. The "TNVIP client" is mainly
+ defined to support a VIP terminal emulation program but can be used
+ 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 line
+
+ and runs using the following rules:
+
+ When the VIP terminal emulation exchanges a message on the
+ communication line, it is in the BUSY state until the end of the
+ message exchange. That means when the VIP terminal is sending a
+ message it can't receive and when it is receiving a message it can't
+ send.
+
+ Note: If a VIP terminal works in the half duplex mode, as the TNVIP
+ protocol uses a Telnet connection it allows a full duplex
+ mode processing.
+
+4.1.1 Local and online states
+
+ The VIP terminal has the capability to switch between these two
+ states. The LOCAL state is generally used to process local terminal
+ tests or to modify the configuration. In this state, the data coming
+ from the line are ignored.
+
+ The LOCAL state allows the "TNVIP client" to request to the server
+ the screen and printer data flows to be suspended.
+
+ The ONLINE state indication allows the "TNVIP server" to resume the
+ screen and printer flows.
+
+ For these reasons the TNVIP protocol differentiates the screen and
+ printer flows from the screen copy printing flow and defines to
+ report the two states to the "TNVIP server".
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 9]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+4.1.2 Data receiving
+
+ When a VIP terminal emulation receives a data message from the line,
+ according to the address given in the header message,it sends data to
+ the screen buffer or to the printer buffer.
+
+ 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 when the terminal is transmitting the 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" according to the
+ type of message received (request or indication) reports or not the
+ BUSY acknowledgement to the "TNVIP server".
+
+4.1.3 Data sending
+
+ A VIP terminal emulation can send message even if the terminal is in
+ the LOCAL state.
+
+4.2 TNVIP Server functions
+
+4.2.1 VIP Terminal Manager
+
+ Its function is to act as a gateway between the VIP terminal and the
+ VIP application. Generally the application is a remote DSA
+ application.
+
+ It manages the screen and printer devices of the VIP terminal
+ station.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 10]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ In the following example figure, the "TNVIP server" is a DSA server
+ and manages three VIP terminal units TU1, TU2 and TU3.
+
+ 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
+ representation to a logical representation where the station (SN
+ object) is the logical representation of a terminal unit, and the
+ logical device (LD) object a logical representation of the real
+ device.
+
+ - TU1 will be chosen by default on generic request (without mailbox
+ name) or by the MB1 name addressing on specific request. It can
+ manage the associated printer device.
+
+ - MB2 will be addressed to access the TU2 terminal unit. TU2 is
+ defined in a specific way because it will be presented to the host
+ application as a station composed of a screen (the TU2 one's) and
+ a printer (the TU3 one's).
+
+ - MB3 will be addressed to access TU3 terminal unit. TU3 is also
+ defined in a specific way because the printer device is shared by
+ several logical stations (SN2 and SN3) and must be well
+ identified.
+
+
+
+
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 11]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+5. TNVIP Messages Format
+
+ Each TNVIP message is delimited by the Telnet EOR command.
+
+ Therefore, a TNVIP message has the following format:
+
+ <TNVIP Header> <parameters> <IAC EOR>
+
+ The TNVIP header is mandatory and have a fixed length of two bytes.
+
+ Some TNVIP messages need no parameter. In this case, the TNVIP
+ message has the following construction:
+
+ <TNVIP Header> <IAC EOR>
+
+ It is strongly recommended that Telnet commands (other than IAC IAC)
+ should 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 the IAC-command sequence will be
+ 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.
+ It is because of this ambiguity that the presence of Telnet commands
+ within a TNVIP message is not recommended; neither "TNVIP client"s
+ nor "TNVIP server"s should send such data.
+
+ The TNVIP header contains 2 bytes. The first one indicates the
+ address <ADR> and the second 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.
+
+
+
+
+Dujonc Informational [Page 12]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+5.2 Command field
+
+ The <CDE> command field is mandatory and defined on one byte.
+
+ The command byte <CDE> is structured as follows:
+
+ <Command-Type><Message-Type>
+
+ - The Command-Type fills the six most significant bits of the <CDE>
+ byte. The most significant bit is always 0.
+
+ Its value is ranged from 0 to 31 included. 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.
+
+ 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 have 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.
+
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 13]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ The following table gives the <CDE> commands list with their
+ hexadecimal values
+
+ 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 47
+
+5.3 Parameter field
+
+ This field has a variable length and its content is depending on the
+ two previous fields (address and command).
+
+6. The screen flow
+
+ All the following messages contain the value SCREEN = 96 (0x60) in
+ the ADR field.
+
+6.1 Screen data messages
+
+ These messages are defined to transport 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, FC2 bytes are the functions codes of the VIP procedure
+ 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 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 = 5
+
+ Generally, 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 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 terminal. In this way, they have the indication that a secret
+ read (password acquisition) is requested by the "TNVIP server". When
+ the program is a terminal emulation this information is not necessary
+ because the data contains the terminal presentation command to
+ request this secret read.
+
+6.2 Local state monitoring messages
+
+ Before to switch in 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.
+
+ 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 others 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.
+
+
+
+
+
+
+Dujonc Informational [Page 15]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ <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 has never 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 an other 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.
+
+
+
+
+Dujonc Informational [Page 16]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+6.3.1 Page overflow processing
+
+ The page overflow processing is not supported through the TNVIP
+ protocol to avoid the retransmission of 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 message 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 which receive 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.
+
+ 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 transport 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, FC2 bytes are the function codes of the VIP procedure
+ 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 introducer
+ of the printer data.
+
+ To manage correctly the printer device, the protocol only defines
+ request message. Whereas the "TNVIP server" is ensured than the
+ "TNVIP client" processes a screen data message only when the previous
+ one have been processed. When it receives a printer data message, the
+ "TNVIP client" transfers it in 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) is not ended.
+
+ 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 are in the
+ presentation of the screen (7800 or P200 commands) and data are
+ converted by the terminal in the printer presentation (TTY, SDP,
+ copy. The second mode allows to give the printer data 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 are 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 are introduced by the command PHD (Print Host Data).
+
+ <CDE> = DATA request = 1 (0x01).
+
+7.2 Printer response messages
+
+ These messages are used to report the printing end status of the
+ printer data request previously received.
+
+ The following command values are defined as:
+
+ <CDE> = ACK response indication = 10 (0x0A). The printer data
+ previously received have been well processed.
+
+ <CDE> = ERR response indication = 14 (0x0E). The printer data
+ previously received have not been correctly processed (invalid
+ command, buffer overflow , printer off...)
+
+ <CDE> = BUSY response indication = 18 (0x12). The printer data
+ received have been deleted because the previous printing request is
+
+
+
+Dujonc Informational [Page 18]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ not ended. Several printer data request messages have been sent
+ without waiting for the response.
+
+ <CDE> = ABORTED response indication = 22 (0x14). The printing has
+ been aborted by the terminal operator.
+
+ <CDE> = PURGED response indication = 26 (0x18). The printing request
+ has been aborted by a printer data purge indication message.
+
+ <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The printer
+ device is not supported.
+
+ <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
+ printer request received has been deleted because an other printer
+ request is already in process. That means several printer 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
+ printer request received has been deleted because of an unknown
+ <CDE> field value. It is a consequence of the non-compliance of the
+ protocol. There is no parameter field.
+
+ For all the above commands, the parameter field may contain
+ specific terminal status if one was requested in the printer data
+ received (response to PDENQ 7800 terminal presentation command).
+
+7.3 7800 printer status management
+
+ When emulating a 7800 terminal [8], the "TNVIP client" takes charge
+ of adding to the printer data the printer differed status request
+ (PDENQ 7800 command) to synchronize the printing end with the sending
+ 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 beginning
+ of the printer data. That is the reason why when the "TNVIP client"
+ receives this command at the beginning of the printer data, it must
+ send back the 7800 status response in the parameter field of the
+ printer data response message.
+
+ The 7800 terminal presentation defines also immediate printer status
+ request and response (PENQ which allows to get an immediate response
+ indicating the current printer status). These commands have to be
+ exchanged in the TNVIP screen data flow.
+
+
+
+
+
+Dujonc Informational [Page 19]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+7.4 Printer state request message
+
+ This message is sent by the "TNVIP server" to know the printer state
+ of the "TNVIP client" without sending printer data.
+
+ The following command value is defined as:
+
+ <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" in order to report the
+ printer state to the "TNVIP server".
+
+ The following command values are defined as:
+
+ <CDE> = READY response indication = 58 (0x3A). The printer state is
+ ready to print. There is no parameter field.
+
+ <CDE> = STANDBY response indication = 62 (0x3E). The printer device
+ is in standby and is temporarily unavailable. There is no parameter
+ field.
+
+ <CDE> = PURGED response indication = 26 (0x1A). The printer state
+ request has been aborted by a printer state purge indication
+ message. There is no parameter field.
+
+ <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The printer
+ device is not supported. There is no parameter field.
+
+ <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
+ printer state request received has been deleted because an other
+ printer request is already in process. That means several printer
+ 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 printer
+ state 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.
+
+7.6 Printer purge indication message
+
+ This message is used by the "TNVIP server" to purge the current
+ printer request message. When the "TNVIP client" receives this
+ message, if it has not already acknowledged the printer data, it
+ aborts the printing and returns a printer data purge acknowledgement
+
+
+
+Dujonc Informational [Page 20]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ response message. If it has already replied, it ignores and deletes
+ the message.
+
+ The printer purge command value is defined as:
+
+ <CDE> = PURGE indication = 40 (0x28). There is no parameter field.
+
+8. The Screen Copy Printing flow
+
+ 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 messages
+
+ As the printer device can be used by the "TNVIP server", if the
+ terminal user wishes a screen copy printing, the "TNVIP" client has
+ to synchronize the user request with the "TNVIP server" printing .
+
+ The TNVIP protocol defines that the "TNVIP client" has to inform the
+ "TNVIP server" when it wants to print a screen copy and waits for its
+ authorization before beginning
+
+ The following command values are defined as:
+
+ <CDE> = COPY-REQ request = 65 (0x41). It is used from the "TNVIP
+ client" to the "TNVIP server" to request a screen copy printing.
+
+ <CDE> = LOCAL-COPY response and request = 71 (0x47). It is sent by
+ the "TNVIP server" to acknowledge the COPY-REQ message indicating
+ the screen copy can be done locally. It is also a request message
+ because it is equivalent to a screen copy data request message and
+ the "TNVIP server" is waiting for a screen copy response message
+ from the "TNVIP client" but on the SCPM flow. There is no parameter
+ field.
+
+8.2 Screen copy data message
+
+ They are defined in order to transport in the parameter of the
+ message the screen copy data in the terminal presentation. It is used
+ by the "TNVIP client" when it wants to send the screen copy data
+ directly to the DSA application (a VIP terminal using a VIP
+ transmission procedure indicates this special request by the STA byte
+ =PRT=0x1A).
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 21]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ The parameter field has the following format:
+
+ <FC1> <FC2> <STX> <screen-copy-data>
+
+ - The FC1, FC2 bytes are the functions codes of the VIP procedure
+ 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 introducer
+ of the screen data.
+
+ Screen copy data message can be sent in a request or indication
+ message.
+
+ The command values are defined as follows:
+
+ <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 following command values are defined as:
+
+ <CDE> = 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 parameter
+ field.
+
+ <CDE> = ERR response indication = 14 (0x0E). The screen copy has not
+ been correctly printed (invalid command, buffer overflow ...) or has
+ been refused by the "TNVIP server". 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 has
+ not been correctly printed because the printer device is already
+ printing. There is no parameter field.
+
+
+
+Dujonc Informational [Page 22]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ <CDE> = ABORTED response indication =22 (0x16). The screen copy has
+ been aborted by the terminal operator. There is no parameter field.
+
+ <CDE> = PURGED response indication = 26 (0x1A). The screen copy
+ request message has been aborted by a purge indication message.
+ There is no parameter field.
+
+ <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The screen
+ copy has not been correctly printed because the printer device is
+ not supported. There is no parameter field.
+
+ <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
+ screen copy request received has been deleted because an other
+ screen copy request is already in process. That means several screen
+ copy 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
+ copy 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.
+
+8.4 Screen copy purge indication message
+
+ This message is used to purge the current screen copy request
+ message. When the "TNVIP server" or the "TNVIP client" receives this
+ message, if it has not already acknowledged the request message, it
+ returns a screen copy purge acknowledgement message. If it has
+ already replied, it ignores and deletes the message.
+
+ The following command value is defined as:
+
+ <CDE> = PURGE indication = 40 (0x28).There is no parameter field.
+
+9. The TM attention
+
+ The TM attention is the signal used to activate the local dialog of
+ the DSA Terminal Manager.
+
+ The Telnet Abort Output (AO) command [1] is the mechanism used to
+ 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 as
+ 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 "TNVIP
+ server".
+
+ Upon receipt of the AO command, a "TNVIP server" that implements the
+ DSA Terminal Manager should enter in what will be loosely termed "TM
+ Local Dialog", suspending the eventual DSA host connection, else it
+ should simply ignore it.
+
+10. The Break Key
+
+ Generally, there is no break key on the real VIP terminal. The break
+ signal is transmitted to the host application through a TM local
+ dialog command ($*$BRK for example)
+
+ On "TNVIP client" emulating VIP terminal, it is often possible to map
+ the break signal on a special key combination or by other way (using
+ mouse ...).
+
+ 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 is
+ implemented on the "TNVIP server".
+
+ IAC IP (0xFF 0xF4)
+
+12. TNVIP messages list
+
+ All the TNVIP commands are summarized here after (and the values are
+ given in hexadecimal).
+
+12.1 Screen Flow
+
+ 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 EF
+
+ - Allowed responses to the screen Data request.
+
+ SCREEN ACK IAC EOR
+ 60 0A FF EF
+
+
+
+
+Dujonc Informational [Page 24]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ 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 EF
+
+ Password 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 EF
+
+ - Allowed 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 EF
+
+ Local state request (only from the "TNVIP client" to the "TNVIP
+ server").
+
+ SCREEN LOCAL-ST IAC EOR
+ 60 2D FF EF
+
+ - Allowed responses to the Local state request.
+
+ SCREEN ACK IAC EOR
+ 60 0A FF EF
+
+ SCREEN PURGED IAC EOR
+ 60 1A FF EF
+
+
+
+
+Dujonc Informational [Page 25]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ Responses to request violating the TNVIP protocol (allowed in the two
+ ways)
+
+ 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 EF
+
+ Indications (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 EF
+
+ Password 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 EF
+
+ On line state indication (only from the "TNVIP client" to the "TNVIP
+ server").
+
+ SCREEN ONLINE-ST IAC EOR
+ 60 30 FF EF
+
+12.2 Printer flow
+
+ 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 EF
+
+ - Allowed 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
+
+
+
+
+
+Dujonc Informational [Page 26]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ 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 EF
+
+ State request (only from the "TNVIP server" to the "TNVIP client")
+
+ PRINTER STATE-REQ IAC EOR
+ 68 35 FF EF
+
+ - Allowed 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 EF
+
+ Responses 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 EF
+
+ Indication (only from the "TNVIP server" to the "TNVIP client")
+
+ PRINTER PURGE IAC EOR
+ 68 28 FF EF
+
+
+
+
+
+
+
+Dujonc Informational [Page 27]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+12.3 Screen Copy Printing messages flow
+
+ Copy request (only from the "TNVIP client" to the "TNVIP server")
+
+ SCPM COPY-REQ IAC EOR
+ 69 41 FF EF
+
+ - Allowed 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 EF
+
+ Local copy request (only from the "TNVIP server" to the "TNVIP
+ client" )
+
+ SCPM LOCAL-COPY-RQ IAC EOR
+ 69 47 FF EF
+
+ - Allowed 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 EF
+
+
+
+Dujonc Informational [Page 28]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+ Data 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 EF
+
+ - Allowed 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 EF
+
+ Responses 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 EF
+
+ Indications (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 EF
+
+13. 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.
+
+
+
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 29]
+
+RFC 1921 TNVIP Protocol March 1996
+
+
+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
+
+
+
+
+
+
+
+
+
+
+Dujonc Informational [Page 30]
+