Copyright Xerox Corporation 1979Inter-Office MemorandumToCommunication ProtocolsDateJuly 2, 1978FromEd TaftLocationPalo AltoSubjectPup Telnet ProtocolOrganizationPARC/CSLXEROX Filed on: [Maxc1]Telnet.pressThis is a revision of a memo of the same title dated November 11, 1975. Only minor changes havebeen made.Telnet is a protocol designed for terminal communication--either process-to-terminal or terminal-to-terminal. It is based entirely on the Pup Byte Stream Protocol (BSP), described elsewhere.Telnet is intended for providing a sequential communication path between (usually) a user terminaland a server process in a manner similar to that provided by conventional computer terminals. It isspecifically not intended for more elaborate forms of communication such as display editing orinteractive graphics. Such applications are better (more efficiently) implemented by means ofappropriate special protocols.The conventions we have adopted are based on the Arpanet Telnet protocol for control of terminalconnections, omitting most of its provisions (particularly the more complicated ones) for which thereis no forseeable need within the PARC environment.All Telnet control commands consist of a BSP Mark byte (of which there are 256 possible types)followed by zero or more arguments given in data bytes immediately following the Mark.All bytes that are not part of such a control sequence are treated as ordinary data bytes. Typically,Telnet data will consist only of ASCII characters in the range 0-177 (octal), but we leave the dooropen to the possibility of 8-bit binary terminal I/O for such purposes as extended character sets.The control functions defined at present are the following:Data MarkA Data Mark (DM, Mark type 1), in conjunction with the BSP Interrupt signal, is used to performthe "Synch" operation. A Telnet sender (user or server) desiring to generate a "Synch" signal insertsa DM in the byte stream and simultaneously transmits an Interrupt. The Interrupt, not beingsubject to BSP flow control, reaches the receiver even if the byte stream is otherwise clogged up dueto allocation or buffering considerations. Upon receipt of the Interrupt, the receiver immediatelydiscards already processed data as appropriate (e.g. clearing terminal buffers), and then reads thebyte stream until the DM is encountered. While doing so, the receiver discards all data exceptTelnet control commands and any other "interesting" signals it may choose to act upon.In Telnet terminal communication, the "Synch" signal is used for two similar purposes. First, itmay be generated by the Telnet server when it is called upon to "clear the terminal output buffer". &pX]g~qi cr]pX-r7Bp \r]p-r7Bp Vr]p-r 7BpOsp I" C=# BD ?_[ =F :@" 9p+9 7[ 6f(6 4 18( 0wC" .2 , J *V 'E! &4/ $K !; 't BpW e 8R (= .;( F $ Nu pV a 5Z ?/d Pup Telnet Protocol2For example, the Tenex CFOBF JSYS, when executed for a network terminal, generates a "Synch"and thereby causes the user's terminal output buffer to be cleared and all data already in the bytestream to be flushed. Second, it may be generated by the Telnet user upon discovering a "terminalinput buffer full" condition that is even preventing panic signals (e.g., control-C) from reaching theserver because the byte stream is blocked due to lack of allocation.Terminal ParametersBy means of Terminal Parameter commands, a Telnet user may inform the server of terminalcharacteristics such as Line Width (Mark type 2), Page Length (Mark type 3), and Terminal Type(Mark type 4). Each of these is followed by an argument byte specifying the value of the parameteras an 8-bit binary number. For Line Width and Page Length, this value is simply the maximumnumber of characters per line and lines per page, with the value zero defined to mean "unknown"or "inapplicable" (e.g., due to variable width characters). For Terminal Type, the argument is aTenex terminal type number, which at present may be any one of the following:0Model 33 TTY (no Tab, Formfeed, or lower case).1Model 35 TTY (Tab and Formfeed, no lower case).2Model 37 TTY (Tab, Formfeed, lower case).3TI (lower case, funny padding, no Tab or Formfeed).7NVT (no Tab or Formfeed, lower case, no padding whatsoever).8LA30, GE Terminet-300 (special padding).9TI-733 (slower CR than normal TI).10Scope (pause at end of page).It is conceded that this aspect of our Telnet protocol is rather strongly oriented toward Tenex conventions. The ArpanetTelnet experience has demonstrated that it is impractical to attempt to do Telnet terminal handling in a "completelygeneral" fashion. We propose simply putting off designing a more general-purpose terminal type specification protocoluntil such time as we require the added generality. At the present time, we use the Telnet protocol only forcommunicating with Tenex and Tenex-like servers.Timing MarkAt any time, either the user or the server may place a Timing Mark (Mark type 5) in the outgoingbyte stream. The receiver of the Timing Mark is expected to respond with a Timing Mark Reply(Mark type 6) when all data preceding the Timing Mark has been "completely processed". By"completely processed", we mean that the data has been in some sense accepted and logically actedupon by the user or server program (as opposed, say, to simply being placed in terminal buffers).Hence, a server Telnet should send the Timing Mark Reply only when the server process accepts (oris prepared to accept) data following the incoming Timing Mark (i.e., is "blocked on input").Similarly, a user Telnet should send the Reply only when all data prior to the incoming TimingMark has actually been printed or displayed on the user's terminal.The intent of this mechanism is to permit a process to synchronize or correlate the incoming andoutgoing data. When the initiator of the Timing Mark encounters the Timing Mark reply, it knowsthat all data following the Reply was generated (by the other process) after the time at which theoriginal Timing Mark was sent.Typical uses of the Timing Mark mechanism may be illustrated as follows. An Alto user Telnetmakes a connection to Maxc, transmits a prepared typescript terminated by the command "Logout"and a Timing Mark, then waits for the Timing Mark Reply before terminating the connection.Without the Timing Mark mechanism, it is difficult for the user Telnet to determine the correct fpG bR `O _20 ]T \ D W}t TpL SH Q.4 P \ N@ LI KzMH/E/B)?3=<:(77"4R 1rZ 0SQ# /<: -!L ,0 (3t %NpI # P "D P 6+ :G F 0T 8& &C AD ` 7 :up  V H'7 Z >(7 ?/^BPup Telnet Protocol3moment at which to close the connection, since in general there is some buffering at the server end.If the connection is closed too early, the server process may get "detached" before having read allthe input.The Timing Mark mechanism may also be put to use by the server Telnet in the following way. Aprogram that detects some logical error will typically execute a "clear input buffer" operation(CFIBF in Tenex) to clear characters that might have been typed ahead by the user before the erroroccurred. But when the terminal is at the other end of a network connection, the server Telnet hasno way of ascertaining the point in the incoming byte stream corresponding (chronologically) withthe time the error occurred. The Timing Mark facility may be used to solve this problem. Whenthe program executes a "clear input buffer" (presumably after generating some sort of errormessage), the server Telnet should drop a Timing Mark in the outgoing byte stream (appended tothe error message), then discard data bytes from the incoming stream until the Timing Mark Replyis encountered.Telnet Operations Not SpecifiedThe Arpanet Telnet protocol includes a large number of operations that have not been adopted inthe Pup Telnet protocol. These include the following:1.Network standard representations for common operations, such as EL (Erase Line), IP(Interrupt Process), etc. The justification for this is that within the PARC environment, wedo not mind adopting the conventions of whatever server host we happen to be connectedto. If users turn out to be unhappy about this, these functions are easy to add.2.Negotiation about server or user echoing. Since we don't have any half-duplex terminalsand always operate over short distances, it seems reasonable to adopt server echoing as thePARC standard.3.The negotiation mechanism itself. The Arpanet Telnet "option negotiation" protocol is quitecomplicated, and experience has shown it to be very difficult to implement correctly. Whenwe find something to negotiate about, we should perhaps try to design something simpler.4.More elaborate interactions such as the Telnet Reconnection protocol and the Remote-Controlled Transmission and Echoing protocol (again, due to lack of any forseeable need forthese mechanisms). fpG b13 `O _ \/3+ Z!> Y%L WP V5, TB S7$ Q)5 P=# N It GpA E6 BBA!]?<>Q ;20(9[8( 5C\3?29D /T#1-8#,J ,?/< TIMESROMAN  TIMESROMAN  TIMESROMANLOGO TIMESROMAN  TIMESROMAN  j/x telnet.bravoTaftSeptember 3, 1979 5:46 PM