rfc1921.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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.