RFC relevance of information

As per Relevance of the word information, we have this rfc below:

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

TELNET KERMIT

Status of this

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

Copyright

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
document are to be interpreted as described in RFC 2119.

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

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.

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

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

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

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

2.

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

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

Altman & da Cruz Informational [Page 2]

RFC 2840 TELNET KERMIT OPTION May 2000

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

3. COMMANDS AND

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

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

The availability of Kermit service is negotiated using the
Telnet option

KERMIT 47 (assigned by IANA

The state of the connection is controlled by the following
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

The KERMIT OPTION is negotiated using the standard Telnet mechanisms

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

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

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

Altman & da Cruz Informational [Page 3]

RFC 2840 TELNET KERMIT OPTION May 2000

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

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

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

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

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

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

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

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

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

Altman & da Cruz Informational [Page 4]

RFC 2840 TELNET KERMIT OPTION May 2000

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

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

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

The receiver of a REQ-START-SERVER or REQ-STOP-SERVER is not
to agree to the request to change state. The receiver must
with either RESP-START-SERVER or RESP-STOP-SERVER to indicate
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
in state and the response to the DO side's request

If the Kermit server receives a Kermit packet commanding it to
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
knows whether (and on which end) a Kermit server is available,
can therefore present the user only with valid choices, and
changes in state of one Telnet partner automatically switch the
to a complementary and valid state

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

5. KERMIT PROTOCOL

The Kermit protocol is described elsewhere [KER]. It is
extensible and self-configuring protocol, like Telnet, and thus
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.
Telnet's case, it is IAC (decimal 255); in Kermit's it is
character specified by the IAC SB KERMIT SOP negotiation,
SOH (decimal 1, Ctrl-A). All Kermit packets must begin with the
and should not contain the SOP character in an unquoted form

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

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

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

6.

6.1. EXAMPLE 1

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

Telnet Server Telnet
----------------------------- -----------------------------
WILL
DO
<responds to negotiations
DONT
WONT

From this point, no subnegotiations take place, and the
client/server relationship is under manual control of the user of
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
immediately after a connection is made. The Telnet client does
offer a Kermit server

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

SB KERMIT START-

At this point the Telnet client knows that a Kermit server is on
other end of the connection, and so may customize its command set
menus to allow only those commands that are valid as a client of
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.
client Kermit server is active whenever its terminal emulator
active, and not active at other times. The Telnet server is used
shell access and does not start a Kermit Server unless requested

Telnet Server Telnet
--------------------------- -----------------------------
WILL
DO
<responds to negotiations
DO
SB KERMIT SOP <0x01>
WILL
SB KERMIT SOP <0x01>
terminal emulator
SB KERMIT START-

terminal emulator
SB KERMIT STOP-

requests Kermit service
SB KERMIT REQ-START-
SB KERMIT RESP-START-
SB KERMIT STOP-
terminal emulator
SB KERMIT START-

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.
client's Kermit server is active whenever the terminal emulator
active. Telnet server is used solely for Kermit protocol
automatically starts a Kermit Server upon accepting the connection

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

SB KERMIT SOP <0x01>
terminal emulator
SB KERMIT START-

response to DO
SB KERMIT SOP <0x01>
SB KERMIT START-
Kermit protocol commands
SB KERMIT STOP-

operations

terminal mode
SB KERMIT REQ-STOP-

SB KERMIT RESP-START-

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
designed to accept incoming connections. In this situation
Telnet Client acts as a pseudo Telnet Server but without the
to provide shell access or many of the other functions
with Telnet. If both Telnet clients support this option and
a Kermit server that is active during terminal emulation there is
potential for a deadlock situation if scripting is also supported
This is because Telnet clients that support a script language do
process input while waiting for the next command to be issued

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

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

set to Kermit protocol
disables Kermit Server
SB KERMIT STOP-
set to Kermit protocol
disables Kermit Server
SB KERMIT STOP-

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

Altman & da Cruz Informational [Page 10]

RFC 2840 TELNET KERMIT OPTION May 2000

7.

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

8.

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

[KER] da Cruz, Frank, "Kermit, A File Transfer Protocol",
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",
8, RFC 855, May 1983.

9. AUTHORS'

Jeffrey E.

EMail:jaltman@columbia.

Frank da

EMail: fdc@columbia.

The Kermit
Columbia
612 West 115th
New York NY 10025-7799

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

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

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

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

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

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

Altman & da Cruz Informational [Page 12]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX