RFC 2839

1. INTRODUCTION 🦋

Okay so, here's the vibe: RFC 2839 is titled Internet Kermit Service 🎀 and it's from the Network Working Group. The authors are F. da Cruz and J. Altman, both from Columbia University. The category is Informational 🌸, and the date is May 2000. This RFC doesn't list any RFCs that it obsoletes or updates, so there's nothing to chase there 💅.

---

Status of this Memo 📜

This memo gives info to the Internet community. It is not an Internet standard of any kind, and it can be shared without limits.

Copyright Notice ©

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

ABSTRACT ✨

This document describes a brand-new file transfer service for the Internet, built on the Telnet Protocol for option negotiation and the Kermit Protocol for file transfer and management 🦋. The Internet Kermit Service works for both authenticated users and anonymous users 🫶. Using Kermit over a Telnet connection gives you a bunch of perks over FTP: it's way easier to get through firewalls, it can transfer files over multiple transports, and it's secure thanks to a mix of supported Telnet authentication and encryption option negotiations. Plus, there are some seriously big functional benefits 🔥.

Here's the iconic part: even though this is a new service, the clients already exist on most platforms. They're Telnet clients that support the Kermit file transfer protocol, and you can get them from Columbia University's Kermit Project as well as plenty of third parties 💖.

TABLE OF CONTENTS 🗂️

   1. INTRODUCTION ................................................ 2
   2. BACKGROUND .................................................. 3
   2.1. History ................................................... 3
   2.2. Motivation ................................................ 4
   3. THE INTERNET KERMIT SERVICE MODEL ........................... 7
   3.1. Server-Side Kermit Server ................................. 7
   3.2. Client-Side Kermit Server ................................. 8
   3.3. Loosely Coupled Operation ................................. 9
   4. SECURITY CONSIDERATIONS .....................................10
   4.1. AUTHENTICATION ............................................10
   4.1.1. Telnet Authentication ...................................10
   4.1.2. Telnet over TLS option ..................................11
   4.1.3. Plaintext Authentication via Kermit REMOTE LOGIN ........11
   4.1.4. Plaintext Authentication via Command Prompt .............11
   4.1.5. Anonymous Login .........................................12
   4.2. ENCRYPTION (PRIVACY) ......................................12
   4.2.1  Telnet Encryption .......................................12
   4.2.2  Telnet Start_TLS ........................................12
   5. SERVICES ....................................................13
   5.1. Features for System Administrators ........................13
   5.2. Features for Users ........................................14
   5.3. User Interface ............................................16
   6. REFERENCES ..................................................18
   7. AUTHORS' ADDRESSES ..........................................19
   8. Full Copyright Statement ....................................20

PREFACE 🌈

This document describes an Internet Kermit Service (IKS) that gives you an alternative to FTP for transferring files 🍓. The service is built on both the TELNET protocol and the Kermit file transfer protocol.

1. INTRODUCTION 🦋

The Internet Kermit Service:

1. Gives you direct access to Kermit file transfer and management services without making you log in to a shell account first 🧚;
2. Gives Kermit file transfer and management services to anonymous users too 🌸;
3. Serves all Telnet clients that support the Kermit file transfer protocol through a simple, predictable, scriptable, and well-documented textual interface 💅;
4. Gives you direct and tightly-coupled access to a Kermit server when requested via the Telnet Kermit Option [TKO] 👑.

This memo assumes you already know about the Transmission Control Protocol, the Telnet Protocol [TEL], the Kermit File Transfer Protocol [KER,PRF], the Telnet Kermit Option [TKO], and the commands and features of Kermit software [CKB,CMG,K95]. No pressure, but it helps 🙈.

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 [BCP] 💜.

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 user (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 🫧.

2. BACKGROUND 🌸

2.1. History 📚

"Kermit" is the name of an extensible platform- and medium-independent file transfer and management protocol [KER,PRF], and also of a suite of communications software programs that implement it and integrate it with other communications functions [CMG,CKB,K95]. It's literally the whole package 🎀.

The Kermit protocol was first developed at Columbia University in New York City in 1981, for transferring files without errors between diverse types of computers over potentially hostile communication links 🤓. Ever since 1981, the Kermit Project at Columbia University has expanded the protocol, built communications software that implements it on key platforms, and worked with volunteer programmers at other sites to adapt Kermit protocol to other platforms or communication methods 🌈. The Kermit Project is also the central hub for Kermit software development, support, information, and distribution all over the world 🌍.

Kermit software is now available for nearly every computer and operating system in existence 💻. The major features of the most popular Kermit programs are:

• Connection establishment and maintenance for a variety of connection methods, including direct serial, dialup, TCP/IP, X.25, DECnet, and NETBIOS 🔌.
• Terminal emulation 🖥️.
• Error-free transfer of both text and binary files, individually or in groups 💯.
• Character-set translation during both terminal emulation and text-mode file transfer -- a unique feature of Kermit software 🦄.
• Remote file management through the client/server protocol 🗂️.
• A powerful and portable scripting language that lets you automate any task you could do by hand 🤖.

Kermit's command and script language is consistent across all platforms and communication methods, so you get one unified way to handle a wide range of communication tasks, whether you're doing them manually or under script control 🪄.

A single Kermit program combines the functions of many different programs, such as uucp, cu, tip, telnet, rlogin, ftp, iconv, and expect. It's giving multitasker 🙌: it's a Telnet and Rlogin client that can also transfer files; it's a file transfer program that can also convert character sets; it's a dialout program that can use dialing directories and understands country codes and area codes; it's fully scriptable; and it offers both client/server and interactive modes of operation. In its desktop versions (especially for DOS, Windows, and OS/2), it also has all the communications software features that Internet client software usually lacks, like key mapping, colors, scrollback, mouse functions, printer control, and more ✨.

Kermit software is widely used across the academic, government, and corporate worlds, both in the USA and internationally 🌎.

On top of the Kermit software that the Kermit Project at Columbia University develops and/or distributes, hundreds of other software products (commercial, shareware, and freeware) also support the Kermit protocol to some degree. So there are hundreds, maybe even thousands, of independent and interoperable Kermit protocol implementations, all based on the open Kermit protocol specification [KER] 🫶.

The Internet has been the main place where Kermit users and developers have collaborated to build feature and command sets that keep evolving to meet their needs as technology changes 🚀.

2.2. Motivation 💖

okay so Kermit protocol and software makes connections from one computer to another and transfers data between them 🦋 countless people basically "live" in Kermit all day long 😭 it's a customizable Telnet or Rlogin (or serial communication) client with a huge selection of terminal emulations and convenience features, so it's literally their window onto the Internet 🪟

others use it in way more creative ways, including some that involve key parts of the Internet 🔥 like batch or cron jobs that update news or Web servers or fetch email, or monitoring routers, terminal servers, and hubs and dialing pagers when faults get detected 🚨 vendors of telecom equipment use it for remote diagnosis, patching, and updates 🛠️ telecom managers often run Kermit scripts to configure PBXs, muxes, routers, or terminal servers 💅 in commerce, Kermit is widely used for financial transactions, EDI, medical claim submission, and so forth 💸 it's used with mobile barcode readers in warehousing and inventory apps 📦 it's in US Postal Service sorting and scanning equipment 📬 it connects a lot of the logistics and supply systems throughout the military 🫡 and it's found in fast-food restaurant cash registers, milling and die-cutting machines, textile looms and cutters, printing presses, and medical diagnostic equipment 🍟 it was the communications backbone of the 1994 Brazilian national election, the largest in history 🇧🇷👑

but here's the tea 🍵 there has never been a strong, explicit connection of Kermit with the Internet 🥺 in the early years, Kermit acted as a kind of do-it-yourself network, letting ordinary users make connections that weren't already there, and for some years it was the predominant way of connecting a personal computer to the ARPAnet (e.g. by dialing a TAC) 💾

now though, with so many of the world's computers on the Internet, the role of Kermit software and protocol is changing 🌈 Kermit users on the network would love to have the features, functions, and interface they're used to, especially the automation features, available in settings where only tools like FTP are currently available, and even more so in situations where standard software like FTP can't be used 🙈

an Internet Kermit Service can fill this role and augment the data transfer power and flexibility of other Internet applications, such as Web browsers ✨

• Like FTP, Kermit provides a service that can be accessed from many different platforms with a consistent set of commands, but unlike FTP, these commands include programming constructions such as variables, arrays, looping and selection mechanisms, and local and remote procedure calls 🧚
• Like FTP, Kermit provides both text- and binary-mode data transfer, as well as file management capabilities. But Kermit also offers numerous features lacking from FTP, such as character-set translation, flexible file selection mechanisms, attribute preservation, and so on (see Section 5.3 for a longer list) 🎀
• Unlike standard FTP, Kermit can transfer data through multiple firewalls, proxies, and network address translators (NATs) on a single port 🚪
• Unlike FTP, Kermit can transfer data across a combination of transports (e.g. dial-up to a terminal server and thence to an Internet host) 📞
• Authentication and data transfer can take place over secure connections (mutually authenticated and encrypted) using established Telnet authentication and encryption options 🔐
• Unlike traditional Kermit use over Telnet, anonymous access is possible, and the considerable overhead of the intervening Telnet server and pseudoterminal service is eliminated 🫧

until now, the main obstacles to an Internet Kermit Service have been:

• Issues of authentication, privacy, and anonymous access. These have been addressed in our implementation, as described Section 4 of this document 🔒
• Issues of coordination and control. A Kermit software program can be in any of several "modes": at its command prompt or menu, awaiting commands from the user; in terminal mode, in which the user's keystrokes are sent to the remote computer or service; or in protocol mode, in which two Kermit programs communicate via well-defined Kermit packets [KER]. Commands or operations valid in one mode do not necessarily work in another. Until now, it has been the user's responsibility to switch modes at one or both ends of the connection as needed 😩 a companion document [TKO] to this one specifies a mechanism to closely couple the client and server via Telnet protocol negotiations, so each one knows the other's state and can switch to the appropriate mode automatically, and a valid and useful relationship obtains at all times 🤝
• Lack of a standard TCP port. The "registered" port 1649 was assigned by IANA for this purpose (27 September 1995) and is named "Kermit". (renamed from "Inspect".) 🏷️

---

3. THE INTERNET KERMIT SERVICE MODEL ✨

okay now the fun part 🤩 the Internet Kermit Service (IKS) uses a standard Telnet [TEL] connection, and all Telnet rules apply 📜 unlike FTP, which needs additional TCP connections, IKS uses a single channel for both signaling and data transfer 🎯 the connection is multiplexed via (a) Telnet options, and (b) Kermit protocol messages. This means existing Telnet clients that also support the Kermit protocol, whether or not they support the Telnet Kermit Option [TKO], can use the IKS and take advantage of all the relevant Telnet options, including authentication and encryption 🔥

the system Internet services daemon (e.g. inetd) waits for a connection on the Kermit socket (1649) and then starts the IKS on the new connection 👀 the IKS does the familiar Telnet negotiations, including the Telnet Kermit option. Unlike a standard Telnet server, the IKS does not support giving the user an interactive system shell 🙅‍♀️ the Kermit socket is only used for file transfer and management functions provided by the Kermit file transfer protocol and the Kermit script language 📂

once the connection is established, the Telnet Kermit Option is negotiated in both directions 🤝 the results decide which of the following configurations the Telnet client and server use 🫶

• Server-side Kermit Server (SKS)
• Client-side Kermit Server (CKS)
• No Kermit Server (NKS)

each configuration has its own procedures and functions 💜 the configuration can change at any time through Telnet Kermit Option subnegotiations, which make sure the Telnet client and server are always in compatible states 🌸

the three configurations are described in the following sections 🦋

3.1. Server-Side Kermit Server 🖥️

in the Server-Side Kermit Server (SKS) configuration, the Telnet server is the Kermit server and the Telnet client is the Kermit client 🙌 this configuration is used when both the Telnet client and IKS support the Telnet Kermit Option, and the IKS sends WILL KERMIT to the Telnet client and receives DO KERMIT from the Telnet client [TKO] 💖

in this case, the IKS immediately starts a Kermit server and reports this to the Telnet client with a Telnet KERMIT START-SERVER subnegotiation 🚀

the SKS configuration is a great fit when the user only wants to interact with the Telnet client's commands or menus 🎀

if authentication wasn't performed with one of the Telnet Authentication Option protocols, the Kermit server rejects all Kermit protocol operations 🚫 the exceptions are REMOTE LOGIN, REMOTE HELP, REMOTE EXIT, BYE, or FINISH, which are the ones that request help, log in, close the connection, or change the status of the connection 🙏 this rejection keeps going until:

• A Kermit REMOTE LOGIN command successfully authenticates the user;
• The login retry limit is reached;
• A Kermit BYE or REMOTE EXIT command is received, which closes the connection;
• A Kermit FINISH command or a Telnet KERMIT REQ-KERMIT-STOP subnegotiation is received to request that the IKS exit Kermit server mode. At this point, the IKS can either exit and close the connection or issue an interactive login prompt, depending on how it was started or configured by the system administrator 🧑‍💻

once the user is authenticated 🥳

• The Telnet client configures itself for Kermit client/server operation, with itself as the Kermit client, communicating with the server only by Kermit packets, and optionally adjusting its menus or commands to get rid of functions (such as terminal emulation) that make no sense in this context 🧹
• The relationship persists until the Telnet client and IKS agree to terminate the Kermit server, via Kermit protocol commands (BYE, FINISH, or REMOTE EXIT), or by Telnet Kermit Option subnegotiation, or by closing the connection 🔚

3.2. Client-Side Kermit Server 🧚‍♀️

in the Client-Side Kermit Server (CKS) configuration, the Telnet server is the Kermit client, and the Telnet client is the Kermit server 🔄 this configuration is used when the IKS has sent WONT KERMIT or SB KERMIT STOP-SERVER, and the Telnet client has sent WILL KERMIT and SB KERMIT START-SERVER, which means it's ready to accept and process Kermit protocol packets 📦

in the CKS configuration, the Telnet client takes on the role of Kermit server because it can recognize and process Kermit protocol packets in its terminal emulator 🧠 so the Telnet client must not send WILL KERMIT or the KERMIT START-SERVER subnegotiation unless its terminal emulator can actually recognize Kermit packets 🛑

if the IKS is at top command level (as opposed to running a script), or when it gets back to top level after finishing a script, it issues its interactive command prompt 💬

at this point, the user can type commands or send scripted commands to the IKS command prompt ⌨️ when a data-transfer command (such as SEND) is issued by the user at the IKS prompt, a Kermit packet gets sent and recognized by the Telnet client, which then automatically performs the requested action (e.g. receives a file) and goes back to its previous mode (terminal emulation or script execution) once the data transfer is done 🎉

so in the CKS configuration, data transfers are started by the IKS rather than by the Telnet client 💫 this configuration is useful when the user prefers the command interface or repertoire of the server over that of the client 💅

if the IKS sends a Telnet KERMIT START-SERVER subnegotiation, the relationship automatically switches to Server-Side Kermit Server (Section 3.1), where the Telnet client is the Kermit client and the Telnet server is the Kermit server 🔁

if the Telnet client sends a KERMIT STOP-SERVER subnegotiation, the connection switches to No Kermit Server (Section 3.3) and the IKS issues its command prompt 🫧 at this point neither side is a Kermit server, and both sides may optionally disable Kermit protocol commands. Later, user action can make one side or the other the Kermit server, whichever they want ✨

3.3. No Kermit Server 🌸

okay so this one is about when there's NO Kermit server in the picture 👀 It's giving "nobody showed up to the party" 💀 Like, if the Telnet client AND the IKS both send WONT KERMIT or SB KERMIT STOP-SERVER, OR the Kermit client and server are split across multiple hosts or transports (which means end-to-end Telnet negotiation is basically off the table 🙈), then a Kermit server is not known to be available. In the KERMIT STOP-SERVER case, the Kermit partners can switch back to SKS or CKS later, bestie 🦋 But in the other two cases? No signaling at all, so the whole session is loosely coupled. Vibes only 🧚

In the No Kermit Server (NKS) configuration, the IKS shows a command prompt to the Telnet client. Same as the Client-Side Kermit Server setup, plain-text commands get sent to the IKS 💜

Now the loosely coupled NKS part is the spicy bit 🌶️ The Telnet client has NO idea what state the Telnet server is in, so it can't automatically adjust its commands and menus to show only valid choices, and it can't change its own state to match the server's either. Main character energy? Nope, it's the USER's job to make sure the "mode" (command prompt, terminal emulation, server command wait) of each Kermit partner fits each action 😭 So an Internet Kermit Server just looks like an ordinary remote Kermit program to any Telnet client that doesn't implement the Telnet Kermit Option, or where that feature is turned off or can't be used 🎀

The NKS setup still lets you manually operate the IKS through Telnet clients that don't support the Telnet Kermit Option, and that's honestly iconic 👑 The Telnet client might or might not support Kermit "autodownload" and "autoupload." If it doesn't, you're stuck typing commands on BOTH sides of the connection the old-school way [CKB,CMG,K95] 🍓

---

4. SECURITY CONSIDERATIONS 🔐

This section is serious business, bestie, so pay attention 😤✨

4.1. AUTHENTICATION 🗝️

Authentication is provided via one or more of the following methods:

• The Telnet AUTHENTICATION option;
• The Telnet START_TLS option;
• Plaintext userid/password verification.

4.1.1. Telnet Authentication option 💖

The use of one of the many Telnet authentication option methods gets rid of the need to send passwords in plaintext across public networks, which is huge 🙌 Also, the exchange of user authentication info often gives you a shared secret that can be used with the Telnet Encryption Option protocols to encrypt the connection in one or both directions. Iykyk 🫶

Telnet authentication can also be combined with the Telnet START_TLS option to negotiate end user identity over the encrypted and host authenticated TLS channel. Double layers, no notes 💅

The IKS currently supports Kerberos 4, Kerberos 5, Secure Remote Password and Microsoft NTLM authentication methods via the Telnet AUTH option 🔥

4.1.2. Telnet over TLS option 🔒

The Telnet START_TLS option handles the negotiation and setup of a TLS version 1 session after the initial telnet connection. The TLS connection gives you host to client authentication through X.509 certificate chains. TLS also supports optional client to host authentication using host verified X.509 certificates, which can be used to authenticate a userid the client provides or be mapped to a userid based on properties of the certificate 🌈

4.1.3. Plaintext Authentication via Kermit REMOTE LOGIN 🙈

In the Server-Side Kermit Server configuration, if the client isn't authenticated yet, it must log in using a REMOTE LOGIN command. This sends a Kermit packet with the user ID and password in clear text from the Telnet client to the Telnet server, which then calls on local mechanisms to authenticate the user. Any packets other than login packets (or REMOTE HELP, REMOTE EXIT, FINISH, or BYE) get rejected, returned with an error message, until the user is authenticated. If the number of unsuccessful login attempts goes over the limit, the connection is closed. Lots of Kermit client programs already support this login method 💀

This method should be avoided whenever possible. If plaintext passwords are used, they should only be sent after the Telnet START-TLS option has been negotiated (see 4.2.2). Otherwise, passwords are open to packet sniffing. 🚨

4.1.4. Plaintext Authentication via Command Prompt 💬

In the Client-Side Kermit Server and No Kermit Server configurations, the server shows the user a plain-text interactive interface that starts with the server issuing "Username:" and "Password:" prompts, just like logging into a multiuser timesharing system such as VMS or UNIX. When a password isn't required, an empty response can be given. Invalid username-password combos bring up a new series of prompts until the login retry limit is hit, and then it disconnects 😭

This method should be avoided whenever possible. If plaintext passwords are used, they should only be sent after the Telnet START-TLS option has been negotiated (see 4.2.2). Otherwise, passwords are open to packet sniffing. 🚨

4.1.5. Anonymous Login 🙋

When the username is "anonymous" or "ftp", the IKS acts like an anonymous ftp server, in a way that fits the underlying platform. On UNIX, for example, access is restricted to a designated area of the file system. Whether a password is required depends on the preference of the site administrator 🧚

If privacy is desired, the Telnet START-TLS option should be used (see 4.2.2). 🌸

4.2. ENCRYPTION (PRIVACY) 🕵️‍♀️

As the Internet gets more public and susceptible to eavesdropping, it becomes more and more necessary to have methods for private access to services. Telnet gives you two of these mechanisms:

• Telnet Encryption option
• Telnet START-TLS option

4.2.1. Telnet Encryption option 🦋

The Telnet Encryption option never actually achieved RFC status, but it's been used for years alongside the Telnet Auth option in Telnet clients and servers that support Kerberos 4, Kerberos 5, Secure Remote Password, and others. The IKS currently supports these encryption methods under the Telnet Encryption option:

• cast128_ofb64
• cast5_40_ofb64
• des_ofb64
• cast128_cfb64
• cast5_40_cfb64
• des_cfb64

4.2.2. Telnet over TLS option 🔐

Transport Layer Security (TLS), the successor to Secure Sockets Layer (SSL), provides methods to implement Server authentication, Client authentication, and Transport Layer encryption. Unlike Telnet Encryption, Start-TLS does NOT require Telnet Authentication in order to provide a private channel. That means it can be used together with plaintext passwords and anonymous connections 🫠

---

5. SERVICES ✨

The Internet Kermit Service has features for both users and system administrators 💖 The IKS is built into the 7.0 release of Columbia University's C-Kermit software, which is the "master" Kermit software program when it comes to features and command language 👑 You can check out an overview of C-Kermit at:

http://www.columbia.edu/kermit/ckermit.html
http://www.kermit-project.org/ckermit.html

When C-Kermit is employed as an Internet Kermit Service, it can offer all its functions to "real" users (the ones authenticated as specific users), and a safe subset of its functions to anonymous users 🎀

The Internet Kermit Service is kinda like an FTP server because it does its own authentication and uses a well-defined protocol to talk to its client. But it's different from an FTP server because it also offers (at the system manager's discretion) an interactive user interface to the Telnet client when it's in terminal mode 🌈 It also differs from FTP by restricting all protocol messages and data transfer to a single socket connection 🧚

An IKS has been deployed at Columbia University for worldwide public access to the Kermit FTP site 🌍

telnet://kermit.columbia.edu:1649/
telnet://ftp.kermit-project.org:1649/

5.1. Features for System Administrators 🛠️

The system administrator can supply IKS configuration parameters as command-line options, in a configuration file, or both in combination. Those parameters include:

• Whether anonymous logins are allowed.
• The file system or root directory that anonymous users are restricted to.
• Specification of permissions and other attributes to be assigned to files uploaded by anonymous users.
• Whether to make session entries in system logs.
• Specific services to disable: reception of files, sending of files, sending of email, printing, changing of directories, getting directory listings, deleting files, etc. (see next section).
• Whether access to the interactive command prompt is allowed. 💅

5.2. Features for Users ✨

okay bestie, the IKS is seriously packed 🎀 Here's everything it can do:

• Log in as a real user or anonymously 🫶
• Send files over, as long as read access is allowed 📤
• Receive files into directories or devices where write access is allowed 📥
• Show a file on the client's screen 👀
• List files 📋
• Change its working (default) directory 📂
• Delete files where write or delete access is allowed 🗑️
• Rename and copy files 🔁
• Create and remove directories 🌸
• Route received files to a specified printer, or email them to a specified address list 🖨️💌
• Let the client control server parameter settings, within limits set by the server system administrator 🎛️
• Transmit variables from client to server or vice versa 🧚
• Run scripts, both remotely and locally 📜
• Run procedures, both remotely and locally 🔥

File transfer is where it gets extra iconic 💅 These are the features:

• Kermit text-mode transfers do more than record-format conversion. They also do character-set translation 🌈
• Kermit can switch between text and binary mode automatically on a per-file basis when it's sending groups of files 🔄
• There's a bunch of file collision options, like "make backup copy of existing file and accept incoming file", "reject incoming file", "accept incoming file only if newer than existing file", and more 🛡️
• There are tons of ways to pick which files to transfer: pattern matching, lists of filenames (or patterns), exception lists, date and/or size ranges, and so on 🔍
• Filename conversion and file renaming 🏷️
• Automatic directory creation, if it's elected and enabled 📁
• Standard mechanisms for directory traversal, so entire directory trees or other file hierarchies can be sent even between unlike file systems such as VMS, UNIX, and Windows 🌳
• Atomic file movement: optionally, the source file can be deleted (or renamed, or moved) when and only when it has been transferred successfully. no half-done vibes 💖
• Kermit can keep file attributes, including time stamps and permissions (at the user's or system administrator's discretion), even between unlike platforms ⏰
• Interrupted transfers can be recovered from the point of failure 🩹
• File-transfer pipes and filters 🚰

Scripting is where the real magic happens 🪄 The script programming features include:

• Macros with parameter substitution ✨
• Built-in and user-defined variables and arrays, with global or local scope 📦
• Built-in and user-defined functions. The built-in ones include:
  • String functions
  • Arithmetic functions
  • Date / time functions
  • File functions
• Input search for multiple simultaneous targets 🎯
• IF-ELSE, WHILE, FOR, SWITCH, GOTO, and C-like block structure 🧱
• Every command returns a completion status that you can test and use as the basis for what happens next 🦋

5.3. User Interface 💻

okay so the Internet Kermit Service uses the Kermit command and script language, as it's implemented in Columbia University's C-Kermit communication software [CKB]. This program and its command language are portable to all known varieties of UNIX, plus Windows 95/98/NT, OS/2, Digital (Open)VMS, Stratus VOS, Data General AOS/VS, Plan 9, OS-9, QNX, the Commodore Amiga, and other platforms 🌍 The C-Kermit command language is a superset of the language used by other Kermit software programs, including MS-DOS Kermit for DOS and Windows 3.x, IBM Mainframe Kermit for VM/CMS, MVS/TSO, CICS, and MUSIC, PDP-11 Kermit for RT-11, RSTS/E, RSX-11, and IAS, and dozens of other Kermit programs 🤯

It's way beyond the scope of this doc to list, let alone explain, every C-Kermit command and service. That's the subject of a 600-page book [CKB], plus hundreds of pages of online material 📚 So here's just a quick overview 💕

Commands are based on English words. There's no plan right now to support other natural languages (Italian, Portuguese, Norwegian, Russian, Hebrew, Japanese, Cherokee, etc) as the base for command words, because that would reduce the portability of scripts 🙅‍♀️ BUT since the command language includes a macro capability, macros can be defined to provide selected commands in different languages if you want 🌏

Some commands can apply either locally or remotely, like "CD" (Change Directory) 🗺️ The convention is to put the word REMOTE in front of the command if it's meant to apply remotely. For example, "cd foo" changes to the "foo" directory on the computer where the command was given, while "remote cd foo" sends a Kermit packet to the Kermit server asking it to change its directory to "foo". The commands in this category are:

ASSIGN <variable> <value>      Assign a value to a variable.
CD <directory>                 Change working directory.
COPY <files> <destination>     Copy file(s)
DELETE <files>                 Delete file(s)
DIRECTORY [ <pattern> ]        List file(s)
EXIT                           Exit
HELP [ <topic-or-command> ]    Display help text
MKDIR <directory>              Create a directory
PRINT <files>                  Print file(s)
PWD                            Print working directory
RENAME <old> <new>             Rename file(s)
RMDIR <directory>              Remove a directory
SET <parameter> <value>        Change a parameter's value
TYPE <file>                    Display the contents of a file

As a bonus, REMOTE commands also have short synonyms: RASSIGN, RCD, RCOPY, RDELETE, and so forth 🎀

The basic file transfer commands are:

SEND [ modifiers ] <files>    Send file(s) (to server)
GET [ modifiers ] <files>     Get file(s) (from server)

These commands take a file name, pattern, or list, plus a bunch of optional modifiers. That includes transfer mode specifiers (text, binary), file selectors (date, size, exception list), aliasing, name and path options, disposition specifiers, and so on 🧁

Beyond the commands above, the client also sends these commands to the server:

REMOTE QUERY                   Get value of variable or procedure
BYE                            Log out and close the connection
FINISH                         Request the server leave server mode

Like all Kermit client/server commands, these can be disabled if you want 🔒

Of course there are loads of other commands with purely local effect, like the many scripting commands. These, plus all the commands above, are fully documented in [CKB] 📖 The repertoire keeps growing over time, but never in a way that breaks existing scripts 🫶

The system administrator can allow or forbid access to any of these features, and to the command language as a whole. If the command language is forbidden, the IKS can only be accessed as a Kermit server, by giving commands to the client 👑

---

6. REFERENCES 📚

[TKO] Altman, J. and F. da Cruz, "Telnet Kermit Option", RFC 2840, May 2000.

[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 (1987). 379 pages, ISBN 0-932376-88-6.

[CKB] da Cruz, Frank, and Christine M. Gianone, "Using C-Kermit", Second Edition, Digital Press / Butterworth-Heinemann, Woburn, MA (1997). 622 pages, ISBN 1-55558-164-1.

[CMG] Gianone, Christine M., "Using MS-DOS Kermit", Second Edition, Digital Press / Butterworth-Heinemann, Woburn, MA (1992). 345 pages, ISBN 1-55558-082-3.

[K95] Gianone, Christine M., and Frank da Cruz, "Kermit 95", Manning Publications, Greenwich CT, (1996). 88 pages, ISBN 1-884777-14-7.

[PRF] Huggins, James K., "Kermit Protocol - Formal Specification and Verification", in Boerger, E., "Specification and Validation Methods", Oxford University Press (1995). ISBN 0-19-853854-5.

[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.

[TEL] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC854, May 1983, et seq.; "Telnet Option Specification", STD 8, RFC855, May 1983, et seq.

[IAN] Internet Assigned Numbers Authority: http://www.iana.org/numbers.html http://www.iana.org/assignment/port-numbers

---

7. AUTHORS' ADDRESSES 💌

Frank da Cruz

EMail: fdc@columbia.edu

Jeffrey E. Altman

EMail: jaltman@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/

8. 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. ✨