idnits 2.17.1 draft-columbia-kermit-service-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-24) 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 758 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 9392 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: 'FTP' is defined on line 724, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TKO' -- Possible downref: Non-RFC (?) normative reference: ref. 'KER' -- Possible downref: Non-RFC (?) normative reference: ref. 'CKB' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMG' -- Possible downref: Non-RFC (?) normative reference: ref. 'K95' -- Possible downref: Non-RFC (?) normative reference: ref. 'PRF' -- Possible downref: Non-RFC (?) normative reference: ref. 'IAN' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Frank da Cruz 2 INTERNET-DRAFT Jeffrey E. Altman 3 Columbia University 4 7 August 1998 5 Expires: 12 February 1999 7 INTERNET KERMIT SERVICE 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 document describes a new file transfer service for the Internet 32 based on Telnet Protocol for option negotiation and Kermit Protocol for 33 file transfer and management. The Internet Kermit Service provides 34 access to both authenticated and anonymous users. The use of Kermit 35 protocol over a Telnet connection provides several advantages over FTP, 36 including easy traversal of firewalls, transfers over multiple 37 transports, and security via a combination of supported Telnet 38 authentication and encryption option negotiations, plus significant 39 functional benefits. 41 CONTENTS 43 1. INTRODUCTION 44 2. BACKGROUND 45 2.1. History 46 2.2. Motivation 47 3. THE INTERNET KERMIT SERVICE MODEL 48 3.1. Server-Side Kermit Server 49 3.2. Client-Side Kermit Server 50 3.3. Loosely Coupled Operation 51 4. AUTHENTICATION 52 4.1. Telnet Authentication 53 4.2. Plaintext Authentication via Kermit REMOTE LOGIN 54 4.3. Plaintext Authentication via Command Prompt 55 4.4. Anonymous Login 56 5. SERVICES 57 5.1. Features for System Administrators 58 5.2. Features for Users 59 5.3. User Interface 60 6. REFERENCES 61 7. AUTHORS' ADDRESS 63 1. INTRODUCTION 65 The Internet Kermit Service is intended to: 67 1. Provide direct access to Kermit services without requiring the 68 user to first login to a shell account; 70 2. Provide Kermit services to anonymous users; 72 3. Provide services to all Telnet clients that support Kermit file 73 transfer protocol via a simple, predictable, scriptable, and 74 well-documented textual interface; 76 4. Provide direct and tightly-coupled access to a Kermit server 77 when requested via the Telnet Kermit Option [TKO]. 79 This draft assumes knowledge of Transmission Control Protocol, the 80 Telnet Protocol [TEL], the Kermit File Transfer Protocol [KER,PRF], 81 Telnet Kermit Option [TKO], and the commands and features of Kermit 82 software [CKB,CMG,K95]. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [BCP]. 88 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 user (or a script or other source) and translates them 97 to command packets, which it sends to a Kermit server, thus 98 initiating a Kermit protocol transaction such as the transfer of one 99 or more files. 101 2. BACKGROUND 103 2.1. History 105 "Kermit" is the name of an extensible platform- and medium-independent 106 file transfer and management protocol [KER,PRF] and of a suite of 107 communications software programs that implement it and integrate it with 108 other communications functions [CMG,CKB,K95]. 110 The Kermit protocol was first developed at Columbia University in New 111 York City in 1981 for transferring files without errors between diverse 112 types of computers over potentially hostile communication links. Since 113 1981, the Kermit Project at Columbia University has expanded the 114 protocol, developed communications software that implements it upon key 115 platforms, and worked with volunteer programmers at other sites adapting 116 Kermit protocol to other platforms or communication methods. The Kermit 117 Project also serves as the central point of Kermit software development, 118 support, information, and distribution throughout the world. 120 Kermit software is now available for nearly every computer and operating 121 system in existence. The major features of the most popular Kermit 122 programs are: 124 . Connection establishment and maintenance for a variety of connection 125 methods including direct serial, dialup, TCP/IP, X.25, DECnet, and 126 NETBIOS. 128 . Terminal emulation. 130 . Error-free transfer of both text and binary files, individually or 131 in groups. 133 . Character-set translation during both terminal emulation and 134 text-mode file transfer -- a unique feature of Kermit software. 136 . Remote file management through the client/server protocol. 138 . A powerful and portable scripting language allowing complete 139 automation of any task that can be performed manually. 141 Kermit's command and script language is consistent across all platforms 142 and communication methods, thus offering a unified method for 143 accomplishing a wide range of communication tasks manually or under 144 script control. 146 A single Kermit program combines the functions of many different 147 programs such as uucp, cu, tip, telnet, rlogin, ftp, iconv, and expect: 148 it is a Telnet and Rlogin client that can also transfer files; it is a 149 file transfer program that can also convert character sets; it is a 150 dialout program that can use dialing directories and understands country 151 codes and area codes; it is fully scriptable; it offers both 152 client/server and interactive modes of operation. In its desktop 153 versions (particularly for DOS, Windows, and OS/2) it offers all the 154 features of communications software that are usually lacking from 155 Internet client software (key mapping, colors, scrollback, mouse 156 functions, printer control, etc) 158 Kermit software is widely used throughout the academic, government, and 159 corporate spheres, both in the USA and internationally. 161 In addition to the Kermit software developed and/or distributed by the 162 Kermit Project at Columbia University, hundreds of other software 163 products -- commercial, shareware, and freeware -- also include some 164 level of support for the Kermit protocol. Thus there are hundreds, 165 perhaps thousands, of independent and interoperable Kermit protocol 166 implementations based upon the open Kermit protocol specification [KER]. 168 The Internet has formed the primary mechanism by which users and 169 developers of Kermit software have collaborated to produce feature and 170 command sets that continually evolve to meet their needs as technology 171 changes. 173 2.2. Motivation. 175 Kermit protocol and software makes connections from one computer to 176 another and transfers data between them. Countless people "live" in 177 Kermit all day long; as a customizable Telnet or Rlogin (or serial 178 communication) client with a wide selection of terminal emulations and 179 convenience features, it is their window onto the Internet. 181 Others use it in more creative ways, including some that involve key 182 parts of the Internet, e.g. in batch or cron jobs that update news or 183 Web servers or fetch email, or to monitor routers, terminal servers, and 184 hubs and dial pagers when faults are detected. It is used by vendors of 185 telecommunications equipment for remote diagnosis, patching, and 186 updates. Telecom managers often use Kermit scripts to configure PBXs, 187 muxes, routers, or terminal servers. In the world of commerce, Kermit 188 is widely used for financial transactions, EDI, medical claim 189 submission, and so forth. It is used with mobile barcode readers in 190 warehousing and inventory applications. It is found in US Postal 191 Service sorting and scanning equipment. It connects many of the 192 logistics and supply systems throughout the military. It is found in 193 fast-food restaurant cash registers, milling and die-cutting machines, 194 textile looms and cutters, printing presses, and medical diagnostic 195 equipment. It was the communications backbone of the 1994 Brazilian 196 national election -- the largest in history. 198 And yet there has never been a strong, explicit connection of Kermit 199 with the Internet. In the early years, Kermit acted as a kind of 200 do-it-yourself network, enabling ordinary users to make connections that 201 were not already there, and for some years was the predominant method of 202 connecting a personal computer to the ARPAnet (e.g. by dialing a TAC). 204 Nowadays, however, with so many of the world's computers on the 205 Internet, the role of Kermit software and protocol is changing. Kermit 206 users on the network would like to have the features, functions, and 207 interface they are accustomed to -- especially the automation features 208 -- available for use in settings where presently only tools like FTP are 209 available -- and even more so in situations where standard software like 210 FTP can't be used. 212 An Internet Kermit Service can fill this role, and augment the data 213 transfer power and flexibity of other Internet applications such as Web 214 browsers: 216 . Like FTP, Kermit provides a service that can be accessed from many 217 different platforms with a consistent set of commands, but unlike 218 FTP, these commands include programming constructions such as 219 variables, arrays, looping and selection mechanisms, and local and 220 remote procedure calls. 222 . Like FTP, Kermit provides both text- and binary-mode data transfer, 223 as well as file management capabilities. But Kermit also offers 224 numerous features lacking from FTP, such as character-set 225 translation, flexible file selection mechanisms, attribute 226 preservation, and so on (see Section 5.3 for a longer list). 228 . Unlike standard FTP, Kermit can transfer data through firewalls or 229 proxies on a single well-known port. 231 . Unlike FTP, Kermit can transfer data across a combination of 232 transports (e.g. dial-up to a terminal server and thence to an 233 Internet host). 235 . Authentication and data transfer can take place over secure 236 connections (mutually authenticated and encrypted) using established 237 Telnet authentication and encryption options. 239 . Unlike traditional Kermit use over Telnet, anonymous access is 240 possible, and the considerable overhead of the intervening Telnet 241 server and pseudoterminal service is eliminated. 243 Until now the primary obstacles to an Internet Kermit Service have been: 245 . Issues of authentication and anonymous access. These have been 246 addressed in our prototype, as described Section 4 of this document. 248 . Issues of coordination and control. A Kermit software program can be 249 in any of several "modes": at its command prompt or menu, awaiting 250 commands from the user; in terminal mode, in which the user's 251 keystrokes are sent to the remote computer or service; or in protocol 252 mode, in which two Kermit programs communicate via well-defined 253 Kermit packets [KER]. Commands or operations valid in one mode do 254 not necessarily work in another. Until now, it has been the user's 255 responsibility to switch modes at one or both ends of the connection 256 as needed. A companion draft [TKO] to this one specifies a mechanism 257 to closely couple the client and server via Telnet protocol 258 negotiations, allowing each to know the other's state and to switch 259 to the appropriate mode automatically so a valid and useful 260 relationship obtains at all times. 262 . Lack of a standard TCP port. Port 1649 was assigned by the IANA for 263 this purpose (via email from Joyce Reynolds, 27 September 1995). 264 This port is provisionally designated as "Inspect" in the Internet 265 Assigned Numbers List of Registered Ports [IAN] until a standard is 266 issued for its use. This document proposes such a standard. 268 3. THE INTERNET KERMIT SERVICE MODEL 270 The Internet Kermit Service (IKS) uses a standard Telnet [TEL] 271 connection, in which all Telnet rules apply. Unlike FTP, which requires 272 additional TCP connections, IKS uses a single channel for both signaling 273 and data transfer. The connection is multiplexed via (a) Telnet 274 options, and (b) Kermit protocol messages. This allows existing Telnet 275 clients that also support the Kermit protocol, whether or not they 276 support the Telnet Kermit Option [TKO], to use the IKS and take 277 advantage of all relevant Telnet options including authentication and 278 encryption. 280 The system Internet services daemon (e.g. inetd) waits for a connection 281 on the Kermit socket (1649) and then starts the IKS on the new 282 connection. The IKS performs the familiar Telnet negotiations including 283 the Telnet Kermit option. Unlike a standard Telnet server, the IKS does 284 not support the ability to present the user with an interactive system 285 shell. The Kermit socket is used only for file transfer and management 286 functions provided by Kermit file transfer protocol and the Kermit 287 script language. 289 Once the connection is established, the Telnet Kermit Option is 290 negotiated in both directions. The results determine which of the 291 following configurations is used by the Telnet client and Server: 293 . Server-side Kermit Server (SKS) 294 . Client-side Kermit Server (CKS) 295 . No Kermit Server (NKS) 297 Different procedures and functions apply to each configuration. The 298 configuration may be changed at any time by Telnet Kermit Option 299 subnegotiations, which assure that the Telnet client and server are 300 always in compatible states. 302 The three configurations are described in the following sections. 304 3.1. Server-Side Kermit Server 306 In the Server-Side Kermit Server (SKS) configuration, the Telnet server 307 is the Kermit server and the Telnet client is the Kermit client. This 308 configuration is used when both Telnet client and IKS support the Telnet 309 Kermit Option and the IKS sends WILL KERMIT to the Telnet client and 310 receives DO KERMIT from the Telnet client [TKO]. 312 In this case, the IKS immediately starts a Kermit server and reports 313 this to the Telnet client with a Telnet KERMIT START-SERVER 314 subnegotiation. 316 The SKS configuration is appropriate when the user wishes to interact 317 only with the Telnet client's commands or menus. 319 If authentication was not performed with one of the Telnet 320 Authentication Option protocols, the Kermit server rejects all Kermit 321 protocol operations (except REMOTE LOGIN, REMOTE HELP, REMOTE EXIT, BYE, 322 or FINISH -- that is, the ones that request help, that log in, that 323 close the connection, or that change the status of the connection) 324 until: 326 . A Kermit REMOTE LOGIN command successfully authenticates the user; 328 . The login retry limit is reached; 330 . A Kermit BYE or REMOTE EXIT command is received, which closes 331 the connection; 333 . A Kermit FINISH command or a Telnet KERMIT REQ-KERMIT-STOP 334 subnegotiation is received to request the IKS exit from Kermit 335 server mode. At this point, the IKS can either exit and close 336 the connection or issue an interactive login prompt, depending 337 on how it was started or configured by the system administrator. 339 Once the user is authenticated: 341 . The Telnet client configures itself for Kermit client/server 342 operation, with itself as the Kermit client, communicating with the 343 server only by Kermit packets, and optionally adjusting its menus or 344 commands to eliminate functions (such as terminal emulation) that 345 make no sense in this context. 347 . The relationship persists until the Telnet client and IKS agree to 348 terminate the Kermit server via Kermit protocol commands (BYE, 349 FINISH, or REMOTE EXIT), or by Telnet Kermit Option subnegotiation, 350 or by closing the connection. 352 3.2. Client-Side Kermit Server 354 In the Client-Side Kermit Server (CKS) configuration, the Telnet server 355 is the Kermit client, and the Telnet client is the Kermit server. This 356 configuration is used when the IKS has sent WONT KERMIT or SB KERMIT 357 STOP-SERVER, and the Telnet Client has sent WILL KERMIT and SB KERMIT 358 START-SERVER, indicating that it is prepared to accept and process 359 Kermit protocol packets. 361 In the CKS configuration, the Telnet client assumes the role of Kermit 362 server by virtue of its ability to recognize and process Kermit protocol 363 packets in its terminal emulator. Thus the Telnet client must not send 364 WILL KERMIT or the KERMIT START-SERVER subnegotiation unless its 365 terminal emulator is capable of recognizing Kermit packets. 367 If the IKS is at top command level (as opposed to executing a script), 368 or when it reaches top level after finishing a script, it issues its 369 interactive command prompt. 371 At the point, the user may type commands or send scripted commands to 372 the IKS command prompt. When a data-transfer command (such as SEND) is 373 issued by the user at the IKS prompt, a Kermit packet is transmitted and 374 recognized by the Telnet client, causing it to automatically perform the 375 requested action (e.g. receive a file), and then resume its previous 376 mode (terminal emulation or script execution) when the data transfer is 377 complete. 379 Thus, in the CKS configuration, data transfers are initiated by the IKS 380 rather than by the Telnet client. This configuration is useful when the 381 user prefers the command interface or repertoire of the server to that 382 of the client. 384 If the IKS sends a Telnet KERMIT START-SERVER subnegotiation, the 385 relationship switches automatically to Server-Side Kermit Server 386 (Section 3.1), in which the Telnet client is the Kermit client and the 387 Telnet server is the Kermit server. 389 If the Telnet client sends a KERMIT STOP-SERVER subnegotiation, the 390 connection switches to No Kermit Server (Section 3.3) and the IKS issues 391 its command prompt. At this point, neither side is a Kermit server, and 392 both sides may optionally disable Kermit protocol commands. Subsequent 393 user action can designate one side or the other as the Kermit server, as 394 desired. 396 3.3. No Kermit Server 398 If both Telnet client and IKS send WONT KERMIT or SB KERMIT STOP-SERVER, 399 or if the Kermit client and server are connected across multiple hosts 400 or transports, thus precluding end-to-end Telnet negotiation, a Kermit 401 server is not known to be available. In the KERMIT STOP-SERVER case, 402 the Kermit partners can later switch back to SKS or CKS, but in the 403 other two cases, there is no such signaling and loose coupling 404 characterizes the entire session. 406 In the No Kermit Server (NKS) configuration, the IKS presents a command 407 prompt to the Telnet client. As in the Client-Side Kermit Server 408 configuration, plain-text commands are issued to the IKS. 410 In the loosely coupled NKS configuration, the Telnet client does not 411 know the state of the Telnet server, and so can not automatically adjust 412 its commands and menus to present only valid choices, or automatically 413 change its state to complement the server's; it is the user's 414 responsibility to assure that the "mode" (command prompt, terminal 415 emulation, server command wait) of each Kermit partner is appropriate 416 for each action. Thus an Internet Kermit Server appears as an ordinary 417 remote Kermit program to any Telnet client that does not implement the 418 Telnet Kermit Option, or in which this feature is disabled or can not be 419 used. 421 The NKS configuration allows successful manual operation of the IKS 422 through Telnet clients that do not support the Telnet Kermit Option. 423 The Telnet client might or might not support Kermit "autodownload" and 424 "autoupload"; if it does not, then the user is forced to "escape back" 425 and re-CONNECT in the traditional and familiar manner [CKB,CMG,K95]. 427 4. AUTHENTICATION 429 Authentication is provided in one of two ways: 431 . The Telnet AUTHENTICATION option; 433 . Plaintext userid/password verification. 435 4.1. Telnet Authentication 437 The use of one of the many Telnet authentication protocols removes the 438 need to transmit passwords in plaintext across public networks. In 439 addition, the exchange of authentication information often provides a 440 shared secret that can be used with the experimental Telnet Encryption 441 Option protocols to encrypt the connection in one or both directions. 443 4.2. Plaintext Authentication via Kermit REMOTE LOGIN 445 In the Server-Side Kermit Server configuration, if the client is not yet 446 authenticated, the client must log in using a REMOTE LOGIN command, in 447 which a Kermit packet containing user ID and password in clear text is 448 sent from the Telnet client to the Telnet server, which then calls upon 449 local mechanisms to authenticate the user. Any packets other than login 450 (or REMOTE HELP, REMOTE EXIT, FINISH, or BYE) packets are rejected 451 (returned with an error message) until the user is authenticated. If 452 the number of unsuccessful login attempts exceeds the limit, the 453 connection is closed. Many Kermit client programs support this login 454 method already. 456 4.3. Plaintext Authentication via Command Prompt 458 In the Client-Side Kermit Server and No Kermit Server configurations, 459 the server presents the user with a plain-text interactive interface 460 that begins with the server issuing "Username:" and "Password:" prompts, 461 just as if the user were logging in to a multiuser timesharing system 462 such as VMS or UNIX. When a password is not required an empty response 463 can be given. Invalid username-password combinations result in a new 464 series of prompts up to the login retry limit, and then disconnection. 466 4.4. Anonymous Login 468 When the username is "anonymous" or "ftp", the IKS behaves like an 469 anonymous ftp server, in a manner appropriate to the underlying 470 platform. In UNIX, for example, access is restricted to a designated 471 area of the file system. A password might or might not be required, 472 according to the preference of the site administrator. 474 5. SERVICES 476 The Internet Kermit Service includes features for both users and system 477 administrators. The prototype IKS is incorporated into a new release of 478 Columbia University's C-Kermit software, which is the "master" Kermit 479 software program in terms of features and command language. An overview 480 of C-Kermit can be found at: 482 http://www.columbia.edu/kermit/ckermit.html 484 (At some point during the lifetime of this draft, an IKS will be 485 deployed at Columbia University for worldwide public access to the 486 Kermit FTP site.) 488 When C-Kermit is employed as an Internet Kermit Service, it may offer 489 all its functions to "real" users (those who are authenticated as 490 specific users), and a safe subset of its functions to anonymous users. 492 The Internet Kermit Service resembles an FTP server in that it performs 493 its own authentication and uses a well-defined protocol to communicate 494 with its client, but differs from the FTP server by also offering (at 495 the system manager's discretion) an interactive user interface to the 496 Telnet client when it is in terminal mode. It also differs from FTP in 497 restricting all protocol messages and data transfer to a single socket 498 connection. 500 5.1. Features for System Administrators 502 The system administrator can supply IKS configuration parameters as 503 command-line options or in a configuration file, or both in combination. 504 Such parameters include: 506 . Whether anonymous logins are allowed. 508 . The file system or root directory to which anonymous users are 509 restricted. 511 . Specification of permissions and other attributes to be assigned to 512 files uploaded by anonymous users. 514 . Whether to make session entries in system logs. 516 . Specific services to disable: reception of files, sending of files, 517 sending of email, printing, changing of directories, getting 518 directory listings, deleting files, etc (see next section). 520 . Whether access to the interactive command prompt is allowed. 522 5.2. Features for Users 524 The IKS supports a wide range of services, including, but not limited 525 to, the following: 527 . Authentication as a real user or anonymously. 529 . Transmission of files to which read access is allowed. 531 . Reception of files into directories or devices to which write access 532 is allowed. 534 . The ability to display a file on the client's screen. 536 . Ability to list files. 538 . Ability to change its working (default) directory. 540 . Ability to delete files to which write or delete access is allowed. 542 . Ability to rename and copy files 544 . Ability to create and remove directories. 546 . The ability to route received files to a specified printer, or to 547 send them as email to a specified address list. 549 . Client control of server parameter settings, within limits 550 established by the server system administrator. 552 . Transmission of variables from client to server or vice versa. 554 . Remote and local script execution. 556 . Remote and local procedure execution. 558 File transfer features include: 560 . Kermit text-mode transfers incorporate not only record-format 561 conversion, but also character-set translation; 563 . Kermit can switch automatically between text and binary mode on a 564 per-file basis when sending groups of files by matching each file's 565 name with a pattern list. 567 . A selection of file collision options, including "make backup copy 568 of existing file and accept incoming file", "reject incoming file", 569 "accept incoming file only if newer than existing file", etc. 571 . Numerous methods for selecting the files to be transferred, including 572 pattern matching, lists of filenames (or patterns), exception lists, 573 date and/or size ranges, etc. 575 . Filename conversion and file renaming. 577 . Automatic directory creation if elected and enabled. 579 . Standard mechanisms for directory traversal, allowing transmission of 580 entire directory trees or other file hierarchies even between unlike 581 file systems such as VMS, UNIX, and Windows. 583 . Atomic file movement: optionally, the source file can be deleted 584 (or renamed, or moved) when and only when it has been transferred 585 successfully. 587 . Kermit can retain file attributes including time stamps and 588 permissions (at the user's or system administrator's discretion), 589 even between unlike platforms; 591 . Recovery of interrupted transfers from the point of failure. 593 . File-transfer pipes and filters. 595 Script programming features include: 597 . Macros with parameter substitution. 599 . Built-in and user-defined variables and arrays, with global 600 or local scope. 602 . Built-in and user-defined functions. Built-in functions include: 603 - String functions 604 - Arithmetic functions 605 - Date / time functions 606 - File functions 608 . Input search for multiple simultaneous targets. 610 . IF-ELSE, WHILE, FOR, SWITCH, GOTO, C-like block structure. 612 . Every command returns a completion status that may be tested 613 and used as a basis for subsequent actions. 615 5.3. User Interface 617 The Internet Kermit Service uses the Kermit command and script language, 618 as implemented in Columbia University's C-Kermit communication software 619 [CKB]. This program and its command language are portable to all known 620 varieties of UNIX, as well as to Windows 95/98/NT, OS/2, Digital 621 (Open)VMS, Stratus VOS, Data General AOS/VS, Plan 9, OS-9, QNX, the 622 Commodore Amiga, and other platforms. The C-Kermit command language is 623 a superset of that of other Kermit software programs including MS-DOS 624 Kermit for DOS and Windows 3.x, IBM Mainframe Kermit for VM/CMS, 625 MVS/TSO, CICS, and MUSIC, PDP-11 Kermit for RT-11, RSTS/E, RSX-11, and 626 IAS, and dozens of other Kermit programs. 628 It is far beyond the scope of this document to enumerate, let alone 629 describe, the commands and services of C-Kermit; this is the subject of 630 a 600-page book [CKB], augmented by hundreds of pages of online 631 material. A brief overview is included here. 633 Commands are based on English words. There is no plan at present to 634 support other natural languages (Italian, Portuguese, Norwegian, 635 Russian, Hebrew, Japanese, Cherokee, etc) as alternative bases for 636 command words, since this would reduce the portability of scripts. 637 However, since the command language includes a macro capability, macros 638 may be defined to provide selected commands in different languages if 639 desired. 641 Certain commands can apply either locally or remotely, for example "CD" 642 (Change Directory). The convention is to prefix the command with the 643 word REMOTE if it is to apply remotely. Example: "cd foo" changes to 644 the "foo" directory on the computer where the command was given; "remote 645 cd foo" sends a Kermit packet to the Kermit server requesting it to 646 change its directory to "foo". The commands in this category include: 648 ASSIGN Assign a value to a variable. 649 CD Change working directory. 650 COPY Copy file(s) 651 DELETE Delete file(s) 652 DIRECTORY [ ] List file(s) 653 EXIT Exit 654 HELP [ ] Display help text 655 MKDIR Create a directory 656 PRINT Print file(s) 657 PWD Print working directory 658 RENAME Rename file(s) 659 RMDIR Remove a directory 660 SET Change a parameter's value 661 TYPE Display the contents of a file 663 As a convenience, REMOTE commands also have short synonyms: RASSIGN, 664 RCD, RCOPY, RDELETE, and so forth. 666 The basic file transfer commands are: 668 SEND [ modifiers ] Send file(s) (to server) 669 GET [ modifiers ] Get file(s) (from server) 671 These commands take a file name, pattern, or list, plus various optional 672 modifiers, including transfer mode specifiers (text, binary), file 673 selectors (date, size, exception list), aliasing, name and path options, 674 disposition specifiers, and so on. 676 In addition to the commands listed above, the following commands are 677 sent by the client to the server: 679 REMOTE QUERY Get value of variable or procedure 680 BYE Log out and close the connection 681 FINISH Request the server leave server mode 683 Like all Kermit client/server commands, these can be disabled if 684 desired. 686 Of course there are numerous other commands with purely local effect, 687 such as the many scripting commands. These, plus all the commands 688 above, are fully documented in [CKB]. The repertoire grows over time, 689 but never in a way that invalidates existing scripts. 691 The system administrator can allow or forbid access to any of these 692 features, and to the command language as a whole. In the latter case, 693 the IKS may be accessed only as a Kermit server, by giving commands to 694 the client. 696 6. REFERENCES 698 [TKO] Altman, Jeffrey E., and Frank da Cruz, 699 Telnet Kermit Option, 700 Internet Draft , 701 August 1998. 703 [BCP] Bradner, Scott, RFC 2119, "Best Current Practice", March 1997. 705 [KER] da Cruz, Frank, "Kermit, A File Transfer Protocol", Digital Press/ 706 Butterworth Heinemann, Newton, MA (1987). 379 pages, 707 ISBN 0-932376-88-6. 709 [CKB] da Cruz, Frank, and Christine M. Gianone, "Using C-Kermit", Second 710 Edition, Digital Press / Butterworth-Heinemann, Woburn, MA (1997). 711 622 pages, ISBN 1-55558-164-1. 713 [CMG] Gianone, Christine M., "Using MS-DOS Kermit", Second Edition, 714 Digital Press / Butterworth-Heinemann, Woburn, MA (1992). 345 715 pages, ISBN 1-55558-082-3. 717 [K95] Gianone, Christine M., and Frank da Cruz, "Kermit 95", Manning 718 Publications, Greenwich CT, (1996). 88 pages, ISBN 1-884777-14-7. 720 [PRF] Huggins, James K., "Kermit Protocol - Formal Specification and 721 Verification", in Boerger, E., "Specification and Validation 722 Methods", Oxford University Press (1995). ISBN 0-19-853854-5. 724 [FTP] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", 725 RFC959, October 1985. 727 [TEL] Postel, J., and J. Reynolds, "Telnet Protocol Specification", 728 RFC854, May 1983, et seq. 730 [IAN] Internet Assigned Numbers Authority: 731 http://www.iana.org/numbers.html 732 http://www.iana.org/assignment/port-numbers 734 7. AUTHORS' ADDRESS 736 Frank da Cruz 737 fdc@columbia.edu 739 Jeffrey E. Altman 740 jaltman@columbia.edu 742 The Kermit Project 743 Columbia University 744 612 West 115th Street 745 New York NY 10025-7799 746 USA 747 http://www.columbia.edu/kermit/