rfc1576.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 675 行 · 第 1/2 页


RFC 1576                TN3270 Current Practices            January 1994


      Server:  IAC DO ECHO
      Client:  IAC WILL ECHO
        (Client does local display of all characters)
      Server:  IAC WONT ECHO
      Client:  IAC DONT ECHO
        (Client enters password - not locally displayed or remotely
      echoed)
      Server:  IAC DO ECHO
      Client:  IAC WILL ECHO
     (Client resumes local display of all characters)

4.4 Timing Mark Option

   The Timing Mark option [10] is used by some servers to test for the
   continued presence of a TN3270 client. The following example will
   assure the server the client is still alive.

      Server:  IAC DO TIMING-MARK
      Client:  IAC WONT TIMING-MARK

5. Testing for session presence

   The NOP command (hexadecimal F1) [11] is used by some servers to test
   for the continued presence of a TN3270 client. If a client has
   terminated abnormally, TCP/IP send errors will occur. The Timing Mark
   option, described above, is also used to test for presence.

      Server:  IAC NOP
      Client:  <ignore / no response>

6. Handling 3270 data

   The 3270 data stream consists of a command and its associated data.
   Commands include but are not limited to erase screen, erase and write
   to screen and read current screen; see [6] for a complete description
   of 3270 commands and parameters.

   The reason for negotiating the EOR telnet option [4] is to provide a
   method for separating these commands since no length information is
   specified. 3270 commands are interpreted by the telnet client in
   their entirety.  Each 3270 command and possible data is terminated
   with the IAC EOR sequence.

   The Binary option [3] is also required since 3270 data may contain
   the FF (hexadecimal) or IAC character. When this character is
   encountered during a TN3270 connection it is handled as per the
   Binary RFC [3].




TN3270 Enhancements Working Group                               [Page 7]

RFC 1576                TN3270 Current Practices            January 1994


7. 3270 Structured Fields

   3270 structured fields provide a much wider range of features than
   "old-style" 3270 data, such as support for graphics, partitions and
   IPDS printer datastreams. A structured field is a 3270 data type that
   allows non 3270 data to be embedded within 3270 data. Briefly, a
   structured field consists of the structured field command followed by
   one or more data blocks. Each data block has a length and a
   structured field identifier, followed optionally by additional data.

   Not every TN3270 client can be expected to support all structured
   field functions.   There must be a  mechanism by which those clients
   that are capable of supporting some or all structured field functions
   can indicate their wishes. This is typically done by adding "-E" to
   the end of the terminal type string. That is, when the terminal
   identifies itself as being able to handle extended attributes, it
   also is capable of being able to send and receive structured fields.

   The design of 3270 structured fields provides a convenient means to
   convey the level of support (including no support) for the various
   structured field functions.  This mechanism is the Read Partition
   Query command, which is sent from the host application to the client.
   The client responds with a Query Reply, listing which, if any,
   structured field functions it supports.

   A TN3270 client that supports structured fields will respond to a
   Read Partition Query command with the appropriate reply.  The
   sequence of events when a client receives a Read Partition Query and
   does not support structured fields is left up to the client
   implementation.  Typically clients can identify at least this
   structured field and reply with a null set.

8. The 3270 ATTN (Attention) Key

   The 3270 ATTN key is interpreted by many host applications in an SNA
   environment as an indication that the user wishes to interrupt the
   execution of the current process.  A majority of the telnet servers
   currently accept the telnet IAC BREAK (code 243) [11] sequence to
   signal this event.

   Use of this key requires two things:

    - The TN3270 clients provide as part of their keyboard
      mapping a single key or a combination of keys that map to
      the 3270 ATTN key.  When the user presses this key(s), the
      client transmits a Telnet BREAK command to the server.





TN3270 Enhancements Working Group                               [Page 8]

RFC 1576                TN3270 Current Practices            January 1994


    - The TN3270 servers translate the BREAK command received from
      a TN3270 client into the appropriate form and pass it along
      to the host application as an ATTN key.  In other words, the
      server representing an SLU in an SNA session would send
      a SIGNAL RU to the host application.

   The ATTN key is not supported in a non-SNA environment; therefore, a
   TN3270 server representing non-SNA 3270 devices ignores any Telnet
   BREAK commands it receives from a client.

9. The 3270 SYSREQ Key

   The 3270 SYSREQ key is useful in an environment where the telnet
   server is attached to the host using SNA. The SYSREQ key is useful in
   this environment when the host application becomes locked or the user
   wishes to terminate the session without closing the Telnet
   connection.

   The Telnet Interrupt Process (IP) command [11] is interpreted by some
   telnet servers as a SYSREQ key. Other servers recognize the 3270 Test
   Request key as a SYSREQ key.  In an SNA environment, pressing this
   key toggles the terminal between the host application session and the
   SSCP session.  Usually the user will enter LOGOFF once this key has
   been pressed to terminate the application session and then select a
   new host to connect to.  Sometimes, if SYSREQ is pressed again, the
   host application will become unlocked and normal activities may then
   proceed.

   It is entirely up to the telnet server to interpret this command and
   send the appropriate commands to the host as well as format the
   resulting host data for display on the telnet client. The data format
   during the SSCP session is in a slightly different format than normal
   3270 data. Since the telnet server has no way to pass this data
   directly to the telnet client, it must either handle it entirely and
   ignore SYSREQ events or convert it to 3270  data to present to the
   client.

   To implement SYSREQ key support, TN3270 clients provide a key (or
   combination of keys) that is identified as mapping to the 3270 SYSREQ
   key.  When the user presses this key(s), the client would either
   transmit a Telnet IP command or Test Request key to the server,
   depending on the server implementation.

   TN3270 servers representing non-SNA 3270 terminals may ignore any
   Telnet IP commands or Test Request keys they receive from a client.






TN3270 Enhancements Working Group                               [Page 9]

RFC 1576                TN3270 Current Practices            January 1994


10. Items not addressed by TN3270

   There are several items that are not supported by current TN3270
   implementations; among them are the following:

    - TN3270 provides no capability for clients to emulate the 328x
      class of printers.

    - There is no mechanism by which a Telnet client can request that
      a connection be associated with a given 3270 device-name.  This
      can be of importance when a terminal session is being
      established, since many host applications behave differently
      depending on the network name of the terminal.

    - The 3270 ATTN and SYSREQ keys are not universally supported.

    - There is no support for the SNA positive/negative response
      process. All data that is sent is assumed to either be handled
      or ignored.  The lack of SNA response processing in TN3270 is
      part of what makes TN3270 efficient.
      A negative response indicates some sort of error at the client
      while processing the previously received data; this could be
      caused by the host application building a 3270 datastream that
      contains an invalid command, or by a mechanical error at the
      client side, among other things.
      Positive responses indicate processing of the previously received
      data has completed.

    - There is no mechanism by which the client can access the SNA
      BIND information.  The BIND image in a SNA environment
      contains a detailed description of the session between the
      telnet server and the host application.

    - The connection negotiation does not make it clear whether
      clients should support 3270 structured fields.

11. References

   [1] Rekhter, Y., "Telnet 3270 Regime Option", RFC 1041, IBM
       Corporation, January 1988.

   [2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP
       Software, Inc., February 1989.

   [3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD
       27, RFC 856, USC/Information Sciences Institute, May 1983.





TN3270 Enhancements Working Group                              [Page 10]

RFC 1576                TN3270 Current Practices            January 1994


   [4] Postel, J., "Telnet End of Record Option", RFC 885,
       USC/Information Sciences Institute, December 1983.

   [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

   [6] "3270 Information Display System - Data Stream Programmer's
       Reference", publication number GA23-0059, IBM Corporation.

   [7] "Systems Network Architecture - Formats", publication number
       GA27-3136, IBM Corporation.

   [8] Postel, J., and J. Reynolds, "Telnet Suppress Go Ahead Option",
       STD 29, RFC 858, USC/Information Sciences Institute, May 1983.

   [9] Postel, J., and J. Reynolds, "Telnet Echo Option", STD 28, RFC
       857, USC/Information Sciences Institute, May 1983.

  [10] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31,
       RFC 860, USC/Information Sciences Institute, May 1983.

  [11] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD
       8, RFC 854, USC/Information Sciences Institute, May 1983.

  [12] "Systems Network Architecture - Concepts and Products",
       publication number GC30-3072, IBM Corporation.

12. Security Considerations

   Security issues are not discussed in this memo.

13. Author's Note

   Portions of this document were drawn from the following sources:

    - A White Paper written by Owen Reddecliffe, WRQ Corporation,
      October 1991.

    - Experimental work on the part of Cleve Graves and Michelle
      Angel, OpenConnect Systems, 1992 - 1993.

    - Discussions at the March 1993 IETF meeting and TN3270 BOF at
      Interop August 1993.

    - Discussions on the "TN3270E" list, 1993.






TN3270 Enhancements Working Group                              [Page 11]

RFC 1576                TN3270 Current Practices            January 1994


14. Author's Address

   Jon Penner
   DCA, Inc.
   2800 Oakmont Drive
   Austin, TX 78664

   Phone: [phone] FAX
   EMail: [e-mail]
          or dca/g=Jon/s=Penner/ou=[e-mail]









































TN3270 Enhancements Working Group                              [Page 12]