home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1921.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  56.1 KB  |  1,684 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. Dujonc
  8. Request for Comments: 1921                                     Bull S.A.
  9. Category: Informational                                       March 1996
  10.  
  11.  
  12.                              TNVIP Protocol
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    The goal of this document specifies a Telnet profile to support VIP
  23.    terminal emulation allowing the access to the BULL hosts applications
  24.    through a TCP/IP network.
  25.  
  26. Table of Contents
  27.  
  28.     1.       Motivation . . . . . . . . . . . . . . . . . . . . . . 2
  29.     2.       Background . . . . . . . . . . . . . . . . . . . . . . 3
  30.     3.       Telnet Options and Commands Used . . . . . . . . . . . 3
  31.     3.1.      Terminal type option  . . . . . . . . . . . . . . . . 4
  32.     3.1.1.      Subnegotiation of the Terminal Type . . . . . . . . 4
  33.     3.1.2.      Terminal-types supported by the TNVIP protocol  . . 4
  34.     3.1.3.      TNVIP terminal models . . . . . . . . . . . . . . . 5
  35.     3.1.4.      Mailbox name  . . . . . . . . . . . . . . . . . . . 5
  36.     3.2.      End of Record Option  . . . . . . . . . . . . . . . . 6
  37.     3.3.      Binary Transmission option  . . . . . . . . . . . . . 6
  38.     3.4.      Suppress Go Ahead option  . . . . . . . . . . . . . . 7
  39.     4.       TNVIP functions  . . . . . . . . . . . . . . . . . . . 8
  40.     4.1.      TNVIP terminal station  . . . . . . . . . . . . . . . 9
  41.     4.1.1.      Local and online states . . . . . . . . . . . . . . 9
  42.     4.1.2.      Data receiving  . . . . . . . . . . . . . . . . .  10
  43.     4.1.3.      Data sending  . . . . . . . . . . . . . . . . . .  10
  44.     4.2.      TNVIP Server functions  . . . . . . . . . . . . . .  10
  45.     4.2.1.      VIP Terminal Manager  . . . . . . . . . . . . . .  10
  46.     5.       TNVIP Messages Format  . . . . . . . . . . . . . . .  12
  47.     5.1.      Address Field . . . . . . . . . . . . . . . . . . .  12
  48.     5.2.      Command field . . . . . . . . . . . . . . . . . . .  13
  49.     5.3.      Parameter field . . . . . . . . . . . . . . . . . .  14
  50.     6.       The screen flow  . . . . . . . . . . . . . . . . . .  14
  51.     6.1.      Screen data messages  . . . . . . . . . . . . . . .  14
  52.     6.2.      Local state monitoring messages . . . . . . . . . .  15
  53.     6.3.      Screen response messages  . . . . . . . . . . . . .  16
  54.     6.3.1      Page overflow processing . . . . . . . . . . . . .  17
  55.  
  56.  
  57.  
  58. Dujonc                       Informational                      [Page 1]
  59.  
  60. RFC 1921                     TNVIP Protocol                   March 1996
  61.  
  62.  
  63.     6.4.      Screen data purge indication message  . . . . . . .  17
  64.     7.       The printer flow . . . . . . . . . . . . . . . . . .  17
  65.     7.1.      Printer data messages . . . . . . . . . . . . . . .  17
  66.     7.2.      Printer response messages . . . . . . . . . . . . .  18
  67.     7.3.      7800 printer status management  . . . . . . . . . .  19
  68.     7.4.      Printer state request message   . . . . . . . . . .  20
  69.     7.5.      Printer state response messages . . . . . . . . . .  20
  70.     7.6.      Printer purge indication message  . . . . . . . . .  20
  71.     8.       The Screen Copy Printing flow  . . . . . . . . . . .  21
  72.     8.1.      Screen copy request messages  . . . . . . . . . . .  21
  73.     8.2.      Screen copy data message  . . . . . . . . . . . . .  21
  74.     8.3.      Screen copy response messages . . . . . . . . . . .  22
  75.     8.4.      Screen copy purge indication message  . . . . . . .  23
  76.     9.       The TM attention . . . . . . . . . . . . . . . . . .  23
  77.     10.      The Break Key  . . . . . . . . . . . . . . . . . . .  24
  78.     11.      The Logout Key . . . . . . . . . . . . . . . . . . .  24
  79.     12.      TNVIP messages list  . . . . . . . . . . . . . . . .  24
  80.     12.1.     Screen Flow . . . . . . . . . . . . . . . . . . . .  24
  81.     12.2.     Printer flow  . . . . . . . . . . . . . . . . . . .  26
  82.     12.3.     Screen Copy Printing messages flow  . . . . . . . .  28
  83.     13.      Security Considerations  . . . . . . . . . . . . . .  29
  84.     14.      References . . . . . . . . . . . . . . . . . . . . .  30
  85.     15.      Author's Address . . . . . . . . . . . . . . . . . .  30
  86.  
  87. 1. Motivation
  88.  
  89.    P200 [7] and 7800 [8] VIP (Visual Information Projection) terminals
  90.    differ mainly from NVT terminals [1] in that they work in block mode
  91.    and have the capability to manage an associated printer. Generally in
  92.    a DSA (Distributed Systems Architecture) network they are managed
  93.    through the VIP transmission line procedure (character oriented).
  94.    That is the reason why they are generically referred as VIP
  95.    terminals.
  96.  
  97.    This document specifies the options to be modified successfully, to
  98.    pass from the NVT terminal emulation supported on a Telnet
  99.    connection, to a VIP terminal emulation. It defines also the format
  100.    of the messages exchanged between the server and the client when the
  101.    TNVIP protocol is successfully negotiated.
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Dujonc                       Informational                      [Page 2]
  115.  
  116. RFC 1921                     TNVIP Protocol                   March 1996
  117.  
  118.  
  119. 2. Background
  120.  
  121.    VIP terminal family includes a broad range of different terminal
  122.    types. They work in block mode with an ASCII or 8 binary bits set of
  123.    characters.
  124.  
  125.    The Bull terminals in the DSA network environment use the services of
  126.    a Terminal Manager (TM) [2]. It is generally installed in a
  127.    communication processor (as a Datanet or Mainway system) where it
  128.    assures the connection with the BULL host application generally
  129.    through a DSA session.
  130.  
  131.    The Terminal Manager is in charge to present the terminal station and
  132.    to manage the session connection to the host computer. It offers
  133.    generally a possibility of dialog with the terminal to allow the user
  134.    to modify the connection parameters, to manage the session
  135.    (connection request, abort, etc ..). The set of commands and
  136.    responses used is called "TM Local Dialog".
  137.  
  138. 3. Telnet Options and Commands Used
  139.  
  140.    The mandatory telnet parameters to be negotiated successfully between
  141.    the "TNVIP server" and the "TNVIP client" are :
  142.  
  143.     - the Terminal-Type option [3] to define a VIP terminal model and
  144.       if necessary a Mailbox name to request a specific access point in
  145.       the "TNVIP server",
  146.  
  147.     - the End Of Record option [4] to delimit the TNVIP message at the
  148.       Telnet level. As the End Of Record (EOR) code indicates the end of
  149.       an effective data unit, Telnet should attempt to send the data up
  150.       to and including the EOR code together to promote communication
  151.       efficiency.
  152.  
  153.     Others Telnet parameters, can be optionally negotiated as :
  154.  
  155.     - the Binary Transmission option [5], when the terminal emulation
  156.       uses a 8 binary bits set of characters,
  157.  
  158.     - the Suppress Go Ahead option [6], when no synchronisation of the
  159.       data transmission from the "TNVIP client" with the DSA session
  160.       turn or the ISO session token is needed.
  161.  
  162.    When the two parties (the "TNVIP server" and the "TNVIP client") have
  163.    negotiated successfully a TNVIP terminal type and the EOR telnet
  164.    option, that means they agree to respect the TNVIP protocol (the
  165.    TNVIP message format and the exchange rules).
  166.  
  167.  
  168.  
  169.  
  170. Dujonc                       Informational                      [Page 3]
  171.  
  172. RFC 1921                     TNVIP Protocol                   March 1996
  173.  
  174.  
  175. 3.1 Terminal type option
  176.  
  177.    IAC DO TERMINAL-TYPE
  178.  
  179.       Sender (the "TNVIP server" party) is willing to receive terminal
  180.       type information in a subsequent sub-negotiation.
  181.  
  182.    IAC WILL TERMINAL-TYPE
  183.  
  184.       Sender (the terminal "TNVIP client" party) is willing to send
  185.       terminal-type information in a subsequent sub-negotiation.
  186.  
  187. 3.1.1 Subnegotiation of the Terminal Type
  188.  
  189.    IAC SB TERMINAL-TYPE SEND IAC SE
  190.  
  191.       Sender (the "TNVIP server" party) requests the receiver to
  192.       transmit his next terminal-type, and switch emulation modes (if
  193.       more than one terminal type is supported).
  194.  
  195.    IAC SB TERMINAL-TYPE IS tnvip-terminal-model@MB-name IAC SE
  196.  
  197.       Sender (the terminal "TNVIP client" party) is stating the name of
  198.       his current (or only) terminal-type. Optionally, a mailbox name
  199.       can be added to request a particular access point in the "TNVIP
  200.       server". By default, the "TNVIP server" uses a generic access
  201.       point.
  202.  
  203. 3.1.2 Terminal-types supported by the TNVIP protocol
  204.  
  205.    The TNVIP terminal type string given at the Telnet negotiation is
  206.    formatted as follows :
  207.  
  208.       <TNVIP-terminal-model> [ <@ character> <Mailbox-name> ]
  209.  
  210.    The @ character is used as separator between the VIP-terminal-model
  211.    and the Mailbox-name.
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Dujonc                       Informational                      [Page 4]
  227.  
  228. RFC 1921                     TNVIP Protocol                   March 1996
  229.  
  230.  
  231. 3.1.3 TNVIP terminal models
  232.  
  233.    The valid TNVIP terminal models are the following ASCII character
  234.    strings. (The table gives for each terminal model string the
  235.    hexadecimal number indicating the associated DSA model number defined
  236.    in the DSA terminal presentation protocols ).
  237.  
  238.                  P200 family                      7800 family
  239.     -------------------------------- --------------------------------
  240.     !   TNVIP model  !    DSA code ! !   TNVIP model  !    DSA code !
  241.     -------------------------------- --------------------------------
  242.     !   VIP7700      !       33    ! !   VIP7804      !       3E    !
  243.     !   VIP7760      !       3A    ! !   VIP7804V     !       4A    !
  244.     !   DKU7005      !       3D    ! !   VIP7814      !       47    !
  245.     !   DKU7007D     !       40    ! !   HDS7         !       4D    !
  246.     !   DKU7105      !       41    ! !   VIP8800      !       4F    !
  247.     !   DKU7107D     !       42    ! --------------------------------
  248.     !   DKU7211      !       45    !
  249.     !   DKU7211D     !       4E    !
  250.     --------------------------------
  251.  
  252.    The D character at the end of the string indicates that the terminal
  253.    supports the Remote Forms function [9]. It is the capability to store
  254.    forms in the terminal allowing the host application to display a form
  255.    stored in the terminal sending a short length command without sending
  256.    all the data of the form. This function is usually supported by the
  257.    terminal concentrators.
  258.  
  259. 3.1.4 Mailbox name
  260.  
  261.    The mailbox name allows the "TNVIP client" to request a specialized
  262.    access point referenced by this name in the "TNVIP server". It is an
  263.    ASCII character string. Its presence in the Telnet terminal type
  264.    string is optional. When not present, a generic (default) access can
  265.    be provided by the "TNVIP server".
  266.  
  267.    When the "TNVIP server" is a gateway to DSA hosts, the mailbox name
  268.    defines the DSA session access point of the terminal in the server.
  269.    Its length is limited to 12 characters. Lower case characters are
  270.    allowed but are processed as upper case. This string is generally
  271.    used to identify a specific terminal station (having a printer for
  272.    example) or to use a particular declaration of this terminal in the
  273.    "TNVIP server".
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Dujonc                       Informational                      [Page 5]
  283.  
  284. RFC 1921                     TNVIP Protocol                   March 1996
  285.  
  286.  
  287. 3.2 End of Record Option
  288.  
  289.    VIP device communications are block oriented. That is, each partner
  290.    buffers data until an entire "message" has been built, at which point
  291.    the data are sent to the other side. The end of a message is
  292.    understood to be the last byte transmitted. The Telnet EOR command is
  293.    used to delimit these natural blocks of TNVIP data within the Telnet
  294.    data stream. An <EOR> is sent at the end of each TNVIP message, in
  295.    both directions.
  296.  
  297.    IAC WILL END-OF-RECORD
  298.  
  299.       The sender of this command requests permission to begin
  300.       transmission of the Telnet END-OF-RECORD (EOR) code when
  301.       transmitting data characters, or the sender of this command
  302.       confirms it will now begin transmission of EORs with transmitted
  303.       data characters.
  304.  
  305.    IAC DO END-OF-RECORD
  306.  
  307.       The sender of this command requests that the sender of data starts
  308.       transmitting the EOR code when transmitting data, or the sender of
  309.       this command confirms that the sender of data is expected to
  310.       transmit EORs.
  311.  
  312. 3.3 Binary Transmission option
  313.  
  314.    According to the character set used by the emulation, the "TNVIP
  315.    client" and the "TNVIP server" can be led to negotiate the Telnet
  316.    binary transmission option.
  317.  
  318.    If either side wishes to transmit the decimal value 255 and have it
  319.    interpreted as data, it must "double" this byte. In other words, a
  320.    single occurrence of decimal 255 will be interpreted by the other
  321.    side as an IAC, while two successive bytes containing decimal 255
  322.    will be treated as one data byte with a value of decimal 255.
  323.  
  324.    IAC DO TRANSMIT-BINARY
  325.  
  326.       Sender requests that sender of the data starts transmitting or
  327.       confirms that the sender of data is expected to transmit
  328.       characters that are to be interpreted as 8 bits of binary data by
  329.       the receiver.
  330.  
  331.    IAC WILL TRANSMIT-BINARY
  332.  
  333.       Sender requests permission to begin transmitting, or confirms it
  334.       will now begin transmitting binary data.
  335.  
  336.  
  337.  
  338. Dujonc                       Informational                      [Page 6]
  339.  
  340. RFC 1921                     TNVIP Protocol                   March 1996
  341.  
  342.  
  343.    IAC WON'T TRANSMIT-BINARY
  344.  
  345.       If the connection is already being operated in binary transmission
  346.       mode, the sender of this command demands to begin transmitting
  347.       data characters which are to be interpreted as standard NVT ASCII
  348.       characters by the receiver of the data. If the connection is not
  349.       already being operated in binary transmission mode, the sender of
  350.       this command refuses to begin transmitting characters which are to
  351.       be interpreted as binary characters by the receiver of the data
  352.       (i.e., the sender of the data requests to continue transmitting
  353.       characters in its present mode).
  354.  
  355.    IAC DON'T TRANSMIT-BINARY
  356.  
  357.       If the connection is already being operated in binary transmission
  358.       mode, the sender of this command requests that the sender of the
  359.       data start transmitting characters which are to be interpreted as
  360.       standard NVT ASCII characters by the receiver of the data
  361.       (i.e.,the party sending this command). If the connection is not
  362.       already being operated in binary transmission mode, the sender of
  363.       this command requests that the sender of data continue
  364.       transmitting characters which are to be interpreted in the present
  365.       mode.
  366.  
  367. 3.4 Suppress Go Ahead option
  368.  
  369.    The "TNVIP client" can use the receiving of the Telnet GoAhead
  370.    command as the signal allowing the terminal operator to transmit
  371.    data. That can allow the synchronisation between the data transmitted
  372.    from the terminal and the DSA "turn".
  373.  
  374.    When the Suppress Go Ahead option is not negotiated, the "TNVIP
  375.    server" must send the Telnet Go Ahead command (GA) when its input
  376.    message queue (from the "TNVIP client") is empty and the DSA turn is
  377.    at the terminal side, to invite the terminal to transmit some data.
  378.  
  379.    To suppress this mechanism, the "TNVIP client" can request the no
  380.    sending of the Telnet GoAhead commands by the "TNVIP server",
  381.    negotiating the Suppress GO Ahead option of the Telnet Protocol.
  382.  
  383.    In this case, the terminal transmission to the "TNVIP server" is
  384.    synchronised on the transport credit.
  385.  
  386.    Note: The Telnet GA command never need to be sent by the "TNVIP
  387.          client" even if the telnet Suppress Go Ahead has not been
  388.          negotiated.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Dujonc                       Informational                      [Page 7]
  395.  
  396. RFC 1921                     TNVIP Protocol                   March 1996
  397.  
  398.  
  399.    IAC DO SUPPRESS-GO-AHEAD
  400.  
  401.    The sender of this command (the "TNVIP client" party) requests that
  402.    the sender of data starts suppressing GA when transmitting data.
  403.  
  404.    IAC WILL SUPPRESS-GO-AHEAD
  405.  
  406.       The sender of this command (the "TNVIP server" party) confirms it
  407.       will now begin suppressing transmission of GAs with transmitted
  408.       data characters.
  409.  
  410.    IAC DON'T SUPPRESSS-GO-AHEAD
  411.  
  412.       The sender of this command (the "TNVIP client" party) requests
  413.       that the receiver of the command start transmitting GAs when
  414.       transmitting data.
  415.  
  416.    IAC WON'T SUPPRESS-GO-AHEAD
  417.  
  418.       The sender of this command (the "TNVIP server" party) confirms it
  419.       will now begin transmitting the GA character when transmitting
  420.       data characters.
  421.  
  422. 4. TNVIP functions
  423.  
  424.    The TNVIP protocol allows the following functions :
  425.  
  426.     - Support of a VIP terminal emulation addressing the screen and its
  427.       associated printer .
  428.  
  429.     - Selection of the terminal type model at the connection time.
  430.  
  431.     - Specific or generic access to the "TNVIP server" by referencing or
  432.       not a Mailbox name.
  433.  
  434.     - TNVIP protocol independent of the terminal data presentation
  435.       protocol (7800 or P200).
  436.  
  437.     - Support of the DSA End To End Acknowledgement.
  438.  
  439.     - Support of the DSA Terminal Manager local attention.
  440.  
  441.     - Support of the DSA turn to the terminal side.
  442.  
  443.     - Support of the DSA secret read.
  444.  
  445.     - Control of the hard copy.
  446.  
  447.  
  448.  
  449.  
  450. Dujonc                       Informational                      [Page 8]
  451.  
  452. RFC 1921                     TNVIP Protocol                   March 1996
  453.  
  454.  
  455. 4.1 TNVIP terminal station
  456.  
  457.    The "TNVIP client" acts as the interface adapter between the TNVIP
  458.    connection and an application program. The "TNVIP client" is mainly
  459.    defined to support a VIP terminal emulation program but can be used
  460.    by other else program using the TNVIP protocol.
  461.  
  462.    A VIP terminal emulation manages:
  463.  
  464.     - a screen buffer,
  465.  
  466.     - a printer buffer if it supports the associated printer,
  467.  
  468.     - the interface with the communication line
  469.  
  470.    and runs using the following rules:
  471.  
  472.    When the VIP terminal emulation exchanges a message on the
  473.    communication line, it is in the BUSY state until the end of the
  474.    message exchange. That means when the VIP terminal is sending a
  475.    message it can't receive and when it is receiving a message it can't
  476.    send.
  477.  
  478.    Note: If a VIP terminal works in the half duplex mode, as the TNVIP
  479.          protocol uses a Telnet connection it allows a full duplex
  480.          mode processing.
  481.  
  482. 4.1.1 Local and online states
  483.  
  484.    The VIP terminal has the capability to switch between these two
  485.    states. The LOCAL state is generally used to process local terminal
  486.    tests or to modify the configuration. In this state, the data coming
  487.    from the line are ignored.
  488.  
  489.    The LOCAL state allows the "TNVIP client" to request to the server
  490.    the screen and printer data flows to be suspended.
  491.  
  492.    The ONLINE state indication allows the "TNVIP server" to resume the
  493.    screen and printer flows.
  494.  
  495.    For these reasons the TNVIP protocol differentiates the screen and
  496.    printer flows from the screen copy printing flow and defines to
  497.    report the two states to the "TNVIP server".
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Dujonc                       Informational                      [Page 9]
  507.  
  508. RFC 1921                     TNVIP Protocol                   March 1996
  509.  
  510.  
  511. 4.1.2 Data receiving
  512.  
  513.    When a VIP terminal emulation receives a data message from the line,
  514.    according to the address given in the header message,it sends data to
  515.    the screen buffer or to the printer buffer.
  516.  
  517.    A message received at the screen or printer address is deleted and
  518.    ignored if the terminal emulation is in the LOCAL state and a BUSY
  519.    status is returned.
  520.  
  521.    The printer buffer is busy when the terminal is transmitting the data
  522.    from the printer buffer to the printer device. A data message for the
  523.    printer is deleted and ignored if the terminal is in the printing
  524.    state and a BUSY status is returned.
  525.  
  526.    When a BUSY state is encountered, the "TNVIP client" according to the
  527.    type of message received (request or indication) reports or not the
  528.    BUSY acknowledgement to the "TNVIP server".
  529.  
  530. 4.1.3 Data sending
  531.  
  532.    A VIP terminal emulation can send message even if the terminal is in
  533.    the LOCAL state.
  534.  
  535. 4.2 TNVIP Server functions
  536.  
  537. 4.2.1 VIP Terminal Manager
  538.  
  539.    Its function is to act as a gateway between the VIP terminal and the
  540.    VIP application. Generally the application is a remote DSA
  541.    application.
  542.  
  543.    It manages the screen and printer devices of the VIP terminal
  544.    station.
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Dujonc                       Informational                     [Page 10]
  563.  
  564. RFC 1921                     TNVIP Protocol                   March 1996
  565.  
  566.  
  567.    In the following example figure, the "TNVIP server" is a DSA server
  568.    and manages three VIP terminal units TU1, TU2 and TU3.
  569.  
  570.     Generic access
  571.     --------------
  572.               !----> LD 1S ----> DV 1S (screen)  ---->!
  573.     MB 1 --> SN 1                                     TU 1
  574.               !----> LD 1P ----> DV 1P (printer) ---->!
  575.  
  576.     Specific accesses
  577.     -----------------
  578.               !----> LD 2S ----> DV 2S (screen)  ---->TU 2
  579.     MB 2 --> SN 2
  580.               !----> LD 2P ----> !
  581.                                  !
  582.               !----> LD 3P ----> DV 3S (printer) ---->!
  583.     MB 3 --> SN 3                                     TU 3
  584.               !----> LD 3S ----> DV 3P (screen)  ---->!
  585.  
  586.    Each Terminal Unit (TU object) is declared as containing one or two
  587.    devices (DV objects). The Terminal Manager maps this physical
  588.    representation to a logical representation where the station (SN
  589.    object) is the logical representation of a terminal unit, and the
  590.    logical device (LD) object a logical representation of the real
  591.    device.
  592.  
  593.     - TU1 will be chosen by default on generic request (without mailbox
  594.       name) or by the MB1 name addressing on specific request. It can
  595.       manage the associated printer device.
  596.  
  597.     - MB2 will be addressed to access the TU2 terminal unit. TU2 is
  598.       defined in a specific way because it will be presented to the host
  599.       application as a station composed of a screen (the TU2 one's) and
  600.       a printer (the TU3 one's).
  601.  
  602.     - MB3 will be addressed to access TU3 terminal unit. TU3 is also
  603.       defined in a specific way because the printer device is shared by
  604.       several logical stations (SN2 and SN3) and must be well
  605.       identified.
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Dujonc                       Informational                     [Page 11]
  619.  
  620. RFC 1921                     TNVIP Protocol                   March 1996
  621.  
  622.  
  623. 5. TNVIP Messages Format
  624.  
  625.    Each TNVIP message is delimited by the Telnet EOR command.
  626.  
  627.    Therefore, a TNVIP message has the following format:
  628.  
  629.     <TNVIP Header> <parameters> <IAC EOR>
  630.  
  631.    The TNVIP header is mandatory and have a fixed length of two bytes.
  632.  
  633.    Some TNVIP messages need no parameter. In this case, the TNVIP
  634.    message has the following construction:
  635.  
  636.     <TNVIP Header> <IAC EOR>
  637.  
  638.    It is strongly recommended that Telnet commands (other than IAC IAC)
  639.    should be sent between TNVIP messages, with no TNVIP header and no
  640.    trailing IAC EOR. If a TNVIP data message containing any other IAC-
  641.    command sequence (other than IAC IAC) is received, it is
  642.    implementation dependent when the IAC-command sequence will be
  643.    processed, but it must be processed. The receiver may process it
  644.    immediately, which in effect causes it to be processed as if it had
  645.    been received before the current TNVIP message, or the processing may
  646.    be deferred until after the current TNVIP message has been processed.
  647.    It is because of this ambiguity that the presence of Telnet commands
  648.    within a TNVIP message is not recommended; neither "TNVIP client"s
  649.    nor "TNVIP server"s should send such data.
  650.  
  651.    The TNVIP header contains 2 bytes. The first one indicates the
  652.    address <ADR> and the second the command <CDE>.
  653.  
  654. 5.1 Address Field
  655.  
  656.    The <ADR> address field is mandatory and is defined on one byte.
  657.  
  658.    The TNVIP protocol defines 3 addresses:
  659.  
  660.     - ADR = SCREEN  = 96 (0x60) for the screen commands flow,
  661.  
  662.     - ADR = PRINTER = 104 (0x68) for the printer commands flow,
  663.  
  664.     - ADR = SCPM    = 105 (0x69) for the screen copy printing commands
  665.       flow.
  666.  
  667.    A request message with an unknown or unsupported address will be
  668.    discarded by the receiver which replies with a NOT-AVAILABLE response
  669.    message.
  670.  
  671.  
  672.  
  673.  
  674. Dujonc                       Informational                     [Page 12]
  675.  
  676. RFC 1921                     TNVIP Protocol                   March 1996
  677.  
  678.  
  679. 5.2 Command field
  680.  
  681.    The <CDE> command field is mandatory and defined on one byte.
  682.  
  683.    The command byte <CDE> is structured as follows:
  684.  
  685.     <Command-Type><Message-Type>
  686.  
  687.     - The Command-Type fills the six most significant bits of the <CDE>
  688.       byte. The most significant bit is always 0.
  689.  
  690.       Its value is ranged from 0 to 31 included. It defines the command
  691.       associated to the message for the flow identified by the address
  692.       field.
  693.  
  694.     - The Message-Type fills the two less significant bits of the <CDE>
  695.       byte.
  696.  
  697.       0 = Indication message. No response message is expected. An
  698.       indication message with an undefined command type or with an
  699.       unknown address is deleted and ignored.
  700.  
  701.       1 = Request message. The sender of a request message is waiting
  702.       for a response message having the same address value. When a
  703.       request message is sent for a given address, it is not allowed to
  704.       send another request to the same address before the receiving
  705.       response. If an end point receives a request before having sent
  706.       the response of the previous request, it deletes the second
  707.       request but have to send back a PROTOCOL-VIOLATION response after
  708.       the response of the first request. A request message with a not
  709.       defined address is replied to by a NOT-AVAILABLE response message.
  710.       A request message with an unknown or unsupported command <CDE> for
  711.       this address will be deleted by the receiver and replied to by an
  712.       UNKNOWN-COMMAND response message.
  713.  
  714.       2 = Response message. This message is the response to the current
  715.       request message. The receiver of this message is allowed to send
  716.       another request message on the flow defined by the ADR field.
  717.  
  718.       3 = Response and request message. This message is a positive
  719.       response to the current request message sent by the receiver, but
  720.       is also a request message.
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Dujonc                       Informational                     [Page 13]
  731.  
  732. RFC 1921                     TNVIP Protocol                   March 1996
  733.  
  734.  
  735.    The following table gives the <CDE> commands list with their
  736.    hexadecimal values
  737.  
  738.     Command          Indication  Request  Response  Resp/Req
  739.     --------------------------------------------------------
  740.     DATA                00         01
  741.     PASSW               04         05
  742.     ACK                                      0A
  743.     ERROR                                    0E
  744.     BUSY                                     12
  745.     ABORTED                                  16
  746.     PURGED                                   1A
  747.     NOT-AVAILABLE                            1E
  748.     PROTOCOL-VIOLATION                       22
  749.     UNKNOWN-COMMAND                          26
  750.     PURGE               28
  751.     LOCAL-STATE                    2D
  752.     ONLINE-STATE        30
  753.     STATE-REQ                      35
  754.     READY                                    3A
  755.     STANDBY                                  3E
  756.     COPY-REQ                       41
  757.     LOCAL-COPY                                         47
  758.  
  759. 5.3 Parameter field
  760.  
  761.    This field has a variable length and its content is depending on the
  762.    two previous fields (address and command).
  763.  
  764. 6. The screen flow
  765.  
  766.    All the following messages contain the value SCREEN = 96 (0x60) in
  767.    the ADR field.
  768.  
  769. 6.1 Screen data messages
  770.  
  771.    These messages are defined to transport in the parameter field of the
  772.    TNVIP message, the data in the terminal presentation negotiated by
  773.    the "Terminal Type" telnet command.
  774.  
  775.    The parameter has the following format:
  776.  
  777.     <FC1> <FC2> <STX> < screen data>
  778.  
  779.     - The FC1, FC2 bytes are the functions codes of the VIP procedure
  780.       transmission [9]. Their values are comprised between 32 (0x20)
  781.       included and 127 (0x7F) included.
  782.  
  783.  
  784.  
  785.  
  786. Dujonc                       Informational                     [Page 14]
  787.  
  788. RFC 1921                     TNVIP Protocol                   March 1996
  789.  
  790.  
  791.     - The STX byte is defined by the value 2 and acts as the introducer
  792.       of the screen data.
  793.  
  794.    A screen data message can be sent in a request or in an indication
  795.    message. The command values are defined as follows:
  796.  
  797.     <CDE> = DATA indication = 0
  798.  
  799.     <CDE> = DATA request = 1
  800.  
  801.     <CDE> = PASSWORD indication = 4
  802.  
  803.     <CDE> = PASSWORD request = 5
  804.  
  805.    Generally, the "TNVIP server" only sends indication messages to the
  806.    screen. The request message is used mainly for the printer device.
  807.    But a DSA/TNVIP gateway server should use the screen data request
  808.    message when it processes a DSA end to end acknowledgement request
  809.    from the DSA application and synchronizes the response message
  810.    receipt with the DSA end to end acknowledgement.
  811.  
  812.    The password request and the password indication message are defined,
  813.    to be used by the programs in the "TNVIP client" machine which don't
  814.    emulate terminal. In this way, they have the indication that a secret
  815.    read (password acquisition) is requested by the "TNVIP server". When
  816.    the program is a terminal emulation this information is not necessary
  817.    because the data contains the terminal presentation command to
  818.    request this secret read.
  819.  
  820. 6.2 Local state monitoring messages
  821.  
  822.    Before to switch in the local state, the "TNVIP client" sends a
  823.    LOCAL-STATE request message to the "TNVIP server". This last one
  824.    sends back an acknowledgement message and suspends the screen and
  825.    printer data flow until it receives a LINE-STATE indication message.
  826.  
  827.    Note: In the local state, only the messages from the "TNVIP server"
  828.          to the screen or printer devices are deleted. The messages
  829.          from the "TNVIP client" screen device or the messages
  830.          associated to others addresses are allowed.
  831.  
  832.    The following command values are defined as:
  833.  
  834.     <CDE> = LOCAL-STATE request = 45 (0x2D). It is sent by the "TNVIP
  835.     client". There is no parameter field.
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Dujonc                       Informational                     [Page 15]
  843.  
  844. RFC 1921                     TNVIP Protocol                   March 1996
  845.  
  846.  
  847.     <CDE> = ONLINE-STATE indication = 48 (0x30). It is sent by the
  848.     "TNVIP client" to indicate the "TNVIP server" is allowed to resume
  849.     the screen data flow. There is no parameter field.
  850.  
  851. 6.3 Screen response messages
  852.  
  853.    These messages are indications used to respond to the screen data
  854.    request previously received.
  855.  
  856.    The command values are defined as follows:
  857.  
  858.     <CDE> = ACK response indication = 10 (0x0A). The screen data
  859.     previously received has been well processed or the LOCAL STATE is
  860.     acknowledged by the "TNVIP server". There is no parameter field.
  861.  
  862.     <CDE> = ERR response indication = 14 (0x0E). The screen data
  863.     previously received has not been correctly processed. There is no
  864.     parameter field.
  865.  
  866.     <CDE> = BUSY response indication = 18 (0x12). The screen data
  867.     previously received has been deleted because the terminal is in the
  868.     local state. There is no parameter field.
  869.  
  870.     <CDE> = ABORTED response indication = 22 (0x16). The receipt of the
  871.     screen data request has been aborted by a reset terminal command.
  872.     There is no parameter field.
  873.  
  874.     <CDE> = PURGED response indication = 26 (0x1A). The processing of
  875.     the screen data request has been aborted by a purge indication
  876.     message. There is no parameter field.
  877.  
  878.     <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The screen
  879.     device is not supported. Normally this command has never to be
  880.     generated because the screen device should always be present. There
  881.     is no parameter field.
  882.  
  883.     <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
  884.     screen request received has been deleted because an other screen
  885.     request is already in process. That means several screen request
  886.     messages have been sent without waiting for the response. It is a
  887.     consequence of the non-compliance of the protocol. There is no
  888.     parameter field.
  889.  
  890.     <CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The screen
  891.     request received has been deleted because the <CDE> field value is
  892.     unknown. It is a consequence of the non-compliance of the protocol.
  893.     There is no parameter field.
  894.  
  895.  
  896.  
  897.  
  898. Dujonc                       Informational                     [Page 16]
  899.  
  900. RFC 1921                     TNVIP Protocol                   March 1996
  901.  
  902.  
  903. 6.3.1 Page overflow processing
  904.  
  905.    The page overflow processing is not supported through the TNVIP
  906.    protocol to avoid the retransmission of the message. That leads the
  907.    "TNVIP client" side to process it locally. When a data message
  908.    induces a page overflow, the terminal emulation alerts the user
  909.    possibly requesting (in manual mode) an "enter" action before
  910.    clearing the screen and reprocessing the data received.
  911.  
  912.    Note: When the "TNVIP client" is processing a page overflow , the
  913.          terminal emulation should be in the BUSY state and should
  914.          stop getting message from the line ("TNVIP server") until the
  915.          page overflow processing is complete.
  916.  
  917. 6.4 Screen data purge indication message
  918.  
  919.    This message is used to purge the current screen request message.
  920.    When the side which receive the message has not already acknowledged
  921.    the screen request, it tries to abort the processing of the request
  922.    and returns a screen purged response message. If it has already
  923.    replied, it ignores and deletes the message.
  924.  
  925.    The following command value is defined as:
  926.  
  927.     <CDE> = PURGE indication = 40 (0x28). There is no parameter field.
  928.  
  929. 7. The printer flow
  930.  
  931.    All the following messages contain the PRINTER value 104 (0x68) in
  932.    the ADR field. The support of this address is optional. If the "TNVIP
  933.    server" doesn't address this device, no message with this address
  934.    will be exchanged. If the "TNVIP client" receives a request message
  935.    with this address and does not support the printer, it replies with a
  936.    printer NOT-AVAILABLE response message.
  937.  
  938. 7.1 Printer data messages
  939.  
  940.    These messages are defined to transport the printer data in the
  941.    parameter field of the TNVIP message. These messages are only sent
  942.    from the "TNVIP server" to the "TNVIP client".
  943.  
  944.    The parameter has the following format:
  945.  
  946.     <FC1> <FC2> <STX> <printer data>
  947.  
  948.     - The FC1, FC2 bytes are the function codes of the VIP procedure
  949.       transmission. Their values are ranged from  32 (0x20) to 127
  950.       (0x7F) included.
  951.  
  952.  
  953.  
  954. Dujonc                       Informational                     [Page 17]
  955.  
  956. RFC 1921                     TNVIP Protocol                   March 1996
  957.  
  958.  
  959.     - The STX byte is defined by the value 2 and acts as the introducer
  960.       of the printer data.
  961.  
  962.    To manage correctly the printer device, the protocol only defines
  963.    request message. Whereas the "TNVIP server" is ensured than the
  964.    "TNVIP client" processes a screen data message only when the previous
  965.    one have been processed. When it receives a printer data message, the
  966.    "TNVIP client" transfers it in the printer buffer. The terminal is
  967.    busy only during this transfer. So, if the "TNVIP client" receives
  968.    another printer data it deletes them because the previous printing
  969.    (transfer between the printer buffer and the printer) is not ended.
  970.  
  971.    The printer data structure depends on the terminal presentation
  972.    family (P200 or 7800). The two presentations define two modes of
  973.    printing. The first one needs the printer data are in the
  974.    presentation of the screen (7800 or P200 commands) and data are
  975.    converted by the terminal in the printer presentation (TTY, SDP,
  976.    copy. The second mode allows to give the printer data in the real
  977.    presentation of the printer. For this reason it is called
  978.    "transparent print".
  979.  
  980.    In the P200 terminal presentation, transparent print data are
  981.    introduced by the sequence of the two ASCII characters ESC Z (0x1B
  982.    0x5A ). P200 formatted print are introduced by the sequence of two
  983.    ASCII characters ESC X (0x1B 0x58) or ESC Y (0x1B 0x59).
  984.  
  985.    In the 7800 terminal presentation, transparent print data are
  986.    introduced by the command PTD (Print Transparent Data). 7800
  987.    formatted print are introduced by the command PHD (Print Host Data).
  988.  
  989.     <CDE> = DATA request = 1 (0x01).
  990.  
  991. 7.2 Printer response messages
  992.  
  993.    These messages are used to report the printing end status of the
  994.    printer data request previously received.
  995.  
  996.    The following command values are defined as:
  997.  
  998.     <CDE> = ACK response indication = 10 (0x0A). The printer data
  999.     previously received have been well processed.
  1000.  
  1001.     <CDE> = ERR response indication = 14 (0x0E). The printer data
  1002.     previously received have not been correctly processed (invalid
  1003.     command, buffer overflow , printer off...)
  1004.  
  1005.     <CDE> = BUSY response indication = 18 (0x12). The printer data
  1006.     received have been deleted because the previous printing request is
  1007.  
  1008.  
  1009.  
  1010. Dujonc                       Informational                     [Page 18]
  1011.  
  1012. RFC 1921                     TNVIP Protocol                   March 1996
  1013.  
  1014.  
  1015.     not ended. Several printer data request messages have been sent
  1016.     without waiting for the response.
  1017.  
  1018.     <CDE> = ABORTED  response indication = 22 (0x14). The printing has
  1019.     been aborted by the terminal operator.
  1020.  
  1021.     <CDE> = PURGED response indication = 26 (0x18). The printing request
  1022.     has been aborted by a printer data purge indication message.
  1023.  
  1024.     <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The printer
  1025.     device is not supported.
  1026.  
  1027.     <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
  1028.     printer request received has been deleted because an other printer
  1029.     request is already in process. That means several printer request
  1030.     messages have been sent without waiting for the response. It is a
  1031.     consequence of the non-compliance of the protocol. There is no
  1032.     parameter field.
  1033.  
  1034.     <CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The
  1035.     printer request received has been deleted because of an unknown
  1036.     <CDE> field value. It is a consequence of the non-compliance of the
  1037.     protocol. There is no parameter field.
  1038.  
  1039.     For all the above commands, the parameter field may contain
  1040.     specific terminal status if one was requested in the printer data
  1041.     received (response to PDENQ 7800 terminal presentation command).
  1042.  
  1043. 7.3 7800 printer status management
  1044.  
  1045.    When emulating a 7800 terminal [8], the "TNVIP client" takes charge
  1046.    of adding to the printer data the printer differed status request
  1047.    (PDENQ 7800 command) to synchronize the printing end with the sending
  1048.    of the printer acknowledgement response.
  1049.  
  1050.    Some DSA applications are written to manage the 7800 printer status,
  1051.    so they send themselves the printer status request at the beginning
  1052.    of the printer data. That is the reason why when the "TNVIP client"
  1053.    receives this command at the beginning of the printer data, it must
  1054.    send back the 7800 status response in the parameter field of the
  1055.    printer data response message.
  1056.  
  1057.    The 7800 terminal presentation defines also immediate printer status
  1058.    request and response (PENQ which allows to get an immediate response
  1059.    indicating the current printer status). These commands have to be
  1060.    exchanged in the TNVIP screen data flow.
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Dujonc                       Informational                     [Page 19]
  1067.  
  1068. RFC 1921                     TNVIP Protocol                   March 1996
  1069.  
  1070.  
  1071. 7.4 Printer state request message
  1072.  
  1073.    This message is sent by the "TNVIP server" to know the printer state
  1074.    of the "TNVIP client" without sending printer data.
  1075.  
  1076.    The following command value is defined as:
  1077.  
  1078.     <CDE> = STATE-REQ request = 53 (0x35). There is no parameter field.
  1079.  
  1080. 7.5 Printer state response messages
  1081.  
  1082.    These messages are sent by the "TNVIP client" in order to report the
  1083.    printer state to the "TNVIP server".
  1084.  
  1085.    The following command values are defined as:
  1086.  
  1087.     <CDE> = READY response indication = 58 (0x3A). The printer state is
  1088.     ready to print. There is no parameter field.
  1089.  
  1090.     <CDE> = STANDBY response indication = 62 (0x3E). The printer device
  1091.     is in standby and is temporarily unavailable. There is no parameter
  1092.     field.
  1093.  
  1094.     <CDE> = PURGED response indication = 26 (0x1A). The printer state
  1095.     request has been aborted by a printer state purge indication
  1096.     message. There is no parameter field.
  1097.  
  1098.     <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The printer
  1099.     device is not supported. There is no parameter field.
  1100.  
  1101.     <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
  1102.     printer state request received has been deleted because an other
  1103.     printer request is already in process. That means several printer
  1104.     request messages have been sent without waiting for the response. It
  1105.     is a consequence of the non-compliance of the protocol. There is no
  1106.     parameter field.
  1107.  
  1108.     <CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The printer
  1109.     state request received has been deleted because the <CDE> field
  1110.     value is unknown. It is a consequence of the non-compliance of the
  1111.     protocol. There is no parameter field.
  1112.  
  1113. 7.6 Printer purge indication message
  1114.  
  1115.    This message is used by the "TNVIP server" to purge the current
  1116.    printer request message. When the "TNVIP client" receives this
  1117.    message, if it has not already acknowledged the printer data, it
  1118.    aborts the printing and returns a printer data purge acknowledgement
  1119.  
  1120.  
  1121.  
  1122. Dujonc                       Informational                     [Page 20]
  1123.  
  1124. RFC 1921                     TNVIP Protocol                   March 1996
  1125.  
  1126.  
  1127.    response message. If it has already replied, it ignores and deletes
  1128.    the message.
  1129.  
  1130.    The printer purge command value is defined as:
  1131.  
  1132.     <CDE> = PURGE indication = 40 (0x28). There is no parameter field.
  1133.  
  1134. 8. The Screen Copy Printing flow
  1135.  
  1136.    All the following messages contain the SCPM address value 105 (0x69)
  1137.    in the ADR field. The support of this address is mandatory.
  1138.  
  1139. 8.1 Screen copy request messages
  1140.  
  1141.    As the printer device can be used by the "TNVIP server", if the
  1142.    terminal user wishes a screen copy printing, the "TNVIP" client has
  1143.    to synchronize the user request with the "TNVIP server" printing .
  1144.  
  1145.    The TNVIP protocol defines that the "TNVIP client" has to inform the
  1146.    "TNVIP server" when it wants to print a screen copy and waits for its
  1147.    authorization before beginning
  1148.  
  1149.    The following command values are defined as:
  1150.  
  1151.     <CDE> = COPY-REQ request = 65 (0x41). It is used from the "TNVIP
  1152.     client" to the "TNVIP server" to request a screen copy printing.
  1153.  
  1154.     <CDE> = LOCAL-COPY response and request = 71 (0x47). It is sent by
  1155.     the "TNVIP server" to acknowledge the COPY-REQ message indicating
  1156.     the screen copy can be done locally. It is also a request message
  1157.     because it is equivalent to a screen copy data request message and
  1158.     the "TNVIP server" is waiting for a screen copy response message
  1159.     from the "TNVIP client" but on the SCPM flow. There is no parameter
  1160.     field.
  1161.  
  1162. 8.2 Screen copy data message
  1163.  
  1164.    They are defined in order to transport in the parameter of the
  1165.    message the screen copy data in the terminal presentation. It is used
  1166.    by the "TNVIP client" when it wants to send the screen copy data
  1167.    directly to the DSA application (a VIP terminal using a VIP
  1168.    transmission procedure indicates this special request by the STA byte
  1169.    =PRT=0x1A).
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Dujonc                       Informational                     [Page 21]
  1179.  
  1180. RFC 1921                     TNVIP Protocol                   March 1996
  1181.  
  1182.  
  1183.    The parameter field has the following format:
  1184.  
  1185.     <FC1> <FC2> <STX> <screen-copy-data>
  1186.  
  1187.     - The FC1, FC2 bytes are the functions codes of the VIP procedure
  1188.       transmission. Their values are ranged from 32 (0x20) to 127
  1189.       (0x7F) included.
  1190.  
  1191.     - The STX byte is defined by the value 2 and acts as the introducer
  1192.       of the screen data.
  1193.  
  1194.    Screen copy data message can be sent in a request or indication
  1195.    message.
  1196.  
  1197.    The command values are defined as follows:
  1198.  
  1199.     <CDE> = DATA indication = 0
  1200.  
  1201.     <CDE> = DATA request = 1
  1202.  
  1203. 8.3 Screen copy response messages
  1204.  
  1205.    These messages are sent by the "TNVIP client" (local copy) to report
  1206.    the end of printing status of the screen copy.
  1207.  
  1208.    The ACK response is also used by the "TNVIP server" to acknowledge a
  1209.    screen copy data request sent to the host application.
  1210.  
  1211.    The ERR message is also used by the server to refuse a COPY-REQ
  1212.    message.
  1213.  
  1214.    The following command values are defined as:
  1215.  
  1216.     <CDE> = ACK response indication = 10 (0x0A). The "TNVIP client"
  1217.     reports the screen copy has been well printed or the "TNVIP server"
  1218.     acknowledges the screen copy data request. There is no parameter
  1219.     field.
  1220.  
  1221.     <CDE> = ERR response indication = 14 (0x0E). The screen copy has not
  1222.     been correctly printed (invalid command, buffer overflow ...) or has
  1223.     been refused by the "TNVIP server". It can optionally contain a
  1224.     reason code value defined on one byte.
  1225.  
  1226.     - 1 : The printer is busy, retry later.
  1227.  
  1228.     <CDE> = BUSY response indication = 18 (0x12). The screen copy has
  1229.     not been correctly printed because the printer device is already
  1230.     printing. There is no parameter field.
  1231.  
  1232.  
  1233.  
  1234. Dujonc                       Informational                     [Page 22]
  1235.  
  1236. RFC 1921                     TNVIP Protocol                   March 1996
  1237.  
  1238.  
  1239.     <CDE> = ABORTED  response indication =22 (0x16). The screen copy has
  1240.     been aborted by the terminal operator. There is no parameter field.
  1241.  
  1242.     <CDE> = PURGED response indication = 26 (0x1A). The screen copy
  1243.     request message has been aborted by a purge indication message.
  1244.     There is no parameter field.
  1245.  
  1246.     <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The screen
  1247.     copy has not been correctly printed because the printer device is
  1248.     not supported. There is no parameter field.
  1249.  
  1250.     <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
  1251.     screen copy request received has been deleted because an other
  1252.     screen copy request is already in process. That means several screen
  1253.     copy request messages have been sent without waiting for the
  1254.     response. It is a consequence of the non-compliance of the protocol.
  1255.     There is no parameter field.
  1256.  
  1257.     <CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The screen
  1258.     copy request received has been deleted because the <CDE> field value
  1259.     is unknown. It is a consequence of the non-compliance of the
  1260.     protocol. There is no parameter field.
  1261.  
  1262. 8.4 Screen copy purge indication message
  1263.  
  1264.    This message is used to purge the current screen copy request
  1265.    message. When the "TNVIP server" or the "TNVIP client" receives this
  1266.    message, if it has not already acknowledged the request message, it
  1267.    returns a screen copy purge acknowledgement message. If it has
  1268.    already replied, it ignores and deletes the message.
  1269.  
  1270.    The following command value is defined as:
  1271.  
  1272.     <CDE> = PURGE indication = 40 (0x28).There is no parameter field.
  1273.  
  1274. 9. The TM attention
  1275.  
  1276.    The TM attention is the signal used to activate the local dialog of
  1277.    the DSA Terminal Manager.
  1278.  
  1279.    The Telnet Abort Output (AO) command [1] is the mechanism used to
  1280.    implement the TM attention key support in TNVIP.
  1281.  
  1282.    IAC AO (0xFF 0xF5)
  1283.  
  1284.    In order to implement the TM attention key support, "TNVIP clients"
  1285.    should provide a key (or combination of keys) that is identified as
  1286.    mapping to the TM attention key. When the user presses this key(s),
  1287.  
  1288.  
  1289.  
  1290. Dujonc                       Informational                     [Page 23]
  1291.  
  1292. RFC 1921                     TNVIP Protocol                   March 1996
  1293.  
  1294.  
  1295.    the "TNVIP client" should transmit a Telnet AO command to the "TNVIP
  1296.    server".
  1297.  
  1298.    Upon receipt of the AO command, a "TNVIP server" that implements the
  1299.    DSA Terminal Manager should enter in what will be loosely termed "TM
  1300.    Local Dialog", suspending the eventual DSA host connection, else it
  1301.    should simply ignore it.
  1302.  
  1303. 10. The Break Key
  1304.  
  1305.    Generally, there is no break key on the real VIP terminal. The break
  1306.    signal is transmitted to the host application through a TM local
  1307.    dialog command ($*$BRK for example)
  1308.  
  1309.    On "TNVIP client" emulating VIP terminal, it is often possible to map
  1310.    the break signal on a special key combination or by other way (using
  1311.    mouse ...).
  1312.  
  1313.    The Telnet Break (BRK) command [1] is used to map the Break signal of
  1314.    the TNVIP.
  1315.  
  1316.    IAC BRK (0xFF 0xF3)
  1317.  
  1318. 11. The Logout Key
  1319.  
  1320.    The Telnet Interrupt Process (IP) command [1] can be used to map the
  1321.    logout command of the TM Local Dialog ($*$LO for example) if it is
  1322.    implemented on the "TNVIP server".
  1323.  
  1324.    IAC IP (0xFF 0xF4)
  1325.  
  1326. 12. TNVIP messages list
  1327.  
  1328.    All the TNVIP commands are summarized here after (and the values are
  1329.    given in hexadecimal).
  1330.  
  1331. 12.1 Screen Flow
  1332.  
  1333.    Data request (allowed in the two ways)
  1334.  
  1335.     SCREEN DATA-REQ <FC1> <FC2> STX [<screen-data>]  IAC EOR
  1336.     60     01       <FC1> <FC2> 02  [<screen-data>]  FF  EF
  1337.  
  1338.     - Allowed responses to the screen Data request.
  1339.  
  1340.       SCREEN ACK  IAC EOR
  1341.       60     0A   FF  EF
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Dujonc                       Informational                     [Page 24]
  1347.  
  1348. RFC 1921                     TNVIP Protocol                   March 1996
  1349.  
  1350.  
  1351.       SCREEN ERROR  IAC EOR
  1352.       60     0E     FF  EF
  1353.  
  1354.       SCREEN BUSY  IAC EOR
  1355.       60     12    FF  EF
  1356.  
  1357.       SCREEN ABORTED  IAC EOR
  1358.       60     16       FF  EF
  1359.  
  1360.       SCREEN PURGED  IAC EOR
  1361.       60     1A      FF  EF
  1362.  
  1363.    Password request (only from the "TNVIP server" to the "TNVIP client")
  1364.  
  1365.     SCREEN PASSW-REQ <FC1> <FC2> STX [<screen-data>]  IAC EOR
  1366.     60     05        <FC1> <FC2> 02  [<screen-data>]  FF  EF
  1367.  
  1368.     - Allowed responses to the password request.
  1369.  
  1370.       SCREEN ACK  IAC EOR
  1371.       60     0A   FF  EF
  1372.  
  1373.       SCREEN ERROR  IAC EOR
  1374.       60     0E     FF  EF
  1375.  
  1376.       SCREEN BUSY  IAC EOR
  1377.       60     12    FF   EF
  1378.  
  1379.       SCREEN ABORTED  IAC EOR
  1380.       60     16       FF  EF
  1381.  
  1382.       SCREEN PURGED  IAC EOR
  1383.       60     1A      FF  EF
  1384.  
  1385.    Local state request (only from the "TNVIP client" to the "TNVIP
  1386.    server").
  1387.  
  1388.     SCREEN LOCAL-ST IAC EOR
  1389.     60     2D       FF  EF
  1390.  
  1391.     - Allowed responses to the Local state request.
  1392.  
  1393.       SCREEN ACK  IAC EOR
  1394.       60     0A   FF  EF
  1395.  
  1396.       SCREEN PURGED  IAC EOR
  1397.       60 1A FF EF
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Dujonc                       Informational                     [Page 25]
  1403.  
  1404. RFC 1921                     TNVIP Protocol                   March 1996
  1405.  
  1406.  
  1407.    Responses to request violating the TNVIP protocol (allowed in the two
  1408.    ways)
  1409.  
  1410.     SCREEN NOT-AVAIL  IAC EOR
  1411.     60     0E         FF  EF
  1412.  
  1413.     SCREEN PROT-VIOL  IAC EOR
  1414.     60     22         FF  EF
  1415.  
  1416.     SCREEN UNKN-CDE  IAC EOR
  1417.     60     26        FF  EF
  1418.  
  1419.    Indications (allowed in the two ways)
  1420.  
  1421.     SCREEN DATA-IND <FC1> <FC2> STX [<screen-data>]  IAC EOR
  1422.     60     00       <FC1> <FC2> 02  [<screen-data>]  FF  EF
  1423.  
  1424.     SCREEN PURGE  IAC EOR
  1425.     60     28     FF  EF
  1426.  
  1427.    Password indication (only from the "TNVIP server" to the "TNVIP
  1428.    client").
  1429.  
  1430.     SCREEN PASSW-IND <FC1> <FC2> STX [<screen-data>]  IAC EOR
  1431.     60     04        <FC1> <FC2> 02  [<screen-data>]  FF  EF
  1432.  
  1433.    On line state indication (only from the "TNVIP client" to the "TNVIP
  1434.    server").
  1435.  
  1436.     SCREEN ONLINE-ST  IAC EOR
  1437.     60     30         FF  EF
  1438.  
  1439. 12.2 Printer flow
  1440.  
  1441.    Data request (only from the "TNVIP server" to the "TNVIP client")
  1442.  
  1443.     PRINTER DATA-REQ <FC1> <FC2> STX [<printer-data>]  IAC EOR
  1444.     68 01 <FC1> <FC2> 02 [<printer-data>] FF EF
  1445.  
  1446.     - Allowed responses to the printer data request.
  1447.  
  1448.       PRINTER ACK [<status>]  IAC EOR
  1449.       68      0A  [<status>]  FF  EF
  1450.  
  1451.       PRINTER ERROR  [<status>] IAC EOR
  1452.       68      0E     [<status>] FF  EF
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Dujonc                       Informational                     [Page 26]
  1459.  
  1460. RFC 1921                     TNVIP Protocol                   March 1996
  1461.  
  1462.  
  1463.       PRINTER BUSY [<status>]  IAC EOR
  1464.       68      12   [<status>]  FF  EF
  1465.  
  1466.       PRINTER ABORTED  [<status>] IAC EOR
  1467.       68      16       [<status>] FF  EF
  1468.  
  1469.       PRINTER PURGED  [<status>] IAC EOR
  1470.       68      1A      [<status>] FF  EF
  1471.  
  1472.       PRINTER NOT-AVAIL  [<status>] IAC EOR
  1473.       68      1E         [<status>] FF  EF
  1474.  
  1475.    State request (only from the "TNVIP server" to the "TNVIP client")
  1476.  
  1477.     PRINTER STATE-REQ  IAC EOR
  1478.     68      35         FF  EF
  1479.  
  1480.     - Allowed responses to the state request.
  1481.  
  1482.       PRINTER READY  IAC EOR
  1483.       68      3A     FF  EF
  1484.  
  1485.       PRINTER STANDBY  IAC EOR
  1486.       68      3E       FF  EF
  1487.  
  1488.       PRINTER PURGED  IAC EOR
  1489.       68      1A      FF  EF
  1490.  
  1491.       PRINTER NOT-AVAIL  IAC EOR
  1492.       68      1E         FF  EF
  1493.  
  1494.    Responses to request violating the TNVIP protocol (allowed in the two
  1495.    ways)
  1496.  
  1497.     PRINTER PROT-VIOL  IAC EOR
  1498.     68      22         FF  EF
  1499.  
  1500.     PRINTER UNKN-CDE  IAC EOR
  1501.     68      26        FF  EF
  1502.  
  1503.    Indication (only from the "TNVIP server" to the "TNVIP client")
  1504.  
  1505.     PRINTER PURGE  IAC EOR
  1506.     68 28 FF EF
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Dujonc                       Informational                     [Page 27]
  1515.  
  1516. RFC 1921                     TNVIP Protocol                   March 1996
  1517.  
  1518.  
  1519. 12.3 Screen Copy Printing messages flow
  1520.  
  1521.    Copy request (only from the "TNVIP client" to the "TNVIP server")
  1522.  
  1523.     SCPM COPY-REQ  IAC EOR
  1524.     69   41        FF  EF
  1525.  
  1526.     - Allowed responses to the copy request (from the "TNVIP server" to
  1527.       the "TNVIP client")
  1528.  
  1529.       SCPM  ERROR  <reason> IAC EOR
  1530.       69    0E     <reason> FF  EF
  1531.  
  1532.       SCPM  PURGED  IAC EOR
  1533.       69    1A      FF  EF
  1534.  
  1535.       SCPM  NOT-AVAIL  IAC EOR
  1536.       69    1E         FF  EF
  1537.  
  1538.       SCPM  LOCAL-COPY-RQ   IAC EOR
  1539.       69    47              FF  EF
  1540.  
  1541.    Local copy request (only from the "TNVIP server" to the "TNVIP
  1542.    client" )
  1543.  
  1544.     SCPM  LOCAL-COPY-RQ   IAC EOR
  1545.     69    47              FF  EF
  1546.  
  1547.     - Allowed responses to the local copy request (from the "TNVIP
  1548.       client" to the "TNVIP server").
  1549.  
  1550.       SCPM ACK  IAC EOR
  1551.       69   0A   FF  EF
  1552.  
  1553.       SCPM ERROR  IAC EOR
  1554.       69   0E     FF  EF
  1555.  
  1556.       SCPM BUSY IAC EOR
  1557.       69   12   FF  EF
  1558.  
  1559.       SCPM ABORTED IAC EOR
  1560.       69   16      FF  EF
  1561.  
  1562.       SCPM PURGED IAC EOR
  1563.       69   1A     FF  EF
  1564.  
  1565.       SCPM NOT-AVAIL IAC EOR
  1566.       69   1E        FF  EF
  1567.  
  1568.  
  1569.  
  1570. Dujonc                       Informational                     [Page 28]
  1571.  
  1572. RFC 1921                     TNVIP Protocol                   March 1996
  1573.  
  1574.  
  1575.    Data request. (only from the "TNVIP client" to the "TNVIP server")
  1576.  
  1577.     SCPM DATA-REQ <FC1> <FC2> STX [<screen-data>]  IAC EOR
  1578.     69   01       <FC1> <FC2> 02  [<screen-data>]  FF  EF
  1579.  
  1580.    - Allowed responses to the data request
  1581.  
  1582.       SCPM ACK  IAC EOR
  1583.       69   0A   FF  EF
  1584.  
  1585.       SCPM PURGED IAC EOR
  1586.       69   1A     FF  EF
  1587.  
  1588.       SCPM NOT-AVAIL IAC EOR
  1589.       69   1E        FF  EF
  1590.  
  1591.    Responses to request violating the TNVIP protocol (allowed in the two
  1592.    ways)
  1593.  
  1594.     SCPM PROT-VIOL  IAC EOR
  1595.     69   22         FF  EF
  1596.  
  1597.     SCPM UNKN-CDE  IAC EOR
  1598.     69   26        FF  EF
  1599.  
  1600.     Indications (allowed in the two ways)
  1601.  
  1602.     SCPM DATA-IND <FC1> <FC2> STX [<screen-data>]  IAC EOR
  1603.     69   00       <FC1> <FC2> 02  [<screen-data>]  FF  EF
  1604.  
  1605.     SCPM PURGE  IAC EOR
  1606.     69   28     FF  EF
  1607.  
  1608. 13.  Security Considerations
  1609.  
  1610.    Security issues are not addressed in this document.  It is
  1611.    anticipated that once authentication mechanisms have become well
  1612.    established, use of them can be made by TNVIP.  One of the important
  1613.    uses of authentication would be to answer the question of whether or
  1614.    not a given user should be allowed to "use" a specific terminal.
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Dujonc                       Informational                     [Page 29]
  1627.  
  1628. RFC 1921                     TNVIP Protocol                   March 1996
  1629.  
  1630.  
  1631. 14. References
  1632.  
  1633.    [1] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD
  1634.        8, RFC 854, USC/Information Sciences Institute, May 1983.
  1635.  
  1636.    [2] "Communications. MainWay. Terminal Management. DNS-E",
  1637.        Ref : 39A213EB Rev00, BULL S.A.
  1638.  
  1639.    [3] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP
  1640.        Software, Inc., February 1989.
  1641.  
  1642.    [4] Postel, J., "Telnet End of Record Option", RFC 885,
  1643.        USC/Information Sciences Institute, December 1983.
  1644.  
  1645.    [5] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD
  1646.        27, RFC 856, USC/Information Sciences Institute, May 1983.
  1647.  
  1648.    [6] Postel, J., and J. Reynolds, "Telnet Suppress Go Ahead Option",
  1649.        STD 29, RFC 858, USC/Information Sciences Institute, May 1983.
  1650.  
  1651.    [7] "Affinity V2. DKU7107 Reference Manual"
  1652.        Ref : 40 A2 23 WA, BULL S.A.
  1653.  
  1654.    [8] "Affinity V2. VIP7800 Reference Manual"
  1655.        Ref : 40 A2 24 WA,  BULL S.A.
  1656.  
  1657.    [9] "Bull Questar 200. TCS 7424 et TCS 7434. Transmission de donnees.
  1658.        Manuel de  reference"
  1659.        Ref : 80 F2 41DC Rev0,  BULL S.A.
  1660.  
  1661. 15. Author's Address
  1662.  
  1663.    Jean-Yves Dujonc
  1664.    BULL S.A.
  1665.    rue Jean Jaures
  1666.    78340 Les Clayes-sous-Bois
  1667.    France
  1668.  
  1669.    Phone: 1 30 80 62 95
  1670.    Fax:   1 30 80 65 40
  1671.    EMail: J.Y.Dujonc@frcl.bull.fr
  1672.  
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Dujonc                       Informational                     [Page 30]
  1683.  
  1684.