RFC2840 日本語訳

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

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

                          TELNET KERMIT OPTION

TELNET KERMIT OPTION

Status of this Memo

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.

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 Notice

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

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.

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

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.

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

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

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

Altman & da Cruz Informational [Page 1]  RFC 2840 TELNET KERMIT OPTION May 2000

1. MOTIVATION

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.

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.

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.

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.

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

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 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.

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

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.

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

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.

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.

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:

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

     KERMIT           47 (assigned by IANA)

KERMIT 47 (assigned by IANA)

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

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

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

4. COMMAND MEANINGS

   The KERMIT OPTION is negotiated using the standard Telnet mechanisms:

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 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 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.

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

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.

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.

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 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 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-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 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-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 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

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

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.

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].

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.

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.

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.

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.

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].

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

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.

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

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.

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.

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.

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.

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. EXAMPLES

6.1. EXAMPLE 1

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.

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

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.

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

Altman & da Cruz Informational [Page 6]  RFC 2840 TELNET KERMIT OPTION May 2000

6.2. EXAMPLE 2

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.

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>

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

<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.

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

Altman & da Cruz Informational [Page 7]  RFC 2840 TELNET KERMIT OPTION May 2000

6.3. EXAMPLE 3

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 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

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 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

<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

Altman & da Cruz Informational [Page 8]  RFC 2840 TELNET KERMIT OPTION May 2000

6.4. EXAMPLE 4

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 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

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

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

<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 performs Kermit protocol operations>

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

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

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

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

Altman & da Cruz             Informational                      [Page 9]

RFC 2840                  TELNET KERMIT OPTION                  May 2000

Altman & da Cruz Informational [Page 9]  RFC 2840 TELNET KERMIT OPTION May 2000

6.5. EXAMPLE 5

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.

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>

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

<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

<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.

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

Altman & da Cruz Informational [Page 10]  RFC 2840 TELNET KERMIT OPTION May 2000

7. SECURITY

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.

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

8. REFERENCES

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

[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).

[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.

[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 Protocol Specification", STD 8, RFC 854, May 1983.

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

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

9. AUTHORS' ADDRESSES

9. AUTHORS' ADDRESSES

   Jeffrey E. Altman

Jeffrey E. Altman

   EMail:jaltman@columbia.edu

EMail:jaltman@columbia.edu

   Frank da Cruz

Frank da Cruz

   EMail: fdc@columbia.edu

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/

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

Altman & da Cruz Informational [Page 11]  RFC 2840 TELNET KERMIT OPTION May 2000

10.  Full Copyright Statement

10. Full Copyright Statement

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

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.

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.

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.

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

Acknowledgement

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

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

Altman & da Cruz             Informational                     [Page 12]

Altman & da Cruz Informational [Page 12]