Simple File Transfer Protocol

Simple File Transfer Protocol, as defined by RFC 913, was proposed as an (unsecured) file transfer protocol with a level of complexity intermediate between TFTP and FTP.

It was never widely accepted on the Internet, and is now assigned Historic status by the IETF.

It is sometimes confused with SSH file transfer protocol, a secured file transfer protocol.

It runs through port 115, and often receives the acronym of SFTP. It has a command set of 11 commands and support three types of data transmission: ASCII, BINARY and CONTINUOUS. For systems which have "WORD SIZE" which are multiples of 8 bits, the implementation of BINARY and CONTINUOUS is the same.

The protocol supports the following:

1. User id based login (User-id/Password combination)
2. Hierarchical folders
3. File Management (Rename, Delete, Upload, Download, Download with overwrite, Download with append)

The protocol does not support random access inside a file (required for resuming interrupted transfers).

SFTP may refer to:

Relating to file transfer:

* SSH file transfer protocol, a network protocol designed by the IETF to provide secure file transfer and manipulation facilities over the secure shell (SSH) protocol. This is typically meant in context of file transfer.
* FTP over SSH, the practice of running an FTP session over SSH, sometimes called Secure FTP. Rarely used, because FTP's normal 2-channel nature makes such tunneling hard.
* Simple File Transfer Protocol, an unsecured and rarely-used file transfer protocol from the early days of the Internet.
* Serial File Transfer Protocol, a protocol used to transfer files between a PC and an embedded device using RS-232 or similar serial protocols.

SFTP may also refer to:

* Screened fully-shielded twisted pair, a kind of network cable, in contrast to FTP and STP
* Science for the People, a U.S. left-wing organization and magazine
* Six Flags Theme Parks, chain of amusement parks and theme parks.

Data format

While transferring data over the network, several data representations can be used. The two most common transfer modes are:
ASCII mode
Binary mode: In "Binary mode", the sending machine sends each file byte for byte and as such the recipient stores the bytestream as it receives it. (The FTP standard calls this "IMAGE" or "I" mode)

In "ASCII mode", any form of data that is not plain text will be corrupted. When a file is sent using an ASCII-type transfer, the individual letters, numbers, and characters are sent using their ASCII character codes. The receiving machine saves these in a text file in the appropriate format (for example, a Unix machine saves it in a Unix format, a Windows machine saves it in a Windows format). Hence if an ASCII transfer is used it can be assumed plain text is sent, which is stored by the receiving computer in its own format. Translating between text formats might entail substituting the end of line and end of file characters used on the source platform with those on the destination platform, e.g. a Windows machine receiving a file from a Unix machine will replace the line feeds with carriage return-line feed pairs. It might also involve translating characters; for example, when transferring from an IBM mainframe to a system using ASCII, EBCDIC characters used on the mainframe will be translated to their ASCII equivalents, and when transferring from the system using ASCII to the mainframe, ASCII characters will be translated to their EBCDIC equivalents.

By default, most FTP clients use ASCII mode. Some clients try to determine the required transfer-mode by inspecting the file's name or contents, or by determining whether the server is running an operating system with the same text file format.

The FTP specifications also list the following transfer modes:
EBCDIC mode - this transfers bytes, except they are encoded in EBCDIC rather than ASCII. Thus, for example, the ASCII mode server
Local mode - this is designed for use with systems that are word-oriented rather than byte-oriented. For example mode "L 36" can be used to transfer binary data between two 36-bit machines. In L mode, the words are packed into bytes rather than being padded. Given the predominance of byte-oriented hardware nowadays, this mode is rarely used. However, some FTP servers accept "L 8" as being equivalent to "I".

In practice, these additional transfer modes are rarely used. They are however still used by some legacy mainframe systems.

The text (ASCII/EBCDIC) modes can also be qualified with the type of carriage control used (e.g. TELNET NVT carriage control, ASA carriage control), although that is rarely used nowadays.

Note that the terminology "mode" is technically incorrect, although commonly used by FTP clients. "MODE" in RFC 959 refers to the format of the protocol data stream (STREAM, BLOCK or COMPRESSED), as opposed to the format of the underlying file. What is commonly called "mode" is actually the "TYPE", which specifies the format of the file rather than the data stream. FTP also supports specification of the file structure ("STRU"), which can be either FILE (stream-oriented files), RECORD (record-oriented files) or PAGE (special type designed for use with TENEX). PAGE STRU is not really useful for non-TENEX systems, and RFC1123 section 4.1.2.3 recommends that it not be implemented.