    Network Working Group                                          J. Altman
    Request for Comments: 2840                                    F. da Cruz
    Category: Informational                              Columbia University
                                                                    May 2000

                              TELNET KERMIT OPTION

    Status of this Memo

       This memo provides information for the Internet community.  It does
       not specify an Internet standard of any kind.  Distribution of this
       memo is unlimited.

    Copyright Notice

       Copyright (C) The Internet Society (2000).  All Rights Reserved.

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in RFC 2119.

    ABSTRACT

       This document describes an extension to the Telnet protocol to allow
       the negotiation, coordination, and use of the Kermit file transfer
       and management protocol over an existing Telnet protocol connection.

    CONTENTS

       1. MOTIVATION . . . . . . . . . . . . . . . . . . . . . . . .  2
       2. DEFINITIONS. . . . . . . . . . . . . . . . . . . . . . . .  2
       3. COMMANDS AND CODES . . . . . . . . . . . . . . . . . . . .  3
       4. COMMAND MEANINGS . . . . . . . . . . . . . . . . . . . . .  3
       5. KERMIT PROTOCOL IMPLICATIONS . . . . . . . . . . . . . . .  5
       6. EXAMPLES . . . . . . . . . . . . . . . . . . . . . . . . .  6
       6.1. EXAMPLE 1. . . . . . . . . . . . . . . . . . . . . . . .  6
       6.2. EXAMPLE 2. . . . . . . . . . . . . . . . . . . . . . . .  7
       6.3. EXAMPLE 3. . . . . . . . . . . . . . . . . . . . . . . .  8
       6.4. EXAMPLE 4. . . . . . . . . . . . . . . . . . . . . . . .  9
       6.5. EXAMPLE 5. . . . . . . . . . . . . . . . . . . . . . . . 10
       7. SECURITY CONSIDERATIONS. . . . . . . . . . . . . . . . . . 11
       8. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . 11
       9. AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . 11
       10. FULL COPYRIGHT STATEMENT. . . . . . . . . . . . . . . . . 12

    Altman & da Cruz             Informational                      [Page 1]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

    1. MOTIVATION

       The Kermit protocol [KER] performs error-corrected file transfer and
       management over many types of connections, including terminal
       connections, among diverse hardware and software platforms.  It is
       supported by a large number of Telnet clients and is also widely
       available on the Internet hosts to which Telnet connections are made.

       Traditionally, the Kermit protocol connection is started manually by
       a user, or perhaps by an automated script.  It is the user's
       responsibility to start the Kermit server on one end of the
       connection and the Kermit client on the other, or to start a Kermit
       "send" operation on one end and a Kermit "receive" on the other.

       This procedure grew out of necessity on ordinary direct-dial
       connections, and serves its purpose within the limitations of that
       context.  But it introduces timing and dexterity problems, and lacks
       an effective way for each Kermit program to determine the "mode" of
       the other, or even its very presence, and therefore to know with
       certainty which operations and procedures are legal on the connection
       at any given time.

       When Kermit services are offered on the Internet, however, a strong
       coupling can be established between the two end applications by
       having the Telnet protocol [TEL] serve as a supervisor for Kermit
       sessions, ensuring that a valid and known relationship is always
       obtained.  Kermit sessions are, in effect, embedded within Telnet
       sessions, with Telnet providing the mechanism for starting and
       stopping them and defining which end is the Kermit client and which
       is the Kermit server, possibly changing the relationship in response
       to user actions.

    2. DEFINITIONS

       Kermit server
          A software program that is ready to accept and act upon commands
          in the form of well-defined Kermit packets [KER].

       Kermit client
          A software program that receives requests through its user
          interface from a human agent (or a script or other source) and
          translates them to command packets, which it sends to a Kermit
          server, thus initiating a Kermit protocol transaction such as the
          transfer of one or more files.

    Altman & da Cruz             Informational                      [Page 2]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

       Availability of Kermit server
          For the purposes of this document, a Kermit server is said to be
          available if, through the negotiations described herein, its
          Telnet partner knows that it is a Kermit server.

    3. COMMANDS AND CODES

       Support for a Kermit server is negotiated separately in each
       direction, allowing Kermit service to be embedded in the Telnet
       client, the Telnet server, or in both.  The proposed Telnet
       extensions are, therefore, symmetrical.

       When the connection is first opened, Kermit service is unavailable in
       both directions.

       The availability of Kermit service is negotiated using the following
       Telnet option:

         KERMIT           47 (assigned by IANA)

       The state of the connection is controlled by the following Telnet
       subnegotiation function codes:

         START-SERVER      0
         STOP-SERVER       1
         REQ-START-SERVER  2
         REQ-STOP-SERVER   3
         SOP               4
         RESP-START-SERVER 8
         RESP-STOP-SERVER  9

    4. COMMAND MEANINGS

       The KERMIT OPTION is negotiated using the standard Telnet mechanisms:

       IAC WILL KERMIT
          The sender of this command incorporates a Kermit server and is
          willing to negotiate its use.

       IAC WONT KERMIT
          The sender of this command does not incorporate a Kermit server or
          refuses to negotiate its use.

       IAC DO KERMIT
          The sender of this command requests that the receiver negotiate
          use of a Kermit server.

    Altman & da Cruz             Informational                      [Page 3]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

       IAC DONT KERMIT
          The sender of this command refuses to negotiate the use of a
          Kermit server.

       Once WILL KERMIT is negotiated in a particular direction,
       subnegotiations are used to indicate or request a change in state of
       the connection, or to convey other information.  Subnegotiations may
       be sent at any time.

       IAC SB KERMIT START-SERVER
          This command is sent by the WILL side to indicate that the Kermit
          server is now active; that is, that client-initiated Kermit
          packets will be accepted.

       IAC SB KERMIT STOP-SERVER
          This command is sent by the WILL side to indicate that the Kermit
          server is no longer active, and therefore that it is not ready to
          accept Kermit packets.

       IAC SB KERMIT REQ-START-SERVER
          This command is sent by the DO side to request that the Kermit
          server be started.  It must be responded to with either RESP-
          START-SERVER or RESP-STOP-SERVER depending upon whether the
          request was accepted.

       IAC SB KERMIT REQ-STOP-SERVER
          This command is sent by the DO side to request that the Kermit
          server be stopped.  It must be responded to with either RESP-
          START-SERVER or RESP-STOP-SERVER depending upon whether the
          request was accepted.

       IAC SB KERMIT RESP-START-SERVER
          This command is sent by the WILL side in response to REQ-START-
          SERVER or REQ-STOP-SERVER to indicate that the Kermit server is
          active after the request was accepted or denied.

       IAC SB KERMIT RESP-STOP-SERVER
          This command is sent by the WILL side in response to REQ-START-
          SERVER or REQ-STOP-SERVER to indicate that the Kermit server is
          not active after the request was accepted or denied.

       IAC SB KERMIT SOP <octet>
          Kermit Start Of Packet.  The sender of this command specifies the
          octet it will use to mark the beginning of the Kermit packets it
          sends.  This command must be sent by each connection partner upon
          the first WILL/DO pair to allow unambiguous identification of
          Kermit packets in the data stream.  This subnegotiation must be
          sent whenever the Start of Packet character changes.  The values

    Altman & da Cruz             Informational                      [Page 4]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

          are restricted to ASCII C0 control characters other than Carriage
          Return and NUL.  The normal value is 1 (ASCII SOH).  The two
          Kermit partners normally use the same SOP, but may use distinct
          ones if desired.

       IAC SB KERMIT SOP is necessary to allow each Telnet partner to
       recognize subsequent incoming Kermit packets.  Data following the SOP
       is processed by the Kermit packet analyzer.  All other Kermit
       protocol parameters are automatically negotiated within the Kermit
       protocol upon the initial exchange of Kermit packets [KER].

       START-SERVER and STOP-SERVER commands must be sent by the WILL side
       whenever the state of the Kermit server changes.  When WILL is
       successfully negotiated the state of the WILL side is assumed to be
       STOP-SERVER.  If the server is active, the WILL side must send a
       START-SERVER to indicate the change in state.

       The receiver of a REQ-START-SERVER or REQ-STOP-SERVER is not required
       to agree to the request to change state.  The receiver must respond
       with either RESP-START-SERVER or RESP-STOP-SERVER to indicate the
       state of the Kermit Server subsequent to the request.  RESP-xxx-
       SERVER is sent instead of xxx-SERVER to enable the sender of REQ-
       xxx-SERVER to distinguish between the WILL side's spontaneous change
       in state and the response to the DO side's request.

       If the Kermit server receives a Kermit packet commanding it to cease
       Kermit service (such as a FINISH, REMOTE EXIT or BYE packet [KER]),
       it must send IAC SB KERMIT STOP-SERVER if the command is accepted.

       These rules ensure that the Telnet client's user interface always
       knows whether (and on which end) a Kermit server is available, and
       can therefore present the user only with valid choices, and that
       changes in state of one Telnet partner automatically switch the other
       to a complementary and valid state.

       While it is possible for a traditional telnet service (port 23) to
       implement this option while at the same time supporting the existing
       remote shell access functionality, it is not expected that this
       option will be used in that manner.  Instead, this option is
       primarily meant for use with dedicated Kermit services such as the
       Internet Kermit Service (port 1649) [IKS].

    5. KERMIT PROTOCOL IMPLICATIONS

       The Kermit protocol is described elsewhere [KER].  It is an
       extensible and self-configuring protocol, like Telnet, and thus any
       two proper Kermit implementations should interoperate automatically.

    Altman & da Cruz             Informational                      [Page 5]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

       In Kermit, as in Telnet, one particular octet is distinguished.  In
       Telnet's case, it is IAC (decimal 255); in Kermit's it is the
       character specified by the IAC SB KERMIT SOP negotiation, normally
       SOH (decimal 1, Ctrl-A).  All Kermit packets must begin with the SOP
       and should not contain the SOP character in an unquoted form.

       Telnet protocol takes precedence over Kermit protocol; whenever an
       IAC is detected, it is processed as the beginning of a Telnet command
       unless quoted by another IAC.  Telnet commands can contain any
       characters at all, including the SOP octet, transparently to the
       Kermit protocol, and in fact Telnet commands are not seen by the
       Kermit protocol at all.

       Kermit protocol must follow Telnet NVT rules in each direction when
       Telnet binary mode is not negotiated for that direction.

       If 8-bit transparency is desired, Telnet binary mode may be
       negotiated upon entry to Kermit protocol in the appropriate
       direction, and the previous mode (NVT or binary) restored upon exit
       from Kermit protocol.  Telnet binary mode can result in more
       efficient transfers, but is not required for data transfer, since
       Kermit protocol does not require a transparent path.

    6. EXAMPLES

    6.1. EXAMPLE 1

       The Telnet server contains a Kermit server.  The Telnet client
       includes Kermit protocol but does not implement the Telnet KERMIT
       Option.

       Telnet Server                   Telnet Client
       -----------------------------   -----------------------------
       <starts negotiations>
       WILL KERMIT
       DO KERMIT
                                       <responds to negotiations>
                                       DONT KERMIT
                                       WONT KERMIT

       From this point, no subnegotiations take place, and the Kermit
       client/server relationship is under manual control of the user of the
       Telnet client.

    Altman & da Cruz             Informational                      [Page 6]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

    6.2. EXAMPLE 2

       The Telnet server contains a Kermit server and starts a Kermit server
       immediately after a connection is made.  The Telnet client does not
       offer a Kermit server.

       Telnet Server                   Telnet Client
       -----------------------------   -----------------------------
       <starts negotiations>
       WILL KERMIT
       DO KERMIT
                                       <responds to negotiations>
                                       DO KERMIT
                                       SB KERMIT SOP <0x01>
                                       WONT KERMIT
       SB KERMIT SOP <0x01>

       <starts Kermit Server>
       SB KERMIT START-SERVER

       At this point the Telnet client knows that a Kermit server is on the
       other end of the connection, and so may customize its command set or
       menus to allow only those commands that are valid as a client of a
       Kermit server.

    Altman & da Cruz             Informational                      [Page 7]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

    6.3. EXAMPLE 3

       Telnet server and Telnet client both contain a Kermit server.  Telnet
       client Kermit server is active whenever its terminal emulator is
       active, and not active at other times.  The Telnet server is used for
       shell access and does not start a Kermit Server unless requested.

       Telnet Server                 Telnet Client
       ---------------------------   -----------------------------
       <starts negotiations>
       WILL KERMIT
       DO KERMIT
                                     <responds to negotiations>
                                     DO KERMIT
                                     SB KERMIT SOP <0x01>
                                     WILL KERMIT
       SB KERMIT SOP <0x01>
                                     <telnet client enters terminal emulator>
                                     SB KERMIT START-SERVER

                                     <client leaves terminal emulator>
                                     SB KERMIT STOP-SERVER

                                     <client requests Kermit service>
                                     SB KERMIT REQ-START-SERVER
       <starts Kermit server>
       SB KERMIT RESP-START-SERVER
                                     <client sends Kermit FINISH packet>
       <stops Kermit server>
       SB KERMIT STOP-SERVER
                                     <client returns to terminal emulator>
                                     SB KERMIT START-SERVER

    Altman & da Cruz             Informational                      [Page 8]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

    6.4. EXAMPLE 4

       Telnet server and Telnet client both contain a Kermit server.  Telnet
       client's Kermit server is active whenever the terminal emulator is
       active.  Telnet server is used solely for Kermit protocol and
       automatically starts a Kermit Server upon accepting the connection.

       Telnet Server                 Telnet Client
       ---------------------------   -----------------------------
       <starts negotiations>
       WILL KERMIT
       DO KERMIT
                                     <responds to negotiations>
                                     DO KERMIT
                                     SB KERMIT SOP <0x01>
                                     WILL KERMIT

       SB KERMIT SOP <0x01>
                                     <client enters terminal emulator>
                                     SB KERMIT START-SERVER

       <in response to DO>
       SB KERMIT SOP <0x01>
       SB KERMIT START-SERVER
                                     <client restricts command set to
                                      Kermit protocol commands>
                                     SB KERMIT STOP-SERVER

                                     <client performs Kermit protocol
                                      operations>

                                     <client want to enter terminal mode>
                                     SB KERMIT REQ-STOP-SERVER

       <Kermit Server refuses>
       SB KERMIT RESP-START-SERVER

    Altman & da Cruz             Informational                      [Page 9]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

    6.5. EXAMPLE 5

       This is an example of something that should not be allowed to happen.
       Some Telnet clients that implement file transfer capabilities are
       designed to accept incoming connections.  In this situation the
       Telnet Client acts as a pseudo Telnet Server but without the ability
       to provide shell access or many of the other functions associated
       with Telnet.  If both Telnet clients support this option and contain
       a Kermit server that is active during terminal emulation there is the
       potential for a deadlock situation if scripting is also supported.
       This is because Telnet clients that support a script language do not
       process input while waiting for the next command to be issued.

       Telnet Client One             Telnet Client Two
       ---------------------------   -----------------------------
       <starts negotiations>
       WILL KERMIT
       DO KERMIT
                                     <responds to WILL>
                                     DO KERMIT
                                     SB KERMIT SOP <0x01>

       <in response to DO>
       SB KERMIT SOP <0x01>
       SB KERMIT START-SERVER
                                     <responds to DO>
                                     WILL KERMIT
                                     SB KERMIT START-SERVER

       <client one restricts command
        set to Kermit protocol and
        disables Kermit Server>
       SB KERMIT STOP-SERVER
                                     <client two restricts command
                                      set to Kermit protocol and
                                      disables Kermit Server>
                                     SB KERMIT STOP-SERVER

       At this point both clients have restricted their command set to
       Kermit Protocol commands.  However, in both cases neither side is
       processing input.  Therefore the following restriction MUST be
       enforced: A Telnet partner may not restrict the command set if it
       accepted the incoming connection.

    Altman & da Cruz             Informational                     [Page 10]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

    7. SECURITY

       Implementors of this Telnet Option must enforce appropriate user
       authentication and file system access restrictions in conjunction
       with their implementation of the Kermit file transfer protocol.
       These issues are beyond the scope of this document.

    8. REFERENCES

       [BCP] Bradner, S.,  "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

       [KER] da Cruz, Frank, "Kermit, A File Transfer Protocol", Digital
             Press/ Butterworth Heinemann, Newton, MA, ISBN 0-932376-88-6
             (1987).

       [IKS] da Cruz, F. and J. Altman, "Internet Kermit Service", RFC 2839,
             May 2000.

       [TEL] Postel, J. and J. Reynolds, "Telnet Protocol Specification",
             STD 8, RFC 854, May 1983.

       [TEL] Postel, J. and J. Reynolds, "Telnet Option Specification", STD
             8, RFC 855, May 1983.

    9. AUTHORS' ADDRESSES

       Jeffrey E. Altman

       EMail:jaltman@columbia.edu

       Frank da Cruz

       EMail: fdc@columbia.edu

       The Kermit Project
       Columbia University
       612 West 115th Street
       New York NY 10025-7799
       USA
       http://www.columbia.edu/kermit/
       http://www.kermit-project.org/

    Altman & da Cruz             Informational                     [Page 11]

    RFC 2840                  TELNET KERMIT OPTION                  May 2000

    10.  Full Copyright Statement

       Copyright (C) The Internet Society (2000).  All Rights Reserved.

       This document and translations of it may be copied and furnished to
       others, and derivative works that comment on or otherwise explain it
       or assist in its implementation may be prepared, copied, published
       and distributed, in whole or in part, without restriction of any
       kind, provided that the above copyright notice and this paragraph are
       included on all such copies and derivative works.  However, this
       document itself may not be modified in any way, such as by removing
       the copyright notice or references to the Internet Society or other
       Internet organizations, except as needed for the purpose of
       developing Internet standards in which case the procedures for
       copyrights defined in the Internet Standards process must be
       followed, or as required to translate it into languages other than
       English.

       The limited permissions granted above are perpetual and will not be
       revoked by the Internet Society or its successors or assigns.

       This document and the information contained herein is provided on an
       "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
       TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
       BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
       HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
       MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Altman & da Cruz             Informational                     [Page 12]