idnits 2.17.1 draft-altman-telnet-kermit-server-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 484 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 January 2000) is 8856 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BCP' is defined on line 432, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'KER' -- Possible downref: Non-RFC (?) normative reference: ref. 'IKS' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jeffrey E. Altman 2 INTERNET-DRAFT Frank da Cruz 3 Columbia University 4 25 January 2000 5 Expires: 25 July 2000 7 TELNET KERMIT OPTION 9 DRAFT 02 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference mate- 22 rial or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119. 34 ABSTRACT 36 This Internet-Draft describes an extension to the Telnet protocol to allow 37 the negotiation, coordination, and use of the Kermit file transfer and 38 management protocol over an existing Telnet protocol connection. 40 CONTENTS 42 1. MOTIVATION 43 2. DEFINITIONS 44 3. COMMANDS AND CODES 45 4. COMMAND MEANINGS 46 5. KERMIT PROTOCOL IMPLICATIONS 47 6. EXAMPLES 48 6.1. EXAMPLE 1 49 6.2. EXAMPLE 2 50 6.3. EXAMPLE 3 51 6.4. EXAMPLE 4 52 6.5. EXAMPLE 5 53 7. SECURITY CONSIDERATIONS 54 8. REFERENCES 55 9. AUTHORS' ADDRESS 57 1. MOTIVATION 59 The Kermit protocol [KER] performs error-corrected file transfer and 60 management over many types of connections, including terminal 61 connections, among diverse hardware and software platforms. It is 62 supported by a large number of Telnet clients and is also widely 63 available on the Internet hosts to which Telnet connections are made. 65 Traditionally, the Kermit protocol connection is started manually by a 66 user, or perhaps by an automated script. It is the user's 67 responsibility to start the Kermit server on one end of the connection 68 and the Kermit client on the other, or to start a Kermit "send" 69 operation on one end and a Kermit "receive" on the other. 71 This procedure grew out of necessity on ordinary direct-dial 72 connections, and serves its purpose within the limitations of that 73 context. But it introduces timing and dexterity problems, and lacks an 74 effective way for each Kermit program to determine the "mode" of the 75 other, or even its very presence, and therefore to know with certainty 76 which operations and procedures are legal on the connection at any given 77 time. 79 When Kermit services are offered on the Internet, however, a strong 80 coupling can be established between the two end applications by having 81 the Telnet protocol [TEL] serve as a supervisor for Kermit sessions, 82 ensuring that a valid and known relationship is always obtained. Kermit 83 sessions are, in effect, embedded within Telnet sessions, with Telnet 84 providing the mechanism for starting and stopping them and defining 85 which end is the Kermit client and which is the Kermit server, possibly 86 changing the relationship in response to user actions. 88 2. DEFINITIONS 90 Kermit server 91 A software program that is ready to accept and act upon commands in 92 the form of well-defined Kermit packets [KER]. 94 Kermit client 95 A software program that receives requests through its user interface 96 from a human agent (or a script or other source) and translates them to 97 command packets, which it sends to a Kermit server, thus initiating a 98 Kermit protocol transaction such as the transfer of one or more files. 100 Availability of Kermit server 101 For the purposes of this document, a Kermit server is said to be 102 available if, through the negotiations described herein, its Telnet 103 partner knows that it is a Kermit server. 105 3. COMMANDS AND CODES 107 Support for a Kermit server is negotiated separately in each direction, 108 allowing Kermit service to be embedded in the Telnet client, the Telnet 109 server, or in both. The proposed Telnet extensions are, therefore, 110 symmetrical. 112 When the connection is first opened, Kermit service is unavailable in 113 both directions. 115 The availability of Kermit service is negotiated using the following 116 Telnet option: 118 KERMIT 47 (assigned by IANA) 120 The state of the connection is controlled by the following Telnet 121 subnegotiation function codes: 123 START-SERVER 0 124 STOP-SERVER 1 125 REQ-START-SERVER 2 126 REQ-STOP-SERVER 3 127 SOP 4 128 RESP-START-SERVER 8 129 RESP-STOP-SERVER 9 131 4. COMMAND MEANINGS 133 The KERMIT OPTION is negotiated using the standard Telnet mechanisms: 135 IAC WILL KERMIT 136 The sender of this command incorporates a Kermit server and is willing 137 to negotiate its use. 139 IAC WONT KERMIT 140 The sender of this command does not incorporate a Kermit server or 141 refuses to negotiate its use. 143 IAC DO KERMIT 144 The sender of this command requests that the receiver negotiate use of 145 a Kermit server. 147 IAC DONT KERMIT 148 The sender of this command refuses to negotiate the use of a Kermit 149 server. 151 Once WILL KERMIT is negotiated in a particular direction, subnegotiations 152 are used to indicate or request a change in state of the connection, or to 153 convey other information. Subnegotiations may be sent at any time. 155 IAC SB KERMIT START-SERVER 156 This command is sent by the WILL side to indicate that the Kermit 157 server is now active; that is, that client-initiated Kermit packets 158 will be accepted. 160 IAC SB KERMIT STOP-SERVER 161 This command is sent by the WILL side to indicate that the Kermit 162 server is no longer active, and therefore that it is not ready to 163 accept Kermit packets. 165 IAC SB KERMIT REQ-START-SERVER 166 This command is sent by the DO side to request that the Kermit server 167 be started. It must be responded to with either RESP-START-SERVER 168 or RESP-STOP-SERVER depending upon whether or not the request was 169 accepted. 171 IAC SB KERMIT REQ-STOP-SERVER 172 This command is sent by the DO side to request that the Kermit server 173 be stopped. It must be responded to with either RESP-START-SERVER 174 or RESP-STOP-SERVER depending upon whether or not the request was 175 accepted. 177 IAC SB KERMIT RESP-START-SERVER 178 This command is sent by the WILL side in response to REQ-START-SERVER 179 or REQ-STOP-SERVER to indicate that the Kermit server is active 180 after the request was accepted or denied. 182 IAC SB KERMIT RESP-STOP-SERVER 183 This command is sent by the WILL side in response to REQ-START-SERVER 184 or REQ-STOP-SERVER to indicate that the Kermit server is not active 185 after the request was accepted or denied. 187 IAC SB KERMIT SOP 188 Kermit Start Of Packet. The sender of this command specifies the 189 octet it will use to mark the beginning of the Kermit packets it 190 sends. This command must be sent by each connection partner upon the 191 first WILL/DO pair to allow unambigious identification of Kermit 192 packets in the data stream. This subnegotiation must be sent whenever 193 the Start of Packet character changes. The values are restricted to 194 ASCII C0 control characters other than Carriage Return and NUL. The 195 normal value is 1 (ASCII SOH). The two Kermit partners normally use 196 the same SOP, but may use distinct ones if desired. 198 IAC SB KERMIT SOP is necessary to allow each Telnet partner to recognize 199 subsequent incoming Kermit packets. Data following the SOP is processed 200 by the Kermit packet analyzer. All other Kermit protocol parameters are 201 automatically negotiated within the Kermit protocol upon the initial 202 exchange of Kermit packets [KER]. 204 START-SERVER and STOP-SERVER commands must be sent by the WILL side 205 whenever the state of the Kermit server changes. When WILL is 206 successfully negotiated the state of the WILL side is assumed to be 207 STOP-SERVER. If the server is active, the WILL side must send a 208 START-SERVER to indicate the change in state. 210 The receiver of a REQ-START-SERVER or REQ-STOP-SERVER is not required to 211 agree to the request to change state. The receiver must respond with 212 either RESP-START-SERVER or RESP-STOP-SERVER to indicate the state of the 213 Kermit Server subsequent to the request. RESP-xxx-SERVER is sent instead 214 of xxx-SERVER to enable the sender of REQ-xxx-SERVER to distinguish 215 between the WILL side's spontaneous change in state and the response 216 to the DO side's request. 218 If the Kermit server receives a Kermit packet commanding it to cease 219 Kermit service (such as a FINISH, REMOTE EXIT or BYE packet [KER]), it 220 must send IAC SB KERMIT STOP-SERVER if the command is accepted. 222 These rules ensure that the Telnet client's user interface always knows 223 whether (and on which end) a Kermit server is available, and can 224 therefore present the user only with valid choices, and that changes in 225 state of one Telnet partner automatically switch the other to a 226 complementary and valid state. 228 While it is possible for a traditional telnet service (port 23) to 229 implement this option while at the same time supporting the existing 230 remote shell access functionality, it is not expected that this option 231 will be used in that manner. Instead, this option is primarily meant 232 for use with dedicated Kermit services (port 1649) such as the 233 Internet Kermit Service [IKS]. 235 5. KERMIT PROTOCOL IMPLICATIONS 237 The Kermit protocol is described elsewhere [KER]. It is an extensible 238 and self-configuring protocol, like Telnet, and thus any two proper 239 Kermit implementations should interoperate automatically. 241 In Kermit, as in Telnet, one particular octet is distinguished. In 242 Telnet's case, it is IAC (decimal 255); in Kermit's it is the character 243 specified by the IAC SB KERMIT SOP negotiation, normally SOH (decimal 1, 244 Ctrl-A). All Kermit packets must begin with the SOP and should not 245 contain the SOP character in an unquoted form. 247 Telnet protocol takes precedence over Kermit protocol; whenever an IAC 248 is detected, it is processed as the beginning of a Telnet command unless 249 quoted by another IAC. Telnet commands can contain any characters at 250 all, including the SOP octet, transparently to the Kermit protocol, and 251 in fact Telnet commands are not seen by the Kermit protocol at all. 253 Kermit protocol must follow Telnet NVT rules in each direction when 254 Telnet binary mode is not negotiated for that direction. 256 If 8-bit transparency is desired, Telnet binary mode may be negotiated 257 upon entry to Kermit protocol in the appropriate direction, and the 258 previous mode (NVT or binary) restored upon exit from Kermit protocol. 259 Telnet binary mode can result in more efficient transfers, but is not 260 required for data transfer, since Kermit protocol does not require a 261 transparent path. 263 6. EXAMPLES 265 6.1. EXAMPLE 1 267 The Telnet server contains a Kermit server. The Telnet client includes 268 Kermit protocol but does not implement the Telnet KERMIT Option. 270 Telnet Server Telnet Client 271 ----------------------------- ----------------------------- 272 273 WILL KERMIT 274 DO KERMIT 275 276 DONT KERMIT 277 WONT KERMIT 279 >From this point, no subnegotiations take place, and the Kermit 280 client/server relationship is under manual control of the user of the 281 Telnet client. This will be the case (for example) with existing 282 Kermit-capable Telnet clients. 284 6.2. EXAMPLE 2 286 The Telnet server contains a Kermit server and starts a Kermit server 287 immediately after a connection is made. The Telnet client does not 288 offer a Kermit server. 290 Telnet Server Telnet Client 291 ----------------------------- ----------------------------- 292 293 WILL KERMIT 294 DO KERMIT 295 296 DO KERMIT 297 SB KERMIT SOP <0x01> 298 WONT KERMIT 299 SB KERMIT SOP <0x01> 301 302 SB KERMIT START-SERVER 304 At this point the Telnet client knows that a Kermit server is on the 305 other end of the connection, and so may customize its command set or 306 menus to allow only those commands that are valid as a client of a 307 Kermit server. 309 6.3. EXAMPLE 3 311 Telnet server and Telnet client both contain a Kermit server. Telnet 312 client Kermit server is active whenever its terminal emulator is active, 313 and not active at other times. The Telnet server is used for shell 314 access and does not start a Kermit Server unless requested. 316 Telnet Server Telnet Client 317 --------------------------- ----------------------------- 318 319 WILL KERMIT 320 DO KERMIT 321 322 DO KERMIT 323 SB KERMIT SOP <0x01> 324 WILL KERMIT 325 SB KERMIT SOP <0x01> 326 327 SB KERMIT START-SERVER 329 330 SB KERMIT STOP-SERVER 332 333 SB KERMIT REQ-START-SERVER 334 335 SB KERMIT RESP-START-SERVER 336 337 338 SB KERMIT STOP-SERVER 339 340 SB KERMIT START-SERVER 342 6.4. EXAMPLE 4 344 Telnet server and Telnet client both contain a Kermit server. Telnet 345 client's Kermit server is active whenever the terminal emulator is 346 active. Telnet server is used solely for Kermit protocol and 347 automatically starts a Kermit Server upon accepting the connection. 349 Telnet Server Telnet Client 350 --------------------------- ----------------------------- 351 352 WILL KERMIT 353 DO KERMIT 354 355 DO KERMIT 356 SB KERMIT SOP <0x01> 357 WILL KERMIT 359 SB KERMIT SOP <0x01> 360 361 SB KERMIT START-SERVER 363 364 SB KERMIT SOP <0x01> 365 SB KERMIT START-SERVER 366 368 SB KERMIT STOP-SERVER 370 373 374 SB KERMIT REQ-STOP-SERVER 376 377 SB KERMIT RESP-START-SERVER 379 6.5. EXAMPLE 5 381 This is an example of something that should not be allowed to happen. 382 Some Telnet clients that implement file transfer capabilities are 383 designed to accept incoming connections. In this situation the Telnet 384 Client acts as a pseudo Telnet Server but without the ability to provide 385 shell access or many of the other functions associated with Telnet. If 386 both Telnet clients support this option and contain a Kermit server that 387 is active during terminal emulation there is the potential for a 388 deadlock situation if scripting is also supported. This is because 389 Telnet clients that support a script language do not process input while 390 waiting for the next command to be issued. 392 Telnet Client One Telnet Client Two 393 --------------------------- ----------------------------- 394 395 WILL KERMIT 396 DO KERMIT 397 398 DO KERMIT 399 SB KERMIT SOP <0x01> 401 402 SB KERMIT SOP <0x01> 403 SB KERMIT START-SERVER 404 405 WILL KERMIT 406 SB KERMIT START-SERVER 408 411 SB KERMIT STOP-SERVER 412 415 SB KERMIT STOP-SERVER 417 At this point both clients have restricted their command set to Kermit 418 Protocol commands. However, in both cases neither side is processing 419 input. Therefore the following restriction MUST be enforced: A Telnet 420 partner may not restrict the command set if it accepted the incoming 421 connection. 423 7. SECURITY 425 Implementors of this Telnet Option must enforce appropriate user 426 authentication and file system access restrictions in conjunction with 427 their implementation of the Kermit file transfer protocol. These issues 428 are beyond the scope of this Internet-Draft. 430 8. REFERENCES 432 [BCP] Bradner, Scott, RFC 2119, "Best Current Practice", March 1997. 434 [KER] da Cruz, Frank, "Kermit, A File Transfer Protocol", Digital Press/ 435 Butterworth Heinemann, Newton, MA, ISBN 0-932376-88-6 (1987). 437 [IKS] da Cruz, Frank, and Jeffrey E. Altman, "Internet Kermit Service", 438 Internet Draft , 439 August 1998. 441 [TEL] Postel, J., and J. Reynolds, "Telnet Protocol Specification", 442 RFC854, May 1983, et seq.; "Telnet Option Specification", 443 RFC855, May 1983, et seq. 445 9. AUTHORS' ADDRESS 447 Jeffrey E. Altman 448 jaltman@columbia.edu 450 Frank da Cruz 451 fdc@columbia.edu 453 The Kermit Project 454 Columbia University 455 612 West 115th Street 456 New York NY 10025-7799 457 USA 458 http://www.columbia.edu/kermit/ 459 http://www.kermit-project.org/ 461 (End) 463 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 464 The Kermit Project * Columbia University 465 612 West 115th St #716 * New York, NY * 10025 466 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org