1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
|
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
|