TN3287 Printer Specification MEMO STATUS Expiration date 12/31/92 This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. INTRODUCTION This RFC suggests a draft standard for the Internet community, and requests discussion and suggestions for improvements to this draft standard for TN3287 protocol. Distribution of this memo is unlimited. The purpose of the TN3287 protocol is to provide a general, bi-directional printer communications facility. It's primary goal is to allow a standard method of interfacing printer devices and printer-oriented processes to each other. This protocol will allow a TN3270 Client to process 3287 print data streams. This RFC supplements and extends the RFC 854, TELNET Protocol Specification. This RFC also presents an example of the correct implementation. GENERAL CONSIDERATIONS A TELNET connection is a Transmission Control Protocol (TCP) connection used to transmit data with interspersed TELNET control information. The companion document, RFC 854- "TELNET Protocol Specification" should be consulted for further information about the TELNET command, codes and code sequences referenced in this specification. CLIENT-SERVER NEGOTIATION The TN3270 Client and Server require a specific negotiation protocol. After the negotiation is complete, all transmission between the Client and Server is in TELNET Binary format with a TELNET "End of Record (EOR)" sequence at the end of each data stream. Support for the TN3287 data stream requires that both sides: -- are able to exchange binary data, -- can establish the agreement between client and server on the terminal type that will be used, -- both sides agree to use the TELNET IAC EOR as a delimeter for inbound/outbound TN3287 data streams. This implementation requires the options: TERMINAL-TYPE and BINARY be successfully negotiated between the Client and Server prior to processing of any print data streams. COMMAND STRUCTURE 1. All TELNET commands consist of at least a two-byte sequence: the "Interpret as Command (IAC)" escape character followed by the code for the command. NOTE: Since the TELNET IAC character (255 decimal) isused as a delimiter (together with EOR) in the inbound/outbound data streams, a data byte within the data stream itself that has the same value as the IAC command is sent as two bytes (255, 255) and one byte is discarded. 2. TELNET Commands Command meaning- WILL and DO commands are used to obtain and grant permission for the subsequent subnegotiation. Both sides must exchange WILL TERM-TYPE and DO TERM-TYPE prior to subnegotiation. The actual exchange of information is done within the option subcommand. IAC DO TERMINAL-TYPE- The sender of this command requests that the other party begin term-type sub-negotiation. IAC WILL TERMINAL-TYPE- Sender is willing to send terminal type information in a subsequent sub-negotiation. IAC SB TERMINAL-TYPE SEND IAC SE- Sender requests the receiver to transmit his terminal type. IAC SB TERM TYPE IS IBM-3287-1 IAC SE- Sender is stating the name of his term-type. The code for "IS" is 0. A specific Logical Unit (LU) can be requested by using the TERM-TYPE string: IAC SB TERM-TYPE IS IBM-3287-1 @ LUNAME IAC SE. IAC DO BINARY- Sender of this command requests that sender of the data start transmitting or confirms that the sender of data is expected to transmit characters which are to be interpreted as 8 bits of binary data by the receiver. IAC WILL BINARY- Sender requests permission to begin transmitting , or confirms it will now begin transmitting binary data. Command Values- TELNET Command Code IAC- Interpret as Character 255 DO 253 WILL 251 SB- Option subnegotiation 250 SE- End subnegotiation 240 TERM-TYPE 24 SEND 1 IS 0 EOR- End of Record 25 BINARY 0 AO- Abort Output 245 NOTE: The above codes and code sequences have the indicated meaning only when immediately preceded by an "Interpret as Command (IAC)". 3. TN3270 Printer Status Message- The status message is sent every time the TN3270 Server sends a data message to the TN3270 Client. This message is only sent by the TN3270 Client. Once the data message is processed, the TN3270 Client sends the status message to the server. Message description: SOH%RS1S2IACEOR SOH= 0X01 %=0X6C R=0XD9 S1=Status/Sense Byte 0 S2=Status/Sense Byte 1 IAC=Telnet IAC Character EOR=Telnet EOR Character 3.1 Status/Sense Byte description S/S Byte 0: High Order Low Order +-------------------------------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +-------------------------------+ Bit Number: Bit Definition: 0 Always Zero 1 Always Zero 2 Always Zero 3 Always Zero 4 Always Zero 5 Unit Specify- is set due to an error condition. The reason for the error condition will be indicated in S/S Byte 1. See Note 1*. 6 Device End- when this bit sent in response to a data message it indicates the client has successfully processed the data message from the server and notifies the server to send a new data message to the client when available. See Note 2*. 7 Always Zero Note 1*: A negative response to the Server's data message would be S/S Byte 0 Bit 5 "Unit Specify condition". The possible Unit Specify conditions are listed below. (See Section 3.2 for bit settings for the Unit Specify conditions listed below) Unit Specify Condition: SNA Sense Code Sent to host: Command Rejected 0X10030000 Intervention Required 0X08020000 Data Check 0X10010000 Operation Check 0X10050000 Note 2*: Device End- A positive response to the Server's data message would be S/S Byte 0 Bit 6 "Device End" to indicate a ready to receive data from the host condition. This will also be sent after clearing a previous Unit Specify condition of "Intervention Required". 3.2. S/S Byte 1: High Order Low Order +-------------------------------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +-------------------------------+ Bit Number: Bit Definition: 0 Always Zero 1 Always Zero 2 Command Rejected (CR)- This bit indicates an invalid 3270 command generated. 3 Intervention Required- Printer Not Ready. See Note 3*. 4 Always Zero 5 Data Check- Invalid print data. 6 Always Zero 7 Operation Check- An illegal buffer address or incomplete order sequence. Note 3*: The Intervention Required is cleared by sending a S/S message with the "Device End" bit (Bit 6 of S/S byte 0). The LUSTAT sent to the host is 0X00010000. The IBM host interprets this as a "printer now ready" condition. The following is an example of the Client-Server negotiation-- TN3270 SERVER: TN3270 CLIENT: IAC DO TERM-TYPE IAC WILL TERM-TYPE IAC SB TERM-TYPE SEND IAC SE IAC SB TERM-TYPE IS IBM-3287-1 IAC SE Note: To request a specific LU the TERM-TYPE string would be: IAC SB TERM-TYPE IS IBM3287-1 @ LUNAME IAC SE TN3270 SERVER: TN3270 CLIENT: IAC DO EOR IAC WILL EOR IAC WILL EOR IAC DO EOR IAC DO BINARY IAC WILL BINARY IAC WILL BINARY IAC DO BINARY IAC DO BINARY IAC WILL BINARY 0x00 (3270 PRINT DATA) Note: LU type 1 data is prefixed with a 0x00 character. This character will precede print data in each chain, and should be discarded before the print data is processed. (S/S with DEV END) IAC EOR 0x00 (3270 PRINT DATA) IAC EOR (S/S with IR) IAC EOR Note: This indicates a paper jam at printer. (S/S with DE) IAC EOR Note: This indicates the clearing of above condition. 0x00 (3270 PRINT DATA) (3270 PRINT DATA) (3270 PRINT DATA) (3270 PRINT DATA) IAC EOR (S/S with DE) IAC EOR 0x00 (LAST 3270 PRINT DATA) IAC EOR IAC AO (S/S with DE) IAC EOR 4. References [1] RFC-854, TELNET Protocol specification. [2] RFC-1041 TELNET 3270 Regime Option. [3] RFC-884 TELNET Terminal Type Option [4] RFC-856 TELNET Binary Transmission Document expiration date 12/31/92 Author's Address: Michelle Angel & Cleve Graves OpenConnect Systems 2033 Chennault Drive Carrollton, Texas 75006 Phone: (214) 490-4090 Email: angel@hp835.oc.com cvg@oc.com