idnits 2.17.1 draft-altman-telnet-kermit-server-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 444 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 3 instances of too long lines in the document, the longest one being 2 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 (7 August 1998) is 9393 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'KER' -- Possible downref: Non-RFC (?) normative reference: ref. 'IKS' Summary: 9 errors (**), 0 flaws (~~), 2 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 7 August 1998 5 Expires: 12 February 1999 7 TELNET KERMIT OPTION 9 DRAFT 00 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress". 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.ca.za (Africa), ftp.nordu.net (Northern Europe), 26 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 27 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 ABSTRACT 31 This memo proposes an optional extension to the Telnet protocol to allow 32 the negotiation, coordination, and use of the Kermit file transfer and 33 management protocol within a Telnet session. 35 CONTENTS 37 1. INTRODUCTION 38 2. DEFINITIONS 39 3. TELNET KERMIT OPTION 40 4. KERMIT PROTOCOL IMPLICATIONS 41 5. EXAMPLES 42 5.1. EXAMPLE 1 43 5.2. EXAMPLE 2 44 5.3. EXAMPLE 3 45 5.4. EXAMPLE 4 46 5.5. EXAMPLE 5 47 6. REFERENCES 48 7. AUTHORS' ADDRESS 50 1. INTRODUCTION 52 The Kermit protocol [KER] performs error-corrected file transfer and 53 management over many types of connections, including terminal 54 connections, among diverse hardware and software platforms. It is 55 supported by a large number of Telnet clients and is also widely 56 available on the Internet hosts to which Telnet connections are made. 58 Traditionally, the Kermit protocol connection is started manually by a 59 user, or perhaps by an automated script. It is the user's 60 responsibility to start the Kermit server on one end of the connection 61 and the Kermit client on the other, or to start a Kermit "send" 62 operation on one end and a Kermit "receive" on the other. 64 This procedure grew out of necessity on ordinary direct-dial 65 connections, and serves its purpose within the limitations of that 66 context. But it introduces timing and dexterity problems, and lacks an 67 effective way for each Kermit program to determine the "mode" of the 68 other, or even its very presence, and therefore to know with certainty 69 which operations and procedures are legal on the connection at any given 70 time. 72 When Kermit services are offered on the Internet, however, a strong 73 coupling can be established between the two end applications by having 74 the Telnet protocol [TEL] serve as a supervisor for Kermit sessions, 75 ensuring that a valid and known relationship is always obtained. Kermit 76 sessions are, in effect, embedded within Telnet sessions, with Telnet 77 providing the mechanism for starting and stopping them and defining 78 which end is the Kermit client and which is the Kermit server, possibly 79 changing the relationship in response to user actions. 81 Kermit clients and servers that implement the Telnet Kermit Option can 82 form the basis of a new Internet Kermit Service, described in a separate 83 Internet Draft [IKS]. 85 This draft assumes knowledge of Transmission Control Protocol, the 86 Telnet Protocol [TEL], and the Kermit File Transfer Protocol [KER]. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [BCP]. 92 2. DEFINITIONS 94 Kermit server 95 A software program that is ready to accept and act upon commands in 96 the form of well-defined Kermit packets [KER]. 98 Kermit client 99 A software program that receives requests through its user interface 100 from a human agent (or a script or other source) and translates them to 101 command packets, which it sends to a Kermit server, thus initiating a 102 Kermit protocol transaction such as the transfer of one or more files. 104 Availability of Kermit server 105 For the purposes of this document, a Kermit server is said to be 106 available if, through the negotiations described herein, its Telnet 107 partner knows that it is a Kermit server. 109 3. TELNET KERMIT OPTION 111 Support for a Kermit server is negotiated separately in each direction, 112 allowing Kermit service to be embedded in the Telnet client, the Telnet 113 server, or in both. The proposed Telnet extensions are, therefore, 114 symmetrical. 116 When the connection is first opened, Kermit service is unavailable in 117 both directions. 119 The availability of Kermit service is negotiated using the following 120 Telnet option: 122 KERMIT 47 (or other number assigned by IANA) 124 NOTE: 47 is currently the lowest unassigned Telnet Option number, 125 but by the time you read this, it might well be assigned to some other 126 option. As noted above, do not consider this draft an authoritative 127 source of information. 129 The state of the connection is controlled by the following Telnet 130 subnegotiation function codes: 132 START-SERVER 0 133 STOP-SERVER 1 134 REQ-START-SERVER 2 135 REQ-STOP-SERVER 3 136 SOP 4 138 The KERMIT OPTION is negotiated using the standard Telnet mechanisms: 140 IAC WILL KERMIT 141 The sender of this command incorporates a Kermit server and is willing 142 to negotiate its use. 144 IAC WONT KERMIT 145 The sender of this command does not incorporate a Kermit server or 146 refuses to negotiate its use. 148 IAC DO KERMIT 149 The sender of this command requests that the receiver negotiate use of 150 a Kermit server. 152 IAC DONT KERMIT 153 The sender of this command refuses to negotiate the use of a Kermit 154 server. 156 Once WILL KERMIT is negotiated in a particular direction, subnegotiations 157 are used to indicate or request a change in state of the connection, or to 158 convey other information. Subnegotiations may be sent at any time. 160 IAC SB KERMIT START-SERVER 161 This command is sent by the WILL side to indicate that the Kermit 162 server is now active; that is, that client-initiated Kermit packets 163 will be accepted. 165 IAC SB KERMIT STOP-SERVER 166 This command is sent by the WILL side to indicate that the Kermit 167 server is no longer active, and therefore that it is not ready to 168 accept Kermit packets. 170 IAC SB KERMIT REQ-START-SERVER 171 This command is sent by the DO side to request that the Kermit server 172 be started. 174 IAC SB KERMIT REQ-STOP-SERVER 175 This command is sent by the DO side to request that the Kermit server 176 be stopped. 178 IAC SB KERMIT SOP 179 Kermit Start Of Packet. The sender of this command specifies the 180 octet it will use to mark the beginning of the Kermit packets it 181 sends. This command must be sent by each connection partner upon the 182 first WILL/DO pair to allow unambigious identification of Kermit 183 packets in the data stream. This subnegotiation must be sent whenever 184 the Start of Packet character changes. The values are restricted to 185 ASCII C0 control characters other than Carriage Return and NUL. The 186 normal value is 1 (ASCII SOH). The two Kermit partners normally use 187 the same SOP, but may use distinct ones if desired. 189 IAC SB KERMIT SOP is necessary to allow each Telnet partner to recognize 190 subsequent incoming Kermit packets. Data following the SOP is processed 191 by the Kermit packet analyzer. All other Kermit protocol parameters are 192 automatically negotiated within the Kermit protocol upon the initial 193 exchange of Kermit packets [KER]. 195 START-SERVER and STOP-SERVER commands must be sent by the WILL side 196 whenever the state of the Kermit server changes. Therefore, by 197 definition, the Kermit server is unavailable at the beginning of 198 negotiations. 200 The receiver of a REQ-START-SERVER or REQ-STOP-SERVER is not required to 201 agree to the request to change state. The receiver must respond with 202 either START-SERVER or STOP-SERVER to indicate the state of the Kermit 203 Server subsequent to the request. 205 If the Kermit server receives a Kermit packet commanding it to cease 206 Kermit service (such as a FINISH, REMOTE EXIT or BYE packet [KER]), it 207 must send IAC SB KERMIT STOP-SERVER if the command is accepted. 209 These rules ensure that the Telnet client's user interface always knows 210 whether (and on which end) a Kermit server is available, and can 211 therefore present the user only with valid choices, and that changes in 212 state of one Telnet partner automatically switch the other to a 213 complementary and valid state. 215 4. KERMIT PROTOCOL IMPLICATIONS 217 The Kermit protocol is described elsewhere [KER]. It is an extensible 218 and self-configuring protocol, like Telnet, and thus any two proper 219 Kermit implementations should interoperate automatically. 221 In Kermit, as in Telnet, one particular octet is distinguished. In 222 Telnet's case, it is IAC (decimal 255); in Kermit's it is the character 223 specified by the IAC SB KERMIT SOP negotiation, normally SOH (decimal 1, 224 Ctrl-A). All Kermit packets must begin with the SOP, and must not 225 contain IAC unless it is quoted with another IAC according to Telnet 226 rules (or else transformed and quoted according to Kermit rules). 228 Telnet protocol takes precedence over Kermit protocol; whenever an IAC 229 is detected, it is processed as the beginning of a Telnet command. 230 Telnet commands can contain any characters at all, including the SOP 231 octet, transparently to the Kermit protocol, and in fact Telnet commands 232 are not seen by the Kermit protocol at all. 234 Kermit protocol must follow Telnet NVT rules in each direction when 235 Telnet binary mode is not negotiated for that direction. 237 If 8-bit transparency is desired, Telnet binary mode may be negotiated 238 upon entry to Kermit protocol in the appropriate direction, and the 239 previous mode (NVT or binary) restored upon exit from Kermit protocol. 240 Telnet binary mode can result in more efficient transfers, but is not 241 required for data transfer, since Kermit protocol does not require a 242 transparent path. 244 5. EXAMPLES 246 5.1. EXAMPLE 1 248 The Telnet server contains a Kermit server. The Telnet client includes 249 Kermit protocol but does not implement the Telnet KERMIT Option. 251 Telnet Server Telnet Client 252 ----------------------------- ----------------------------- 253 254 WILL KERMIT 255 DO KERMIT 256 257 DONT KERMIT 258 WONT KERMIT 260 >From this point, no subnegotiations take place, and the Kermit 261 client/server relationship is under manual control of the user of the 262 Telnet client. This will be the case (for example) with existing 263 Kermit-capable Telnet clients. 265 5.2. EXAMPLE 2 267 The Telnet server contains a Kermit server and starts a Kermit server 268 immediately after a connection is made. The Telnet client does not 269 offer a Kermit server. 271 Telnet Server Telnet Client 272 ----------------------------- ----------------------------- 273 274 WILL KERMIT 275 DO KERMIT 276 277 DO KERMIT 278 SB KERMIT SOP <0x01> 279 WONT KERMIT 280 SB KERMIT SOP <0x01> 282 283 SB KERMIT START-SERVER 285 At this point the Telnet client knows that a Kermit server is on the 286 other end of the connection, and so may customize its command set or 287 menus to allow only those commands that are valid as a client of a 288 Kermit server. 290 5.3. EXAMPLE 3 292 Telnet server and Telnet client both contain a Kermit server. Telnet 293 client Kermit server is active whenever its terminal emulator is active, 294 and not active at other times. The Telnet server is used for shell 295 access and does not start a Kermit Server unless requested. 297 Telnet Server Telnet Client 298 --------------------------- ----------------------------- 299 300 WILL KERMIT 301 DO KERMIT 302 303 DO KERMIT 304 SB KERMIT SOP <0x01> 305 WILL KERMIT 306 SB KERMIT SOP <0x01> 307 308 SB KERMIT START-SERVER 310 311 SB KERMIT STOP-SERVER 313 314 SB KERMIT REQ-START-SERVER 315 316 SB KERMIT START-SERVER 317 318 319 SB KERMIT STOP-SERVER 320 321 SB KERMIT START-SERVER 323 5.4. EXAMPLE 4 325 Telnet server and Telnet client both contain a Kermit server. Telnet 326 client's Kermit server is active whenever the terminal emulator is 327 active. Telnet server is used solely for Kermit protocol and 328 automatically starts a Kermit Server upon accepting the connection. 330 Telnet Server Telnet Client 331 --------------------------- ----------------------------- 332 333 WILL KERMIT 334 DO KERMIT 335 336 DO KERMIT 337 SB KERMIT SOP <0x01> 338 WILL KERMIT 340 SB KERMIT SOP <0x01> 341 342 SB KERMIT START-SERVER 344 345 SB KERMIT SOP <0x01> 346 SB KERMIT START-SERVER 347 349 SB KERMIT STOP-SERVER 351 354 355 SB KERMIT REQ-STOP-SERVER 357 358 SB KERMIT START-SERVER 360 5.5. EXAMPLE 5 362 This is an example of something that should not be allowed to happen. 363 Some Telnet clients that implement file transfer capabilities are 364 designed to accept incoming connections. In this situation the Telnet 365 Client acts as a pseudo Telnet Server but without the ability to provide 366 shell access or many of the other functions associated with Telnet. If 367 both Telnet clients support this option and contain a Kermit server that 368 is active during terminal emulation there is the potential for a 369 deadlock situation if scripting is also supported. This is because 370 Telnet clients that support a script language do not process input while 371 waiting for the next command to be issued. 373 Telnet Client One Telnet Client Two 374 --------------------------- ----------------------------- 375 376 WILL KERMIT 377 DO KERMIT 378 379 DO KERMIT 380 SB KERMIT SOP <0x01> 382 383 SB KERMIT SOP <0x01> 384 SB KERMIT START-SERVER 385 386 WILL KERMIT 387 SB KERMIT START-SERVER 389 392 SB KERMIT STOP-SERVER 393 396 SB KERMIT STOP-SERVER 398 At this point both clients have restricted their command set to Kermit 399 Protocol commands. However, in both cases neither side is processing 400 input. Therefore the following restriction MUST be enforced: A Telnet 401 partner may not restrict the command set if it accepted the incoming 402 connection. 404 6. REFERENCES 406 [BCP] Bradner, Scott, RFC 2119, "Best Current Practice", March 1997. 408 [KER] da Cruz, Frank, "Kermit, A File Transfer Protocol", Digital Press/ 409 Butterworth Heinemann, Newton, MA, ISBN 0-932376-88-6 (1987). 411 [IKS] da Cruz, Frank, and Jeffrey E. Altman, "Internet Kermit Service", 412 Internet Draft , 413 August 1998. 415 [TEL] Postel, J., and J. Reynolds, "Telnet Protocol Specification", 416 RFC854, May 1983, et seq. 418 7. AUTHORS' ADDRESS 420 Jeffrey E. Altman 421 jaltman@columbia.edu 423 Frank da Cruz 424 fdc@columbia.edu 426 The Kermit Project 427 Columbia University 428 612 West 115th Street 429 New York NY 10025-7799 430 USA 431 http://www.columbia.edu/kermit/