rfc1921.txt

中、英文RFC文档大全打包下载完全版 .


RFC 1921                     TNVIP Protocol                   March 1996


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

6.3 Screen response messages

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

   The command values are defined as follows:

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

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

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

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

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

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

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

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




Dujonc                       Informational                     [Page 16]

RFC 1921                     TNVIP Protocol                   March 1996


6.3.1 Page overflow processing

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

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

6.4 Screen data purge indication message

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

   The following command value is defined as:

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

7. The printer flow

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

7.1 Printer data messages

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

   The parameter has the following format:

    <FC1> <FC2> <STX> <printer data>

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



Dujonc                       Informational                     [Page 17]

RFC 1921                     TNVIP Protocol                   March 1996


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

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

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

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

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

    <CDE> = DATA request = 1 (0x01).

7.2 Printer response messages

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

   The following command values are defined as:

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

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

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



Dujonc                       Informational                     [Page 18]

RFC 1921                     TNVIP Protocol                   March 1996


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

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

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

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

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

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

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

7.3 7800 printer status management

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

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

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





Dujonc                       Informational                     [Page 19]

RFC 1921                     TNVIP Protocol                   March 1996


7.4 Printer state request message

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

   The following command value is defined as:

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

7.5 Printer state response messages

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

   The following command values are defined as:

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

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

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

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

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

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

7.6 Printer purge indication message

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



Dujonc                       Informational                     [Page 20]

RFC 1921                     TNVIP Protocol                   March 1996


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

   The printer purge command value is defined as:

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

8. The Screen Copy Printing flow

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

8.1 Screen copy request messages

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

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

   The following command values are defined as:

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

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

8.2 Screen copy data message

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








Dujonc                       Informational                     [Page 21]

RFC 1921                     TNVIP Protocol                   March 1996


   The parameter field has the following format:

    <FC1> <FC2> <STX> <screen-copy-data>

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

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

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

   The command values are defined as follows:

    <CDE> = DATA indication = 0

    <CDE> = DATA request = 1

8.3 Screen copy response messages

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

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

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

   The following command values are defined as:

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

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

    - 1 : The printer is busy, retry later.

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



Dujonc                       Informational                     [Page 22]

RFC 1921                     TNVIP Protocol                   March 1996


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

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

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

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

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

8.4 Screen copy purge indication message