rfc1921.txt

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

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]