`IEN 149 J. Postel
`RFC 765 ISI
` June 1980
`
` FILE TRANSFER PROTOCOL
`
`INTRODUCTION
`
` The objectives of FTP are 1) to promote sharing of files (computer
` programs and/or data), 2) to encourage indirect or implicit (via
` programs) use of remote computers, 3) to shield a user from
` variations in file storage systems among Hosts, and 4) to transfer
` data reliably and efficiently. FTP, though usable directly by a user
` at a terminal, is designed mainly for use by programs.
`
` The attempt in this specification is to satisfy the diverse needs of
` users of maxi-Hosts, mini-Hosts, and TIPs, with a simple, and easily
` implemented protocol design.
`
` This paper assumes knowledge of the following protocols described in
` the ARPA Internet Protocol Handbook.
`
` The Transmission Control Protocol
`
` The TELNET Protocol
`
`DISCUSSION
`
` In this section, the terminology and the FTP model are discussed.
` The terms defined in this section are only those that have special
` significance in FTP. Some of the terminology is very specific to the
` FTP model; some readers may wish to turn to the section on the FTP
` model while reviewing the terminology.
`
` TERMINOLOGY
`
` ASCII
`
` The ASCII character set as defined in the ARPA Internet
` Protocol Handbook. In FTP, ASCII characters are defined to be
` the lower half of an eight-bit code set (i.e., the most
` significant bit is zero).
`
` access controls
`
` Access controls define users’ access privileges to the use of a
` system, and to the files in that system. Access controls are
` necessary to prevent unauthorized or accidental use of files.
` It is the prerogative of a server-FTP process to invoke access
` controls.
`
` 1
`
`NOAC Ex. 1040 Page 1
`
`

`

`
`June 1980 IEN 149
`File Transfer Protocol RFC 765
`
` byte size
`
` There are two byte sizes of interest in FTP: the logical byte
` size of the file, and the transfer byte size used for the
` transmission of the data. The transfer byte size is always 8
` bits. The transfer byte size is not necessarily the byte size
` in which data is to be stored in a system, nor the logical byte
` size for interpretation of the structure of the data.
`
` data connection
`
` A simplex connection over which data is transferred, in a
` specified mode and type. The data transferred may be a part of
` a file, an entire file or a number of files. The path may be
` between a server-DTP and a user-DTP, or between two
` server-DTPs.
`
` data port
`
` The passive data transfer process "listens" on the data port
` for a connection from the active transfer process in order to
` open the data connection.
`
` EOF
`
` The end-of-file condition that defines the end of a file being
` transferred.
`
` EOR
`
` The end-of-record condition that defines the end of a record
` being transferred.
`
` error recovery
`
` A procedure that allows a user to recover from certain errors
` such as failure of either Host system or transfer process. In
` FTP, error recovery may involve restarting a file transfer at a
` given checkpoint.
`
` FTP commands
`
` A set of commands that comprise the control information flowing
` from the user-FTP to the server-FTP process.
`
` 2
`
`NOAC Ex. 1040 Page 2
`
`

`

`
`IEN 149 June 1980
`RFC 765 File Transfer Protocol
`
` file
`
` An ordered set of computer data (including programs), of
` arbitrary length, uniquely identified by a pathname.
`
` mode
`
` The mode in which data is to be transferred via the data
` connection. The mode defines the data format during transfer
` including EOR and EOF. The transfer modes defined in FTP are
` described in the Section on Transmission Modes.
`
` NVT
`
` The Network Virtual Terminal as defined in the TELNET Protocol.
`
` NVFS
`
` The Network Virtual File System. A concept which defines a
` standard network file system with standard commands and
` pathname conventions. FTP only partially implements the NVFS
` concept at this time.
`
` page
`
` A file may be structured as a set of independent parts called
` pages. FTP supports the transmission of discontinuous files as
` independent indexed pages.
`
` pathname
`
` Pathname is defined to be the character string which must be
` input to a file system by a user in order to identify a file.
` Pathname normally contains device and/or directory names, and
` file name specification. FTP does not yet specify a standard
` pathname convention. Each user must follow the file naming
` conventions of the file systems involved in the transfer.
`
` record
`
` A sequential file may be structured as a number of contiguous
` parts called records. Record structures are supported by FTP
` but a file need not have record structure.
`
` 3
`
`NOAC Ex. 1040 Page 3
`
`

`

`
`June 1980 IEN 149
`File Transfer Protocol RFC 765
`
` reply
`
` A reply is an acknowledgment (positive or negative) sent from
` server to user via the TELNET connections in response to FTP
` commands. The general form of a reply is a completion code
` (including error codes) followed by a text string. The codes
` are for use by programs and the text is usually intended for
` human users.
`
` server-DTP
`
` The data transfer process, in its normal "active" state,
` establishes the data connection with the "listening" data port,
` sets up parameters for transfer and storage, and transfers data
` on command from its PI. The DTP can be placed in a "passive"
` state to listen for, rather than initiate a, connection on the
` data port.
`
` server-FTP process
`
` A process or set of processes which perform the function of
` file transfer in cooperation with a user-FTP process and,
` possibly, another server. The functions consist of a protocol
` interpreter (PI) and a data transfer process (DTP).
`
` server-PI
`
` The protocol interpreter "listens" on Port L for a connection
` from a user-PI and establishes a TELNET communication
` connection. It receives standard FTP commands from the
` user-PI, sends replies, and governs the server-DTP.
`
` TELNET connections
`
` The full-duplex communication path between a user-PI and a
` server-PI, operating according to the TELNET Protocol.
`
` type
`
` The data representation type used for data transfer and
` storage. Type implies certain transformations between the time
` of data storage and data transfer. The representation types
` defined in FTP are described in the Section on Establishing
` Data Connections.
`
` 4
`
`NOAC Ex. 1040 Page 4
`
`

`

`
`IEN 149 June 1980
`RFC 765 File Transfer Protocol
`
` user
`
` A human being or a process on behalf of a human being wishing
` to obtain file transfer service. The human user may interact
` directly with a server-FTP process, but use of a user-FTP
` process is preferred since the protocol design is weighted
` towards automata.
`
` user-DTP
`
` The data transfer process "listens" on the data port for a
` connection from a server-FTP process. If two servers are
` transferring data between them, the user-DTP is inactive.
`
` user-FTP process
`
` A set of functions including a protocol interpreter, a data
` transfer process and a user interface which together perform
` the function of file transfer in cooperation with one or more
` server-FTP processes. The user interface allows a local
` language to be used in the command-reply dialogue with the
` user.
`
` user-PI
`
` The protocol interpreter initiates the TELNET connection from
` its port U to the server-FTP process, initiates FTP commands,
` and governs the user-DTP if that process is part of the file
` transfer.
`
` 5
`
`NOAC Ex. 1040 Page 5
`
`

`

`
`June 1980 IEN 149
`File Transfer Protocol RFC 765
`
` THE FTP MODEL
`
` With the above definitions in mind, the following model (shown in
` Figure 1) may be diagrammed for an FTP service.
`
` -------------
` |/---------\|
` || User || --------
` ||Interface|<--->| User |
` |\----:----/| --------
` ---------- | V |
` |/------\| FTP Commands |/---------\|
` ||Server|<---------------->| User ||
` || PI || FTP Replies || PI ||
` |\--:---/| |\----:----/|
` | V | | V |
` -------- |/------\| Data |/---------\| --------
` | File |<--->|Server|<---------------->| User |<--->| File |
` |System| || DTP || Connection || DTP || |System|
` -------- |\------/| |\---------/| --------
` ---------- -------------
`
` Server-FTP User-FTP
`
` NOTES: 1. The data connection may be used in either direction.
` 2. The data connection need not exist all of the time.
`
` Figure 1 Model for FTP Use
`
` In the model described in Figure 1, the user-protocol interpreter
` initiates the TELNET connection. At the initiation of the user,
` standard FTP commands are generated by the user-PI and transmitted
` to the server process via the TELNET connection. (The user may
` establish a direct TELNET connection to the server-FTP, from a TIP
` terminal for example, and generate standard FTP commands himself,
` bypassing the user-FTP process.) Standard replies are sent from
` the server-PI to the user-PI over the TELNET connection in
` response to the commands.
`
` The FTP commands specify the parameters for the data connection
` (data port, transfer mode, representation type, and structure) and
` the nature of file system operation (store, retrieve, append,
` delete, etc.). The user-DTP or its designate should "listen" on
` the specified data port, and the server initiate the data
` connection and data transfer in accordance with the specified
` parameters. It should be noted that the data port need not be in
`
` 6
`
`NOAC Ex. 1040 Page 6
`
`

`

`
`IEN 149 June 1980
`RFC 765 File Transfer Protocol
`
` the same Host that initiates the FTP commands via the TELNET
` connection, but the user or his user-FTP process must ensure a
` "listen" on the specified data port. It should also be noted that
` the data connection may be used for simultaneous sending and
` receiving.
`
` In another situation a user might wish to transfer files between
` two Hosts, neither of which is his local Host. He sets up TELNET
` connections to the two servers and then arranges for a data
` connection between them. In this manner control information is
` passed to the user-PI but data is transferred between the server
` data transfer processes. Following is a model of this
` server-server interaction.
`
`
` TELNET ------------ TELNET
` ---------->| User-FTP |<-----------
` | | User-PI | |
` | | "C" | |
` V ------------ V
` -------------- --------------
` | Server-FTP | Data Connection | Server-FTP |
` | "A" |<---------------------->| "B" |
` -------------- Port (A) Port (B) --------------
`
`
` Figure 2
`
` The protocol requires that the TELNET connections be open while
` data transfer is in progress. It is the responsibility of the
` user to request the closing of the TELNET connections when
` finished using the FTP service, while it is the server who takes
` the action. The server may abort data transfer if the TELNET
` connections are closed without command.
`
`DATA TRANSFER FUNCTIONS
`
` Files are transferred only via the data connection. The TELNET
` connection is used for the transfer of commands, which describe the
` functions to be performed, and the replies to these commands (see the
` Section on FTP Replies). Several commands are concerned with the
` transfer of data between Hosts. These data transfer commands include
` the MODE command which specify how the bits of the data are to be
` transmitted, and the STRUcture and TYPE commands, which are used to
` define the way in which the data are to be represented. The
` transmission and representation are basically independent but
`
` 7
`
`NOAC Ex. 1040 Page 7
`
`

`

`
`June 1980 IEN 149
`File Transfer Protocol RFC 765
`
` "Stream" transmission mode is dependent on the file structure
` attribute and if "Compressed" transmission mode is used the nature of
` the filler byte depends on the representation type.
`
` DATA REPRESENTATION AND STORAGE
`
` Data is transferred from a storage device in the sending Host to a
` storage device in the receiving Host. Often it is necessary to
` perform certain transformations on the data because data storage
` representations in the two systems are different. For example,
` NVT-ASCII has different data storage representations in different
` systems. PDP-10’s generally store NVT-ASCII as five 7-bit ASCII
` characters, left-justified in a 36-bit word. 360’s store NVT-ASCII
` as 8-bit EBCDIC codes. Multics stores NVT-ASCII as four 9-bit
` characters in a 36-bit word. It may be desirable to convert
` characters into the standard NVT-ASCII representation when
` transmitting text between dissimilar systems. The sending and
` receiving sites would have to perform the necessary
` transformations between the standard representation and their
` internal representations.
`
` A different problem in representation arises when transmitting
` binary data (not character codes) between Host systems with
` different word lengths. It is not always clear how the sender
` should send data, and the receiver store it. For example, when
` transmitting 32-bit bytes from a 32-bit word-length system to a
` 36-bit word-length system, it may be desirable (for reasons of
` efficiency and usefulness) to store the 32-bit bytes
` right-justified in a 36-bit word in the latter system. In any
` case, the user should have the option of specifying data
` representation and transformation functions. It should be noted
` that FTP provides for very limited data type representations.
` Transformations desired beyond this limited capability should be
` performed by the user directly.
`
` Data representations are handled in FTP by a user specifying a
` representation type. This type may implicitly (as in ASCII or
` EBCDIC) or explicitly (as in Local byte) define a byte size for
` interpretation which is referred to as the "logical byte size."
` This has nothing to do with the byte size used for transmission
` over the data connection, called the "transfer byte size", and the
` two should not be confused. For example, NVT-ASCII has a logical
` byte size of 8 bits. If the type is Local byte, then the TYPE
` command has an obligatory second parameter specifying the logical
` byte size. The transfer byte size is always 8 bits.
`
` 8
`
`NOAC Ex. 1040 Page 8
`
`

`

`
`IEN 149 June 1980
`RFC 765 File Transfer Protocol
`
` The types ASCII and EBCDIC also take a second (optional)
` parameter; this is to indicate what kind of vertical format
` control, if any, is associated with a file. The following data
` representation types are defined in FTP:
`
` ASCII Format
`
` This is the default type and must be accepted by all FTP
` implementations. It is intended primarily for the transfer
` of text files, except when both Hosts would find the EBCDIC
` type more convenient.
`
` The sender converts the data from his internal character
` representation to the standard 8-bit NVT-ASCII
` representation (see the TELNET specification). The receiver
` will convert the data from the standard form to his own
` internal form.
`
` In accordance with the NVT standard, the <CRLF> sequence
` should be used, where necessary, to denote the end of a line
` of text. (See the discussion of file structure at the end
` of the Section on Data Representation and Storage).
`
` Using the standard NVT-ASCII representation means that data
` must be interpreted as 8-bit bytes.
`
` The Format parameter for ASCII and EBCDIC types is discussed
` below.
`
` EBCDIC Format
`
` This type is intended for efficient transfer between Hosts
` which use EBCDIC for their internal character
` representation.
`
` For transmission the data are represented as 8-bit EBCDIC
` characters. The character code is the only difference
` between the functional specifications of EBCDIC and ASCII
` types.
`
` End-of-line (as opposed to end-of-record--see the discussion
` of structure) will probably be rarely used with EBCDIC type
` for purposes of denoting structure, but where it is
` necessary the <NL> character should be used.
`
` 9
`
`NOAC Ex. 1040 Page 9
`
`

`

`
`June 1980 IEN 149
`File Transfer Protocol RFC 765
`
` A character file may be transferred to a Host for one of three
` purposes: for printing, for storage and later retrieval, or for
` processing. If a file is sent for printing, the receiving Host
` must know how the vertical format control is represented. In the
` second case, it must be possible to store a file at a Host and
` then retrieve it later in exactly the same form. Finally, it
` ought to be possible to move a file from one Host to another and
` process the file at the second Host without undue trouble. A
` single ASCII or EBCDIC format does not satisfy all these
` conditions and so these types have a second parameter specifying
` one of the following three formats:
`
` Non-print
`
` This is the default format to be used if the second (format)
` parameter is omitted. Non-print format must be accepted by
` all FTP implementations.
`
` The file need contain no vertical format information. If it
` is passed to a printer process, this process may assume
` standard values for spacing and margins.
`
` Normally, this format will be used with files destined for
` processing or just storage.
`
` TELNET Format Controls
`
` The file contains ASCII/EBCDIC vertical format controls
` (i.e., <CR>, <LF>, <NL>, <VT>, <FF>) which the printer
` process will interpret appropriately. <CRLF>, in exactly
` this sequence, also denotes end-of-line.
`
` Carriage Control (ASA)
`
` The file contains ASA (FORTRAN) vertical format control
` characters. (See RFC 740 Appendix C and Communications of
` the ACM, Vol. 7, No. 10, 606 (Oct. 1964)). In a line or a
` record, formatted according to the ASA Standard, the first
` character is not to be printed. Instead it should be used
` to determine the vertical movement of the paper which should
` take place before the rest of the record is printed.
`
` 10
`
`NOAC Ex. 1040 Page 10
`
`

`

`
`IEN 149 June 1980
`RFC 765 File Transfer Protocol
`
` The ASA Standard specifies the following control characters:
`
` Character Vertical Spacing
`
` blank Move paper up one line
` 0 Move paper up two lines
` 1 Move paper to top of next page
` + No movement, i.e., overprint
`
` Clearly there must be some way for a printer process to
` distinguish the end of the structural entity. If a file has
` record structure (see below) this is no problem; records
` will be explicitly marked during transfer and storage. If
` the file has no record structure, the <CRLF> end-of-line
` sequence is used to separate printing lines, but these
` format effectors are overridden by the ASA controls.
`
` Image
`
` The data are sent as contiguous bits which, for transfer,
` are packed into the 8-bit transfer bytes. The receiving
` site must store the data as contiguous bits. The structure
` of the storage system might necessitate the padding of the
` file (or of each record, for a record-structured file) to
` some convenient boundary (byte, word or block). This
` padding, which must be all zeros, may occur only at the end
` of the file (or at the end of each record) and there must be
` a way of identifying the padding bits so that they may be
` stripped off if the file is retrieved. The padding
` transformation should be well publicized to enable a user to
` process a file at the storage site.
`
` Image type is intended for the efficient storage and
` retrieval of files and for the transfer of binary data. It
` is recommended that this type be accepted by all FTP
` implementations.
`
` Local byte Byte size
`
` The data is transferred in logical bytes of the size
` specified by the obligatory second parameter, Byte size.
` The value of Byte size must be a decimal integer; there is
` no default value. The logical byte size is not necessarily
` the same as the transfer byte size. If there is a
`
` 11
`
`NOAC Ex. 1040 Page 11
`
`

`

`
`June 1980 IEN 149
`File Transfer Protocol RFC 765
`
` difference in byte sizes, then the logical bytes should be
` packed contiguously, disregarding transfer byte boundaries
` and with any necessary padding at the end.
`
` When the data reaches the receiving Host it will be
` transformed in a manner dependent on the logical byte size
` and the particular Host. This transformation must be
` invertible (that is an identical file can be retrieved if
` the same parameters are used) and should be well publicized
` by the FTP implementors.
`
` For example, a user sending 36-bit floating-point numbers to
` a Host with a 32-bit word could send his data as Local byte
` with a logical byte size of 36. The receiving Host would
` then be expected to store the logical bytes so that they
` could be easily manipulated; in this example putting the
` 36-bit logical bytes into 64-bit double words should
` suffice.
`
` Another example, a pair of hosts with a 36-bit word size may
` send data to one another in words by using TYPE L 36. The
` data would be sent in the 8-bit transmission bytes packed so
` that 9 transmission bytes carried two host words.
`
` A note of caution about parameters: a file must be stored and
` retrieved with the same parameters if the retrieved version is to
` be identical to the version originally transmitted. Conversely,
` FTP implementations must return a file identical to the original
` if the parameters used to store and retrieve a file are the same.
`
` In addition to different representation types, FTP allows the
` structure of a file to be specified. Three file structures are
` defined in FTP:
`
` file-structure, where there is no internal structure and the
` file is considered to be a continuous
` sequence of data bytes,
`
` record-structure, where the file is made up of sequential
` records,
`
` and page-structure, where the file is made up of independent
` indexed pages.
`
` File-structure is the default, to be assumed if the STRUcture
` command has not been used but both file and record structures must
`
` 12
`
`NOAC Ex. 1040 Page 12
`
`

`

`
`IEN 149 June 1980
`RFC 765 File Transfer Protocol
`
` be accepted for "text" files (i.e., files with TYPE ASCII or
` EBCDIC) by all FTP implementations. The structure of a file will
` affect both the transfer mode of a file (see the Section on
` Transmission Modes) and the interpretation and storage of the
` file.
`
` The "natural" structure of a file will depend on which Host stores
` the file. A source-code file will usually be stored on an IBM 360
` in fixed length records but on a PDP-10 as a stream of characters
` partitioned into lines, for example by <CRLF>. If the transfer of
` files between such disparate sites is to be useful, there must be
` some way for one site to recognize the other’s assumptions about
` the file.
`
` With some sites being naturally file-oriented and others naturally
` record-oriented there may be problems if a file with one structure
` is sent to a Host oriented to the other. If a text file is sent
` with record-structure to a Host which is file oriented, then that
` Host should apply an internal transformation to the file based on
` the record structure. Obviously this transformation should be
` useful but it must also be invertible so that an identical file
` may be retrieved using record structure.
`
` In the case of a file being sent with file-structure to a
` record-oriented Host, there exists the question of what criteria
` the Host should use to divide the file into records which can be
` processed locally. If this division is necessary the FTP
` implementation should use the end-of-line sequence, <CRLF> for
` ASCII, or <NL> for EBCDIC text files, as the delimiter. If an FTP
` implementation adopts this technique, it must be prepared to
` reverse the transformation if the file is retrieved with
` file-structure.
`
` Page Structure
`
` To transmit files that are discontinuous FTP defines a page
` structure. Files of this type are sometimes know as "random
` access files" or even as "holey files". In these files there
` is sometimes other information associated with the file as a
` whole (e.g., a file descriptor), or with a section of the file
` (e.g., page access controls), or both. In FTP, the sections of
` the file are called pages.
`
` To provide for various page sizes and associated information
` each page is sent with a page header. The page header has the
` following defined fields:
`
` 13
`
`NOAC Ex. 1040 Page 13
`
`

`

`
`June 1980 IEN 149
`File Transfer Protocol RFC 765
`
` Header Length
`
` The number of logical bytes in the page header including
` this byte. The minimum header length is 4.
`
` Page Index
`
` The logical page number of this section of the file.
` This is not the transmission sequence number of this
` page, but the index used to identify this page of the
` file.
`
` Data Length
`
` The number of logical bytes in the page data. The
` minimum data length is 0.
`
` Page Type
`
` The type of page this is. The following page types are
` defined:
`
` 0 = Last Page
`
` This is used to indicate the end of a paged
` structured transmission. The header length must be
` 4, and the data length must be 0.
`
` 1 = Simple Page
`
` This is the normal type for simple paged files with
` no page level associated control information. The
` header length must be 4.
`
` 2 = Descriptor Page
`
` This type is used to transmit the descriptive
` information for the file as a whole.
`
` 3 = Access Controled Page
`
` This is type includes an additional header field
` for paged files with page level access control
` information. The header length must be 5.
`
` 14
`
`NOAC Ex. 1040 Page 14
`
`

`

`
`IEN 149 June 1980
`RFC 765 File Transfer Protocol
`
` Optional Fields
`
` Further header fields may be used to supply per page
` control information, for example, per page access
` control.
`
` All fields are one logical byte in length. The logical byte
` size is specified by t