home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1646 < prev    next >
Text File  |  1994-07-13  |  28KB  |  732 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         C. Graves
  8. Request for Comments: 1646                                     T. Butts
  9. Category: Informational                                        M. Angel
  10.                                                    Open Connect Systems
  11.                                                               July 1994
  12.  
  13.  
  14.            TN3270 Extensions for LUname and Printer Selection
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document describes protocol extensions to TN3270.  There are two
  25.    extensions outlined in this document.  The first defines a way by
  26.    which a TN3270 client can request a specific device (LUname) from a
  27.    TN3270 server.  The second extension specifies how a TN3270 printer
  28.    device can be requested by a TN3270 client and the manner in which
  29.    the 3270 printer status information can be sent to the TN3270 server.
  30.    Discussions and suggestions for improvements to these enhancements
  31.    should be sent to the TN3270E Working Group mailing list
  32.    TN3270E@list.nih.gov . These extensions will be called TN3287 in this
  33.    document.  This information is being provided to members of the
  34.    Internet community that want to support the 3287 data stream within
  35.    the TELNET protocol.
  36.  
  37. 1. INTRODUCTION
  38.  
  39.    The need to communicate with IBM mainframe systems has a number of
  40.    unique requirements associated with it.  This document addresses
  41.    those needs in a TCP/IP communications network.
  42.  
  43.    IBM terminals are generically referred to as 3270's which includes a
  44.    broad range of terminals and devices,not all of which actually begin
  45.    with the numbers 327x.
  46.  
  47.    The 3270 family of terminals and the IBM mainframe applications
  48.    systems are VERY closely coupled and it is the nature of the way the
  49.    3270s and the applications interact which require that this document
  50.    be available to provide a consistent way for the TCP/IP environment
  51.    to interact effectively with the 3270 applications of the IBM
  52.    mainframe world.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Graves, Butts & Angel                                           [Page 1]
  59.  
  60. RFC 1646                   TN3270 Extensions                   July 1994
  61.  
  62.  
  63.    IBM mainframe applications systems have existed for almost two
  64.    decades now and are used to serve tens of thousands of users daily.
  65.    For this reason it is usually the need of a mainframe environment to
  66.    add TCP/IP network support WITHOUT writing new applications to run
  67.    with the TCP network.  The TN3270 series of documents addresses how
  68.    this can be done and maintain compatibility with those mainframe
  69.    application systems.
  70.  
  71.    One of the unique characteristics of the 3270 terminals is their
  72.    ability to communicate status information in an out-of-band data
  73.    flow.  These status's are in turn used by the applications systems to
  74.    support error recovery, and conflict resolutions, examples of these
  75.    are printer out of paper, and terminal powered up.  The terminals are
  76.    also half duplex and block mode in their operations, which results in
  77.    the need to communicate when blocks are being sent, when they end,
  78.    and when they cannot be sent.  This document describes these
  79.    characteristics in IBM VTAM/SNA terms.  Some VM mainframe application
  80.    systems do not use VTAM, so for those systems these terms don't
  81.    apply.  For any systems which use VTAM these terms apply and are
  82.    dealt with in some way by the TCP/IP to VTAM interface.
  83.  
  84.    VTAM/SNA is a hierarchical network and some of that hierarchy needs
  85.    to be addressed by the TCP network attaching to it if the
  86.    applications systems are to continue to provide the same applications
  87.    support that they have provided to the 3270 terminals.
  88.  
  89.    The 3270 terminal environment consists of a terminal controller with
  90.    terminals attached to that controller.  In VTAM/SNA this controller
  91.    is called a PU (Physical Unit) and the terminals called LUs (Logical
  92.    Units).  The PU is used to communicate management information to the
  93.    VTAM/SNA system, and the LU is used by the application to communicate
  94.    with the terminal.  VTAM/SNA identifies each LU and PU in a network
  95.    by a unique name.  These names are referred to as LUnames and
  96.    PUnames, and is how the network is managed and the applications
  97.    identify what terminals are being communicated with in the network.
  98.    The actual connection between a terminal and the applications is
  99.    referred to as a session, and it is this session which has both in-
  100.    band and out-of-band information flows sent between the applications
  101.    and the terminals.
  102.  
  103.    VTAM/SNA 3270 terminals actually have two sessions when communicating
  104.    with the applications.  One session is directly connected with the
  105.    application and the other session is connected directly to VTAM.  It
  106.    is the session with VTAM, also called the SSCP, that is used to
  107.    communicate the out-of-band information flows.  This session is
  108.    called the SSCP-LU session, and the session with the application is
  109.    called the LU-LU session (in VTAM an applications is just another
  110.    Logical Unit).
  111.  
  112.  
  113.  
  114. Graves, Butts & Angel                                           [Page 2]
  115.  
  116. RFC 1646                   TN3270 Extensions                   July 1994
  117.  
  118.  
  119.    One such out-of-band flow is the LUSTAT message which tells the
  120.    application that the status of the terminal has changed, and is how a
  121.    printer or screen tells the application that it is ready, or is not
  122.    ready to receive data.
  123.  
  124.    There are also flows which must be able to flow in the LU-LU session
  125.    to help control the use of the terminal by applications.  The block
  126.    of information sent in a session is called an RU (Request Unit) and
  127.    it tells what type of data this block contains, how long it is and if
  128.    more data (RUs) is coming along.  This is a gross over simplification
  129.    of what RUs are and do, but it should help understand their use in
  130.    the TN3270 documents.  Some of the VTAM/SNA terms used to describe
  131.    what an RU is requesting are:  Chains/chaining which tell a session
  132.    partner that another RU is being sent or not being sent in this
  133.    transmission.  Brackets which are used to indicate that a unit of
  134.    work is complete, such as when a printout of a file is complete.
  135.  
  136.    The determination of what part of the VTAM/SNA protocols such as
  137.    brackets and chaining are to be used are managed by VTAM tables
  138.    called LOGMODE tables.  These tables are selected when an LU-LU
  139.    session is started and set up such things as bracket, and/or chaining
  140.    protocols; and the type of terminal data contained in the RUs, such
  141.    as printer data without screen formatting data (LU type 1), 3270
  142.    screen formatted data (LU type 2) and 3270 screen formatted data for
  143.    a printer (LU type 3).  The LOGMODE tables also contain the size of
  144.    the RU to be sent and received.  These tables also communicate the
  145.    screen size of 3270 terminals such as 24X80 (Model 2), 27X132 (Model
  146.    5), etc.  Each LU has a LOGMODE table entry hard assigned to it as
  147.    part of the VTAM configuration (often called a GEN).  The selection
  148.    of these table entries can't be controlled by the terminal LU or PU.
  149.    They can only be selected by the user at connection/logon time or by
  150.    the application when the connection is established.  The actual
  151.    LOGMODE entries to be used during a session are sent at session logon
  152.    time, in a special type of RU called a BIND.  Once the bind has been
  153.    sent then the rules for the use of the session have been set, can't
  154.    be changed, and must be followed.
  155.  
  156.    The purpose of the TN3287 protocol is to provide a general IBM 3270
  157.    host printer communications facility.  Its primary goal is to allow a
  158.    method of connecting printer devices and printer-oriented processes
  159.    to each other.  This protocol will allow a TN3270 Client to process
  160.    3287 print data streams.
  161.  
  162.    This memo supplements and extends the STD 8, RFC 854, TELNET Protocol
  163.    Specification.  This memo also presents an example of the correct
  164.    implementation.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Graves, Butts & Angel                                           [Page 3]
  171.  
  172. RFC 1646                   TN3270 Extensions                   July 1994
  173.  
  174.  
  175. 2. GENERAL CONSIDERATIONS
  176.  
  177.    A TELNET connection is a Transmission Control Protocol (TCP)
  178.    connection used to transmit data with interspersed TELNET control
  179.    information.
  180.  
  181.    The companion document, STD 8, RFC 854 -- "TELNET Protocol
  182.    Specification" should be consulted for further information about the
  183.    TELNET command, codes and code sequences referenced in this
  184.    specification.
  185.  
  186. 3. CLIENT-SERVER NEGOTIATION
  187.  
  188.    The TN3270 Client and Server require a specific negotiation protocol.
  189.    After the negotiation is complete, all transmission between the
  190.    Client and Server is in TELNET Binary format with a TELNET "End-Of-
  191.    Record(EOR)" sequence at the end of each data stream.
  192.  
  193.    Support for the TN3287 data stream requires that both sides:
  194.  
  195.       A.  Are able to exchange binary data.
  196.  
  197.       B. Can establish the agreement between client and server on the
  198.          terminal type that will be used.
  199.  
  200.       C. Agree to use the TELNET IAC EOR as a delimiter for inbound
  201.          and outbound TN3287 data streams
  202.  
  203.    This implementation requires the options: TERMINAL-TYPE and BINARY be
  204.    successfully negotiated between the Client and Server before
  205.    processing of any print data streams.
  206.  
  207.    This implementation supports host applications that can mix LU 1 and
  208.    LU 3 type data in the data stream.
  209.  
  210. 3.1  TN3287 SERVER
  211.  
  212.    The maximum Request Unit (RU) size is server specific, but should not
  213.    exceed 4 kilobytes.
  214.  
  215.    The LU type is determined by the bind from the mainframe application.
  216.    The server, when bound, must remember LU 1 or LU 3 type.
  217.  
  218.    The server will automatically unbind the session upon receipt of a
  219.    TELNET CLOSE command.  The printer will be reported to VTAM as
  220.    powered down until a new TELNET connection is established.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Graves, Butts & Angel                                           [Page 4]
  227.  
  228. RFC 1646                   TN3270 Extensions                   July 1994
  229.  
  230.  
  231. 3.2  TN3287 CLIENT
  232.  
  233.    The TN3287 Client is a TN3270 client created specifically to print
  234.    mainframe 3270 print data.  The client emulates the IBM device type
  235.    that it identifies itself to the TN3270 server as, in this case, an
  236.    IBM 3287 model 1 type printer.  The design of this printer protocol
  237.    is aligned with the way printing occurs in the IBM host and how 3270
  238.    printers function.  These printer extensions DO NOT support a 3270
  239.    printer client that cannot accept both types LU 1 and LU 3 printer
  240.    streams.  No IBM printer operates in this fashion, and as a result,
  241.    no TN3270 server could function properly with mainframe applications
  242.    if it didn't allow for a mixing of LU 1 and LU 3 data streams.  The
  243.    common way in which this can occur is printer sharing between
  244.    multiple IBM host applications, such as CICS and JES.  Since there is
  245.    no restriction, the JES can be configured to output LU 1 data
  246.    streams, and the CICS can be  configured for LU 3 data streams.
  247.    Therefore, the server will identify what LU type the current
  248.    application connected to the server is using.  If that type is LU 1,
  249.    ALL message records sent to the Client will be preceded by one byte
  250.    of binary zeros (0x00).  If the first byte is not zeros, then that
  251.    byte will be a valid LU type 3 Write-Command-Code(WCC), which can
  252.    NEVER be zeros.  Thus, the client can tell the LU type of data as
  253.    each record is received.
  254.  
  255.    This protocol does allow for the client to shutdown if the client
  256.    does not wish to support both LU types.  This is accomplished by
  257.    detecting an invalid data type from the received record, and
  258.    notifying the user that the mainframe application has sent LU type x
  259.    print data and should be configured for LU type y printing.
  260.  
  261. 4.  COMMAND STRUCTURE
  262.  
  263.       1. All TELNET commands consist of at least a two-byte sequence:
  264.          the "Interpret-as-Command(IAC)" escape character followed by
  265.          the code for the command.
  266.  
  267.    NOTE:  Since the TELNET IAC character (255 decimal) is used as a
  268.    delimiter (together with EOR) in the inbound and outbound data
  269.    streams, a data byte within the data stream itself that has the same
  270.    value as the IAC command is sent as two bytes (255, 255) and one byte
  271.    is discarded.
  272.  
  273. 4.1  TELNET COMMANDS
  274.  
  275.    Command meaning - WILL and DO commands are used to obtain and grant
  276.    permission for the subsequent subnegotiation.  Both sides must
  277.    exchange WILL TERM-TYPE and DO TERM-TYPE before subnegotiation.
  278.  
  279.  
  280.  
  281.  
  282. Graves, Butts & Angel                                           [Page 5]
  283.  
  284. RFC 1646                   TN3270 Extensions                   July 1994
  285.  
  286.  
  287.    The actual exchange of information is done within the option
  288.    subcommand.
  289.  
  290.    <IAC DO TERMINAL-TYPE>  Sender requests that the other party begin
  291.    terminal-type sub-negotiation.
  292.  
  293.    <IAC WILL TERMINAL-TYPE>  Sender is willing to send terminal-type
  294.    information in a subsequent sub-negotiation.
  295.  
  296.    <IAC SB TERMINAL-TYPE SEND IAC SE>  Sender requests the receiver to
  297.    transmit his terminal-type.
  298.  
  299.    <IAC SB TERM TYPE IS IBM-3287-1 IAC SE>   Sender is stating the name
  300.    of his terminal-type.  The code for <IS> is 0.  Optionally, a
  301.    specific Logical Unit (LU) can be requested by using the TERMINAL-
  302.    TYPE string below.   If no LUname is specified, the first available
  303.    3287 LU is selected.
  304.  
  305.       IAC SB TERM-TYPE IS IBM-3287-1 @ LUNAME IAC SE
  306.  
  307.    <IAC DO BINARY>  Sender requests that sender of the data starts
  308.    transmitting or confirms that the sender of data is expected to
  309.    transmit characters that are to be interpreted as 8 bits of binary
  310.    data by the receiver.
  311.  
  312.    <IAC WILL BINARY>   Sender requests permission to begin transmitting,
  313.    or confirms it will now begin transmitting binary data.
  314.  
  315.    An <EOR> is sent at the end of each SNA Request Unit (RU) end of
  316.    chain, in either direction.   The first byte following the <EOR> is a
  317.    Write-Command-Code(WCC) for LU 3 data streams.
  318.  
  319.    An <AO> is sent at the end of the SNA RU and end of bracket.  This
  320.    signifies the end of the print output or file by the IBM host
  321.    application and possibly a change of LU type.
  322.  
  323. 4.2   COMMAND VALUES
  324.  
  325.  
  326.                      TELNET COMMAND                     CODE
  327.                      IAC  Interpret as Command           255
  328.                      DO                                  253
  329.                      WILL                                251
  330.                      SB  SuBnegotiation option           250
  331.                      SE  Subnegotiation End              240
  332.                      TERMINAL-TYPE                        24
  333.                      SEND                                  1
  334.                      IS                                    0
  335.  
  336.  
  337.  
  338. Graves, Butts & Angel                                           [Page 6]
  339.  
  340. RFC 1646                   TN3270 Extensions                   July 1994
  341.  
  342.  
  343.                      EOR  End-Of-Record                   25
  344.                      BINARY                                0
  345.                      AO  Abort Output                    245
  346.                      IP  Interrupt Process               244
  347.                      AYT  Are You There                  246
  348.                      BREAK                               243
  349.  
  350.    NOTE:  The above codes and code sequences have the indicated meaning
  351.    only when immediately preceded by an "Interpret as Command (IAC)".
  352.  
  353. 5.  TN3270 Printer Status Message
  354.  
  355.    The status message can be sent at any time.  It must be sent every
  356.    time the TN3270 Server sends an End-of-Record(EOR) indicator to the
  357.    TN3270 Client, or when a printing error occurs at the Client.  The
  358.    Printer Status Message is only sent by the TN3270 Client. Once the
  359.    End-Of-Record IAC is processed, the TN3270 Client sends the status
  360.    message to the server when it is ready to receive more print data.
  361.  
  362.       MESSAGE DESCRIPTION:      SOH  %  R  S1  S2  IAC  EOR
  363.  
  364.  
  365.                                SOH = 0X01
  366.                                % = 0X6C
  367.                                R = 0XD9
  368.                                S1 = Status/Sense Byte 0
  369.                                S2 = Status/Sense Byte 1
  370.                                IAC = Telnet IAC Character
  371.                                EOR = Telnet EOR Character
  372.  
  373. 5.1   Status/Sense Byte description
  374.  
  375. 5.1.1.  S/S Byte 0:
  376.  
  377.         High Order                                          Low Order
  378.  
  379.  
  380.         _____________________________________________________________
  381.         |                                                           |
  382.         |   0      1      2      3      4      5      6      7      |
  383.         |___________________________________________________________|
  384.  
  385.  
  386.           Bit Number:       Bit Definition:
  387.  
  388.                 0           Always Zero
  389.  
  390.                 1           Always Zero
  391.  
  392.  
  393.  
  394. Graves, Butts & Angel                                           [Page 7]
  395.  
  396. RFC 1646                   TN3270 Extensions                   July 1994
  397.  
  398.  
  399.                 2           Always Zero
  400.  
  401.                 3           Always Zero
  402.  
  403.                 4           Always Zero
  404.  
  405.                 5           Unit Specify - is set due to an error
  406.                             condition.  The reason for the error
  407.                             condition will be indicated in S/S Byte 1.
  408.                             See Note 1*.
  409.  
  410.                 6           Device End - when this bit sent in response
  411.                             to a data message it indicates the client
  412.                             has successfully processed the data message
  413.                             from the server and notifies the server to
  414.                             send a new data message to the client when
  415.                             available.   See Note 2*.
  416.  
  417.                 7           Always Zero
  418.  
  419.  
  420.    Note 1*:   A negative response to the Server's data message would be
  421.    S/S Byte 0 Bit 5 "Unit Specify condition".  The possible Unit Specify
  422.    conditions are listed below.  (See Section 3.2 for bit settings for
  423.    the Unit Specify conditions listed below.)
  424.  
  425.                 Unit Specify Condition:    SNA Sense Code sent to host:
  426.  
  427.                 Command Rejected                     0X10030000
  428.                 Intervention Required                0X08020000
  429.                 Data Check                           0X10010000
  430.                 Operation Check                      0X10050000
  431.                 Component Disconnected (LU)          0X08020000
  432.  
  433.    Note 2*:   Device End -  A positive response to the Server's data
  434.    message would be the "Device End" bit (S/S Byte 0 Bit 6) to indicate
  435.    a ready to receive data from the host condition.  This will also be
  436.    sent after clearing a previous Unit Specify condition of
  437.    "Intervention Required".
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Graves, Butts & Angel                                           [Page 8]
  451.  
  452. RFC 1646                   TN3270 Extensions                   July 1994
  453.  
  454.  
  455. 5.1.2.  S/S Byte 1:
  456.  
  457.          High Order                                           Low Order
  458.  
  459.        ______________________________________________________________
  460.        |                                                            |
  461.        |    0      1      2      3      4      5      6      7      |
  462.        |____________________________________________________________|
  463.  
  464.  
  465.           Bit Number:       Bit Definition:
  466.  
  467.  
  468.                0            Always Zero
  469.  
  470.                1            Always Zero
  471.  
  472.                2            Command Rejected (CR) -- This bit
  473.                             indicates an invalid 3270 command
  474.                             generated.
  475.  
  476.                3            Intervention Required - Printer Not Ready.
  477.                             See Note 3*.
  478.  
  479.                4            Component Disconnected - Printer is powered
  480.                             off or printer cable not connected.  See
  481.                             Note 4*.
  482.  
  483.                5            Data Check - Invalid print data
  484.  
  485.                6            Always Zero
  486.  
  487.                7            Operation Check - An illegal buffer address
  488.                             or incomplete order sequence
  489.  
  490.    Note 3*:  The Intervention Required is cleared by sending an S/S
  491.    message with the "Device End" bit (Bit 6 of S/S byte  0).  The LUSTAT
  492.    sent to the host is 0X00010000.  The IBM host interprets this as a
  493.    "printer now ready" condition.
  494.  
  495.    Note 4*:  The Component disconnected is cleared by sending an S/S
  496.    message with the "Device End" bit  (Bit 6 of S/S byte 0).  The LUSTAT
  497.    sent to the host is 0X082B0000.  The IBM host interprets this as a
  498.    "printer now ready -- presentation space integrity may be lost"
  499.    condition.
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Graves, Butts & Angel                                           [Page 9]
  507.  
  508. RFC 1646                   TN3270 Extensions                   July 1994
  509.  
  510.  
  511. 6.  The following is an example of the Client-Server negotiation
  512.     process.
  513.  
  514.       Server:   IAC DO TERMINAL-TYPE
  515.       Client:        IAC WILL TERMINAL-TYPE
  516.       Server:   IAC SB TERMINAL-TYPE SEND IAC SE
  517.       Client:        IAC SB TERMINAL-TYPE IS IBM-3287-1 IAC SE
  518.  
  519.       Note: To request a specific LU the TERMINAL-TYPE string would be:
  520.       IAC SB TERMINAL-TYPE IS IBM-3287-1 @ LUNAME IAC SE
  521.       (The client has specified its terminal type is an IBM-3287-1)
  522.  
  523.  
  524.       Server:   IAC DO END-OF-RECORD
  525.       Client:        IAC WILL END-OF-RECORD
  526.       Server:   IAC WILL END-OF-RECORD
  527.       Client:        IAC DO END-OF-RECORD
  528.  
  529.       (The Server and Client have both agreed to transmit End-Of-Record
  530.       (EOR)).
  531.  
  532.  
  533.       Server:   IAC DO TRANSMIT-BINARY
  534.       Client:        IAC WILL TRANSMIT-BINARY
  535.       Server:   IAC WILL TRANSMIT-BINARY
  536.       Client:        IAC DO TRANSMIT-BINARY
  537.       (The Server and Client have both agreed to use binary
  538.       transmission)
  539.  
  540.  
  541.       Server:   0x00 (3270 PRINT DATA)
  542.       Client:        (S/S with DEV END) IAC EOR
  543.       Server:   0x00 (3270 PRINT DATA) IAC EOR
  544.  
  545.       NOTE:  LU 1 type data is prefaced with a 0x00 character. LU 3
  546.       type data is not prefaced with a special character.  This
  547.       character will precede print data in each chain, and should be
  548.       discarded before the print data is processed.   An <IAC EOR> must
  549.       be received before changing to LU 1 or LU 3 type data.
  550.  
  551.       Client:        (S/S with IR) IAC EOR (This indicates a paper jam
  552.                     at printer.)
  553.       Client:        (S/S with DE) IAC EOR (This indicates the clearing
  554.                     of above condition.)
  555.       Server:  0x00 (3270 PRINT DATA) (This indicates start of LU 1
  556.                data)
  557.  
  558.       Server:   (3270 PRINT DATA)
  559.  
  560.  
  561.  
  562. Graves, Butts & Angel                                          [Page 10]
  563.  
  564. RFC 1646                   TN3270 Extensions                   July 1994
  565.  
  566.  
  567.       Server:   (3270 PRINT DATA)
  568.       Server:   (3270 PRINT DATA) IAC EOR
  569.       Client:        (S/S with DE) IAC EOR
  570.       Server:   0x00 (LAST 3270 PRINT DATA) IAC EOR
  571.  
  572.  
  573.       Client:        (S/S with DE) IAC EOR
  574.       Server:   IAC AO
  575.       (The Abort Output <AO> signifies the end-of-bracket -- end of
  576.       print job)
  577.  
  578. 7.  SECURITY CONSIDERATIONS
  579.  
  580.    This document does not specify a security methodology to insure that
  581.    the client requesting a printer LU name is authorized to access that
  582.    LU.  Currently, this is left up to individual server implementations.
  583.    The design of the protocols described in this document allow for the
  584.    future incorporation of the RFCs regarding encryptions and
  585.    authentication protocols and services.  However, before this may
  586.    occur, certain extensions may be required to the protocols defined in
  587.    this document or to the encryptions and authentication services and
  588.    protocols.
  589.  
  590. 8. ERROR CONDITIONS
  591.  
  592.    After a client and server have successfully completed negotiation, a
  593.    number of potential error conditions may be detected by the server
  594.    which require notifying the client and aborting the connection.
  595.  
  596.    When an error condition is detected by the server, the client must be
  597.    negotiated back into NVT mode by the server sending a "WONT/DONT
  598.    BINARY" TELNET sequence and the client responding with the
  599.    appropriate "DONT/WONT BINARY" TELNET sequence.
  600.  
  601.    The server should immediately send the appropriate error message to
  602.    the client as an ASCII string and then close the connection. The
  603.    error message should be prefixed by a numeric identifier to precisely
  604.    notify the client of the specific error condition. The error message
  605.    sent to the client should be routed to the proper console or log for
  606.    corrective action.
  607.  
  608.    Below is a list of error conditions identified by numeric value,
  609.    error text, meaning of the error and recovery procedure.
  610.  
  611.       Message: "01 No LU's of the type configured"
  612.  
  613.          Meaning: The configuration definition on the server
  614.                   does not include the LU type requested.
  615.  
  616.  
  617.  
  618. Graves, Butts & Angel                                          [Page 11]
  619.  
  620. RFC 1646                   TN3270 Extensions                   July 1994
  621.  
  622.  
  623.          Recovery: Notify your Systems Administrator as this
  624.                    is a permanent error condition.
  625.  
  626.       Message: "02 Requested LU unavailable"
  627.  
  628.          Meaning: The requested LU is not available at
  629.                   this time.
  630.  
  631.          Recovery: This may be a temporary error and may
  632.                    be retried periodically.  If the condition
  633.                    persists contact your Systems Administrator.
  634.  
  635.       Message: "03 Requested LU type is inconsistent with configuration"
  636.  
  637.          Meaning: The LU requested does not match the terminal
  638.                   type in the server configuration.
  639.  
  640.          Recovery: Notify your Systems Administrator as this
  641.                    is a permanent error condition.
  642.  
  643.       Message: "04 Requested LU is not configured"
  644.  
  645.          Meaning: The LU is not defined in server configuration.
  646.  
  647.          Recovery: Notify your Systems Administrator as this
  648.                    is a permanent error condition.
  649.  
  650.    When a client receives a message not defined in the above list, the
  651.    message should be displayed to a console or log and the connection to
  652.    the server should be closed.  No other recovery should be attempted
  653.    as this is most likely a fatal error condition.  (Notify your Systems
  654.    Administrator.)
  655.  
  656. 9. REFERENCES
  657.  
  658.    [1] Postel, J., and J. Reynolds, "TELNET Protocol Specification", STD
  659.        8, RFC 854, USC/Information Services Institute, May 1983.
  660.  
  661.    [2] VanBokkeln, J., "TELNET Terminal-Type Option" RFC 1091, FTP
  662.        Software Inc., February 1989.
  663.  
  664.    [3] Postel, J., and J. Reynolds, "TELNET Binary Transmission", STD
  665.        27, RFC 856, USC/Information Services Institute, May 1983.
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Graves, Butts & Angel                                          [Page 12]
  675.  
  676. RFC 1646                   TN3270 Extensions                   July 1994
  677.  
  678.  
  679. Authors' Addresses
  680.  
  681.        Cleve Graves
  682.        2711 LBJ Freeway
  683.        Dallas, Texas  75234
  684.  
  685.        Phone: (214) 484-5200
  686.        EMail: cvg@oc.com
  687.  
  688.  
  689.        Thomas Butts
  690.        2711 LBJ Freeway
  691.        Dallas, Texas  75234
  692.  
  693.        Phone: (214) 484-5200
  694.        EMail: tom@oc.com
  695.  
  696.  
  697.        Michelle Angel
  698.        2711 LBJ Freeway
  699.        Dallas, Texas  75234
  700.  
  701.        Phone: (214) 484-5200
  702.        EMail: angel@oc.com
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Graves, Butts & Angel                                          [Page 13]
  731.  
  732.