1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/netwerk/protocol/ftp/doc/rfc959.txt Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,3933 @@
1.4 +
1.5 +
1.6 +Network Working Group J. Postel
1.7 +Request for Comments: 959 J. Reynolds
1.8 + ISI
1.9 +Obsoletes RFC: 765 (IEN 149) October 1985
1.10 +
1.11 + FILE TRANSFER PROTOCOL (FTP)
1.12 +
1.13 +
1.14 +Status of this Memo
1.15 +
1.16 + This memo is the official specification of the File Transfer
1.17 + Protocol (FTP). Distribution of this memo is unlimited.
1.18 +
1.19 + The following new optional commands are included in this edition of
1.20 + the specification:
1.21 +
1.22 + CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU
1.23 + (Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD
1.24 + (Print Directory), and SYST (System).
1.25 +
1.26 + Note that this specification is compatible with the previous edition.
1.27 +
1.28 +1. INTRODUCTION
1.29 +
1.30 + The objectives of FTP are 1) to promote sharing of files (computer
1.31 + programs and/or data), 2) to encourage indirect or implicit (via
1.32 + programs) use of remote computers, 3) to shield a user from
1.33 + variations in file storage systems among hosts, and 4) to transfer
1.34 + data reliably and efficiently. FTP, though usable directly by a user
1.35 + at a terminal, is designed mainly for use by programs.
1.36 +
1.37 + The attempt in this specification is to satisfy the diverse needs of
1.38 + users of maxi-hosts, mini-hosts, personal workstations, and TACs,
1.39 + with a simple, and easily implemented protocol design.
1.40 +
1.41 + This paper assumes knowledge of the Transmission Control Protocol
1.42 + (TCP) [2] and the Telnet Protocol [3]. These documents are contained
1.43 + in the ARPA-Internet protocol handbook [1].
1.44 +
1.45 +2. OVERVIEW
1.46 +
1.47 + In this section, the history, the terminology, and the FTP model are
1.48 + discussed. The terms defined in this section are only those that
1.49 + have special significance in FTP. Some of the terminology is very
1.50 + specific to the FTP model; some readers may wish to turn to the
1.51 + section on the FTP model while reviewing the terminology.
1.52 +
1.53 +
1.54 +
1.55 +
1.56 +
1.57 +
1.58 +
1.59 +Postel & Reynolds [Page 1]
1.60 +
1.61 +
1.62 +
1.63 +RFC 959 October 1985
1.64 +File Transfer Protocol
1.65 +
1.66 +
1.67 + 2.1. HISTORY
1.68 +
1.69 + FTP has had a long evolution over the years. Appendix III is a
1.70 + chronological compilation of Request for Comments documents
1.71 + relating to FTP. These include the first proposed file transfer
1.72 + mechanisms in 1971 that were developed for implementation on hosts
1.73 + at M.I.T. (RFC 114), plus comments and discussion in RFC 141.
1.74 +
1.75 + RFC 172 provided a user-level oriented protocol for file transfer
1.76 + between host computers (including terminal IMPs). A revision of
1.77 + this as RFC 265, restated FTP for additional review, while RFC 281
1.78 + suggested further changes. The use of a "Set Data Type"
1.79 + transaction was proposed in RFC 294 in January 1982.
1.80 +
1.81 + RFC 354 obsoleted RFCs 264 and 265. The File Transfer Protocol
1.82 + was now defined as a protocol for file transfer between HOSTs on
1.83 + the ARPANET, with the primary function of FTP defined as
1.84 + transfering files efficiently and reliably among hosts and
1.85 + allowing the convenient use of remote file storage capabilities.
1.86 + RFC 385 further commented on errors, emphasis points, and
1.87 + additions to the protocol, while RFC 414 provided a status report
1.88 + on the working server and user FTPs. RFC 430, issued in 1973,
1.89 + (among other RFCs too numerous to mention) presented further
1.90 + comments on FTP. Finally, an "official" FTP document was
1.91 + published as RFC 454.
1.92 +
1.93 + By July 1973, considerable changes from the last versions of FTP
1.94 + were made, but the general structure remained the same. RFC 542
1.95 + was published as a new "official" specification to reflect these
1.96 + changes. However, many implementations based on the older
1.97 + specification were not updated.
1.98 +
1.99 + In 1974, RFCs 607 and 614 continued comments on FTP. RFC 624
1.100 + proposed further design changes and minor modifications. In 1975,
1.101 + RFC 686 entitled, "Leaving Well Enough Alone", discussed the
1.102 + differences between all of the early and later versions of FTP.
1.103 + RFC 691 presented a minor revision of RFC 686, regarding the
1.104 + subject of print files.
1.105 +
1.106 + Motivated by the transition from the NCP to the TCP as the
1.107 + underlying protocol, a phoenix was born out of all of the above
1.108 + efforts in RFC 765 as the specification of FTP for use on TCP.
1.109 +
1.110 + This current edition of the FTP specification is intended to
1.111 + correct some minor documentation errors, to improve the
1.112 + explanation of some protocol features, and to add some new
1.113 + optional commands.
1.114 +
1.115 +
1.116 +Postel & Reynolds [Page 2]
1.117 +
1.118 +
1.119 +
1.120 +RFC 959 October 1985
1.121 +File Transfer Protocol
1.122 +
1.123 +
1.124 + In particular, the following new optional commands are included in
1.125 + this edition of the specification:
1.126 +
1.127 + CDUP - Change to Parent Directory
1.128 +
1.129 + SMNT - Structure Mount
1.130 +
1.131 + STOU - Store Unique
1.132 +
1.133 + RMD - Remove Directory
1.134 +
1.135 + MKD - Make Directory
1.136 +
1.137 + PWD - Print Directory
1.138 +
1.139 + SYST - System
1.140 +
1.141 + This specification is compatible with the previous edition. A
1.142 + program implemented in conformance to the previous specification
1.143 + should automatically be in conformance to this specification.
1.144 +
1.145 + 2.2. TERMINOLOGY
1.146 +
1.147 + ASCII
1.148 +
1.149 + The ASCII character set is as defined in the ARPA-Internet
1.150 + Protocol Handbook. In FTP, ASCII characters are defined to be
1.151 + the lower half of an eight-bit code set (i.e., the most
1.152 + significant bit is zero).
1.153 +
1.154 + access controls
1.155 +
1.156 + Access controls define users' access privileges to the use of a
1.157 + system, and to the files in that system. Access controls are
1.158 + necessary to prevent unauthorized or accidental use of files.
1.159 + It is the prerogative of a server-FTP process to invoke access
1.160 + controls.
1.161 +
1.162 + byte size
1.163 +
1.164 + There are two byte sizes of interest in FTP: the logical byte
1.165 + size of the file, and the transfer byte size used for the
1.166 + transmission of the data. The transfer byte size is always 8
1.167 + bits. The transfer byte size is not necessarily the byte size
1.168 + in which data is to be stored in a system, nor the logical byte
1.169 + size for interpretation of the structure of the data.
1.170 +
1.171 +
1.172 +
1.173 +Postel & Reynolds [Page 3]
1.174 +
1.175 +
1.176 +
1.177 +RFC 959 October 1985
1.178 +File Transfer Protocol
1.179 +
1.180 +
1.181 + control connection
1.182 +
1.183 + The communication path between the USER-PI and SERVER-PI for
1.184 + the exchange of commands and replies. This connection follows
1.185 + the Telnet Protocol.
1.186 +
1.187 + data connection
1.188 +
1.189 + A full duplex connection over which data is transferred, in a
1.190 + specified mode and type. The data transferred may be a part of
1.191 + a file, an entire file or a number of files. The path may be
1.192 + between a server-DTP and a user-DTP, or between two
1.193 + server-DTPs.
1.194 +
1.195 + data port
1.196 +
1.197 + The passive data transfer process "listens" on the data port
1.198 + for a connection from the active transfer process in order to
1.199 + open the data connection.
1.200 +
1.201 + DTP
1.202 +
1.203 + The data transfer process establishes and manages the data
1.204 + connection. The DTP can be passive or active.
1.205 +
1.206 + End-of-Line
1.207 +
1.208 + The end-of-line sequence defines the separation of printing
1.209 + lines. The sequence is Carriage Return, followed by Line Feed.
1.210 +
1.211 + EOF
1.212 +
1.213 + The end-of-file condition that defines the end of a file being
1.214 + transferred.
1.215 +
1.216 + EOR
1.217 +
1.218 + The end-of-record condition that defines the end of a record
1.219 + being transferred.
1.220 +
1.221 + error recovery
1.222 +
1.223 + A procedure that allows a user to recover from certain errors
1.224 + such as failure of either host system or transfer process. In
1.225 + FTP, error recovery may involve restarting a file transfer at a
1.226 + given checkpoint.
1.227 +
1.228 +
1.229 +
1.230 +Postel & Reynolds [Page 4]
1.231 +
1.232 +
1.233 +
1.234 +RFC 959 October 1985
1.235 +File Transfer Protocol
1.236 +
1.237 +
1.238 + FTP commands
1.239 +
1.240 + A set of commands that comprise the control information flowing
1.241 + from the user-FTP to the server-FTP process.
1.242 +
1.243 + file
1.244 +
1.245 + An ordered set of computer data (including programs), of
1.246 + arbitrary length, uniquely identified by a pathname.
1.247 +
1.248 + mode
1.249 +
1.250 + The mode in which data is to be transferred via the data
1.251 + connection. The mode defines the data format during transfer
1.252 + including EOR and EOF. The transfer modes defined in FTP are
1.253 + described in the Section on Transmission Modes.
1.254 +
1.255 + NVT
1.256 +
1.257 + The Network Virtual Terminal as defined in the Telnet Protocol.
1.258 +
1.259 + NVFS
1.260 +
1.261 + The Network Virtual File System. A concept which defines a
1.262 + standard network file system with standard commands and
1.263 + pathname conventions.
1.264 +
1.265 + page
1.266 +
1.267 + A file may be structured as a set of independent parts called
1.268 + pages. FTP supports the transmission of discontinuous files as
1.269 + independent indexed pages.
1.270 +
1.271 + pathname
1.272 +
1.273 + Pathname is defined to be the character string which must be
1.274 + input to a file system by a user in order to identify a file.
1.275 + Pathname normally contains device and/or directory names, and
1.276 + file name specification. FTP does not yet specify a standard
1.277 + pathname convention. Each user must follow the file naming
1.278 + conventions of the file systems involved in the transfer.
1.279 +
1.280 + PI
1.281 +
1.282 + The protocol interpreter. The user and server sides of the
1.283 + protocol have distinct roles implemented in a user-PI and a
1.284 + server-PI.
1.285 +
1.286 +
1.287 +Postel & Reynolds [Page 5]
1.288 +
1.289 +
1.290 +
1.291 +RFC 959 October 1985
1.292 +File Transfer Protocol
1.293 +
1.294 +
1.295 + record
1.296 +
1.297 + A sequential file may be structured as a number of contiguous
1.298 + parts called records. Record structures are supported by FTP
1.299 + but a file need not have record structure.
1.300 +
1.301 + reply
1.302 +
1.303 + A reply is an acknowledgment (positive or negative) sent from
1.304 + server to user via the control connection in response to FTP
1.305 + commands. The general form of a reply is a completion code
1.306 + (including error codes) followed by a text string. The codes
1.307 + are for use by programs and the text is usually intended for
1.308 + human users.
1.309 +
1.310 + server-DTP
1.311 +
1.312 + The data transfer process, in its normal "active" state,
1.313 + establishes the data connection with the "listening" data port.
1.314 + It sets up parameters for transfer and storage, and transfers
1.315 + data on command from its PI. The DTP can be placed in a
1.316 + "passive" state to listen for, rather than initiate a
1.317 + connection on the data port.
1.318 +
1.319 + server-FTP process
1.320 +
1.321 + A process or set of processes which perform the function of
1.322 + file transfer in cooperation with a user-FTP process and,
1.323 + possibly, another server. The functions consist of a protocol
1.324 + interpreter (PI) and a data transfer process (DTP).
1.325 +
1.326 + server-PI
1.327 +
1.328 + The server protocol interpreter "listens" on Port L for a
1.329 + connection from a user-PI and establishes a control
1.330 + communication connection. It receives standard FTP commands
1.331 + from the user-PI, sends replies, and governs the server-DTP.
1.332 +
1.333 + type
1.334 +
1.335 + The data representation type used for data transfer and
1.336 + storage. Type implies certain transformations between the time
1.337 + of data storage and data transfer. The representation types
1.338 + defined in FTP are described in the Section on Establishing
1.339 + Data Connections.
1.340 +
1.341 +
1.342 +
1.343 +
1.344 +Postel & Reynolds [Page 6]
1.345 +
1.346 +
1.347 +
1.348 +RFC 959 October 1985
1.349 +File Transfer Protocol
1.350 +
1.351 +
1.352 + user
1.353 +
1.354 + A person or a process on behalf of a person wishing to obtain
1.355 + file transfer service. The human user may interact directly
1.356 + with a server-FTP process, but use of a user-FTP process is
1.357 + preferred since the protocol design is weighted towards
1.358 + automata.
1.359 +
1.360 + user-DTP
1.361 +
1.362 + The data transfer process "listens" on the data port for a
1.363 + connection from a server-FTP process. If two servers are
1.364 + transferring data between them, the user-DTP is inactive.
1.365 +
1.366 + user-FTP process
1.367 +
1.368 + A set of functions including a protocol interpreter, a data
1.369 + transfer process and a user interface which together perform
1.370 + the function of file transfer in cooperation with one or more
1.371 + server-FTP processes. The user interface allows a local
1.372 + language to be used in the command-reply dialogue with the
1.373 + user.
1.374 +
1.375 + user-PI
1.376 +
1.377 + The user protocol interpreter initiates the control connection
1.378 + from its port U to the server-FTP process, initiates FTP
1.379 + commands, and governs the user-DTP if that process is part of
1.380 + the file transfer.
1.381 +
1.382 +
1.383 +
1.384 +
1.385 +
1.386 +
1.387 +
1.388 +
1.389 +
1.390 +
1.391 +
1.392 +
1.393 +
1.394 +
1.395 +
1.396 +
1.397 +
1.398 +
1.399 +
1.400 +
1.401 +Postel & Reynolds [Page 7]
1.402 +
1.403 +
1.404 +
1.405 +RFC 959 October 1985
1.406 +File Transfer Protocol
1.407 +
1.408 +
1.409 + 2.3. THE FTP MODEL
1.410 +
1.411 + With the above definitions in mind, the following model (shown in
1.412 + Figure 1) may be diagrammed for an FTP service.
1.413 +
1.414 + -------------
1.415 + |/---------\|
1.416 + || User || --------
1.417 + ||Interface|<--->| User |
1.418 + |\----^----/| --------
1.419 + ---------- | | |
1.420 + |/------\| FTP Commands |/----V----\|
1.421 + ||Server|<---------------->| User ||
1.422 + || PI || FTP Replies || PI ||
1.423 + |\--^---/| |\----^----/|
1.424 + | | | | | |
1.425 + -------- |/--V---\| Data |/----V----\| --------
1.426 + | File |<--->|Server|<---------------->| User |<--->| File |
1.427 + |System| || DTP || Connection || DTP || |System|
1.428 + -------- |\------/| |\---------/| --------
1.429 + ---------- -------------
1.430 +
1.431 + Server-FTP USER-FTP
1.432 +
1.433 + NOTES: 1. The data connection may be used in either direction.
1.434 + 2. The data connection need not exist all of the time.
1.435 +
1.436 + Figure 1 Model for FTP Use
1.437 +
1.438 + In the model described in Figure 1, the user-protocol interpreter
1.439 + initiates the control connection. The control connection follows
1.440 + the Telnet protocol. At the initiation of the user, standard FTP
1.441 + commands are generated by the user-PI and transmitted to the
1.442 + server process via the control connection. (The user may
1.443 + establish a direct control connection to the server-FTP, from a
1.444 + TAC terminal for example, and generate standard FTP commands
1.445 + independently, bypassing the user-FTP process.) Standard replies
1.446 + are sent from the server-PI to the user-PI over the control
1.447 + connection in response to the commands.
1.448 +
1.449 + The FTP commands specify the parameters for the data connection
1.450 + (data port, transfer mode, representation type, and structure) and
1.451 + the nature of file system operation (store, retrieve, append,
1.452 + delete, etc.). The user-DTP or its designate should "listen" on
1.453 + the specified data port, and the server initiate the data
1.454 + connection and data transfer in accordance with the specified
1.455 + parameters. It should be noted that the data port need not be in
1.456 +
1.457 +
1.458 +Postel & Reynolds [Page 8]
1.459 +
1.460 +
1.461 +
1.462 +RFC 959 October 1985
1.463 +File Transfer Protocol
1.464 +
1.465 +
1.466 + the same host that initiates the FTP commands via the control
1.467 + connection, but the user or the user-FTP process must ensure a
1.468 + "listen" on the specified data port. It ought to also be noted
1.469 + that the data connection may be used for simultaneous sending and
1.470 + receiving.
1.471 +
1.472 + In another situation a user might wish to transfer files between
1.473 + two hosts, neither of which is a local host. The user sets up
1.474 + control connections to the two servers and then arranges for a
1.475 + data connection between them. In this manner, control information
1.476 + is passed to the user-PI but data is transferred between the
1.477 + server data transfer processes. Following is a model of this
1.478 + server-server interaction.
1.479 +
1.480 +
1.481 + Control ------------ Control
1.482 + ---------->| User-FTP |<-----------
1.483 + | | User-PI | |
1.484 + | | "C" | |
1.485 + V ------------ V
1.486 + -------------- --------------
1.487 + | Server-FTP | Data Connection | Server-FTP |
1.488 + | "A" |<---------------------->| "B" |
1.489 + -------------- Port (A) Port (B) --------------
1.490 +
1.491 +
1.492 + Figure 2
1.493 +
1.494 + The protocol requires that the control connections be open while
1.495 + data transfer is in progress. It is the responsibility of the
1.496 + user to request the closing of the control connections when
1.497 + finished using the FTP service, while it is the server who takes
1.498 + the action. The server may abort data transfer if the control
1.499 + connections are closed without command.
1.500 +
1.501 + The Relationship between FTP and Telnet:
1.502 +
1.503 + The FTP uses the Telnet protocol on the control connection.
1.504 + This can be achieved in two ways: first, the user-PI or the
1.505 + server-PI may implement the rules of the Telnet Protocol
1.506 + directly in their own procedures; or, second, the user-PI or
1.507 + the server-PI may make use of the existing Telnet module in the
1.508 + system.
1.509 +
1.510 + Ease of implementaion, sharing code, and modular programming
1.511 + argue for the second approach. Efficiency and independence
1.512 +
1.513 +
1.514 +
1.515 +Postel & Reynolds [Page 9]
1.516 +
1.517 +
1.518 +
1.519 +RFC 959 October 1985
1.520 +File Transfer Protocol
1.521 +
1.522 +
1.523 + argue for the first approach. In practice, FTP relies on very
1.524 + little of the Telnet Protocol, so the first approach does not
1.525 + necessarily involve a large amount of code.
1.526 +
1.527 +3. DATA TRANSFER FUNCTIONS
1.528 +
1.529 + Files are transferred only via the data connection. The control
1.530 + connection is used for the transfer of commands, which describe the
1.531 + functions to be performed, and the replies to these commands (see the
1.532 + Section on FTP Replies). Several commands are concerned with the
1.533 + transfer of data between hosts. These data transfer commands include
1.534 + the MODE command which specify how the bits of the data are to be
1.535 + transmitted, and the STRUcture and TYPE commands, which are used to
1.536 + define the way in which the data are to be represented. The
1.537 + transmission and representation are basically independent but the
1.538 + "Stream" transmission mode is dependent on the file structure
1.539 + attribute and if "Compressed" transmission mode is used, the nature
1.540 + of the filler byte depends on the representation type.
1.541 +
1.542 + 3.1. DATA REPRESENTATION AND STORAGE
1.543 +
1.544 + Data is transferred from a storage device in the sending host to a
1.545 + storage device in the receiving host. Often it is necessary to
1.546 + perform certain transformations on the data because data storage
1.547 + representations in the two systems are different. For example,
1.548 + NVT-ASCII has different data storage representations in different
1.549 + systems. DEC TOPS-20s's generally store NVT-ASCII as five 7-bit
1.550 + ASCII characters, left-justified in a 36-bit word. IBM Mainframe's
1.551 + store NVT-ASCII as 8-bit EBCDIC codes. Multics stores NVT-ASCII
1.552 + as four 9-bit characters in a 36-bit word. It is desirable to
1.553 + convert characters into the standard NVT-ASCII representation when
1.554 + transmitting text between dissimilar systems. The sending and
1.555 + receiving sites would have to perform the necessary
1.556 + transformations between the standard representation and their
1.557 + internal representations.
1.558 +
1.559 + A different problem in representation arises when transmitting
1.560 + binary data (not character codes) between host systems with
1.561 + different word lengths. It is not always clear how the sender
1.562 + should send data, and the receiver store it. For example, when
1.563 + transmitting 32-bit bytes from a 32-bit word-length system to a
1.564 + 36-bit word-length system, it may be desirable (for reasons of
1.565 + efficiency and usefulness) to store the 32-bit bytes
1.566 + right-justified in a 36-bit word in the latter system. In any
1.567 + case, the user should have the option of specifying data
1.568 + representation and transformation functions. It should be noted
1.569 +
1.570 +
1.571 +
1.572 +Postel & Reynolds [Page 10]
1.573 +
1.574 +
1.575 +
1.576 +RFC 959 October 1985
1.577 +File Transfer Protocol
1.578 +
1.579 +
1.580 + that FTP provides for very limited data type representations.
1.581 + Transformations desired beyond this limited capability should be
1.582 + performed by the user directly.
1.583 +
1.584 + 3.1.1. DATA TYPES
1.585 +
1.586 + Data representations are handled in FTP by a user specifying a
1.587 + representation type. This type may implicitly (as in ASCII or
1.588 + EBCDIC) or explicitly (as in Local byte) define a byte size for
1.589 + interpretation which is referred to as the "logical byte size."
1.590 + Note that this has nothing to do with the byte size used for
1.591 + transmission over the data connection, called the "transfer
1.592 + byte size", and the two should not be confused. For example,
1.593 + NVT-ASCII has a logical byte size of 8 bits. If the type is
1.594 + Local byte, then the TYPE command has an obligatory second
1.595 + parameter specifying the logical byte size. The transfer byte
1.596 + size is always 8 bits.
1.597 +
1.598 + 3.1.1.1. ASCII TYPE
1.599 +
1.600 + This is the default type and must be accepted by all FTP
1.601 + implementations. It is intended primarily for the transfer
1.602 + of text files, except when both hosts would find the EBCDIC
1.603 + type more convenient.
1.604 +
1.605 + The sender converts the data from an internal character
1.606 + representation to the standard 8-bit NVT-ASCII
1.607 + representation (see the Telnet specification). The receiver
1.608 + will convert the data from the standard form to his own
1.609 + internal form.
1.610 +
1.611 + In accordance with the NVT standard, the <CRLF> sequence
1.612 + should be used where necessary to denote the end of a line
1.613 + of text. (See the discussion of file structure at the end
1.614 + of the Section on Data Representation and Storage.)
1.615 +
1.616 + Using the standard NVT-ASCII representation means that data
1.617 + must be interpreted as 8-bit bytes.
1.618 +
1.619 + The Format parameter for ASCII and EBCDIC types is discussed
1.620 + below.
1.621 +
1.622 +
1.623 +
1.624 +
1.625 +
1.626 +
1.627 +
1.628 +
1.629 +Postel & Reynolds [Page 11]
1.630 +
1.631 +
1.632 +
1.633 +RFC 959 October 1985
1.634 +File Transfer Protocol
1.635 +
1.636 +
1.637 + 3.1.1.2. EBCDIC TYPE
1.638 +
1.639 + This type is intended for efficient transfer between hosts
1.640 + which use EBCDIC for their internal character
1.641 + representation.
1.642 +
1.643 + For transmission, the data are represented as 8-bit EBCDIC
1.644 + characters. The character code is the only difference
1.645 + between the functional specifications of EBCDIC and ASCII
1.646 + types.
1.647 +
1.648 + End-of-line (as opposed to end-of-record--see the discussion
1.649 + of structure) will probably be rarely used with EBCDIC type
1.650 + for purposes of denoting structure, but where it is
1.651 + necessary the <NL> character should be used.
1.652 +
1.653 + 3.1.1.3. IMAGE TYPE
1.654 +
1.655 + The data are sent as contiguous bits which, for transfer,
1.656 + are packed into the 8-bit transfer bytes. The receiving
1.657 + site must store the data as contiguous bits. The structure
1.658 + of the storage system might necessitate the padding of the
1.659 + file (or of each record, for a record-structured file) to
1.660 + some convenient boundary (byte, word or block). This
1.661 + padding, which must be all zeros, may occur only at the end
1.662 + of the file (or at the end of each record) and there must be
1.663 + a way of identifying the padding bits so that they may be
1.664 + stripped off if the file is retrieved. The padding
1.665 + transformation should be well publicized to enable a user to
1.666 + process a file at the storage site.
1.667 +
1.668 + Image type is intended for the efficient storage and
1.669 + retrieval of files and for the transfer of binary data. It
1.670 + is recommended that this type be accepted by all FTP
1.671 + implementations.
1.672 +
1.673 + 3.1.1.4. LOCAL TYPE
1.674 +
1.675 + The data is transferred in logical bytes of the size
1.676 + specified by the obligatory second parameter, Byte size.
1.677 + The value of Byte size must be a decimal integer; there is
1.678 + no default value. The logical byte size is not necessarily
1.679 + the same as the transfer byte size. If there is a
1.680 + difference in byte sizes, then the logical bytes should be
1.681 + packed contiguously, disregarding transfer byte boundaries
1.682 + and with any necessary padding at the end.
1.683 +
1.684 +
1.685 +
1.686 +Postel & Reynolds [Page 12]
1.687 +
1.688 +
1.689 +
1.690 +RFC 959 October 1985
1.691 +File Transfer Protocol
1.692 +
1.693 +
1.694 + When the data reaches the receiving host, it will be
1.695 + transformed in a manner dependent on the logical byte size
1.696 + and the particular host. This transformation must be
1.697 + invertible (i.e., an identical file can be retrieved if the
1.698 + same parameters are used) and should be well publicized by
1.699 + the FTP implementors.
1.700 +
1.701 + For example, a user sending 36-bit floating-point numbers to
1.702 + a host with a 32-bit word could send that data as Local byte
1.703 + with a logical byte size of 36. The receiving host would
1.704 + then be expected to store the logical bytes so that they
1.705 + could be easily manipulated; in this example putting the
1.706 + 36-bit logical bytes into 64-bit double words should
1.707 + suffice.
1.708 +
1.709 + In another example, a pair of hosts with a 36-bit word size
1.710 + may send data to one another in words by using TYPE L 36.
1.711 + The data would be sent in the 8-bit transmission bytes
1.712 + packed so that 9 transmission bytes carried two host words.
1.713 +
1.714 + 3.1.1.5. FORMAT CONTROL
1.715 +
1.716 + The types ASCII and EBCDIC also take a second (optional)
1.717 + parameter; this is to indicate what kind of vertical format
1.718 + control, if any, is associated with a file. The following
1.719 + data representation types are defined in FTP:
1.720 +
1.721 + A character file may be transferred to a host for one of
1.722 + three purposes: for printing, for storage and later
1.723 + retrieval, or for processing. If a file is sent for
1.724 + printing, the receiving host must know how the vertical
1.725 + format control is represented. In the second case, it must
1.726 + be possible to store a file at a host and then retrieve it
1.727 + later in exactly the same form. Finally, it should be
1.728 + possible to move a file from one host to another and process
1.729 + the file at the second host without undue trouble. A single
1.730 + ASCII or EBCDIC format does not satisfy all these
1.731 + conditions. Therefore, these types have a second parameter
1.732 + specifying one of the following three formats:
1.733 +
1.734 + 3.1.1.5.1. NON PRINT
1.735 +
1.736 + This is the default format to be used if the second
1.737 + (format) parameter is omitted. Non-print format must be
1.738 + accepted by all FTP implementations.
1.739 +
1.740 +
1.741 +
1.742 +
1.743 +Postel & Reynolds [Page 13]
1.744 +
1.745 +
1.746 +
1.747 +RFC 959 October 1985
1.748 +File Transfer Protocol
1.749 +
1.750 +
1.751 + The file need contain no vertical format information. If
1.752 + it is passed to a printer process, this process may
1.753 + assume standard values for spacing and margins.
1.754 +
1.755 + Normally, this format will be used with files destined
1.756 + for processing or just storage.
1.757 +
1.758 + 3.1.1.5.2. TELNET FORMAT CONTROLS
1.759 +
1.760 + The file contains ASCII/EBCDIC vertical format controls
1.761 + (i.e., <CR>, <LF>, <NL>, <VT>, <FF>) which the printer
1.762 + process will interpret appropriately. <CRLF>, in exactly
1.763 + this sequence, also denotes end-of-line.
1.764 +
1.765 + 3.1.1.5.2. CARRIAGE CONTROL (ASA)
1.766 +
1.767 + The file contains ASA (FORTRAN) vertical format control
1.768 + characters. (See RFC 740 Appendix C; and Communications
1.769 + of the ACM, Vol. 7, No. 10, p. 606, October 1964.) In a
1.770 + line or a record formatted according to the ASA Standard,
1.771 + the first character is not to be printed. Instead, it
1.772 + should be used to determine the vertical movement of the
1.773 + paper which should take place before the rest of the
1.774 + record is printed.
1.775 +
1.776 + The ASA Standard specifies the following control
1.777 + characters:
1.778 +
1.779 + Character Vertical Spacing
1.780 +
1.781 + blank Move paper up one line
1.782 + 0 Move paper up two lines
1.783 + 1 Move paper to top of next page
1.784 + + No movement, i.e., overprint
1.785 +
1.786 + Clearly there must be some way for a printer process to
1.787 + distinguish the end of the structural entity. If a file
1.788 + has record structure (see below) this is no problem;
1.789 + records will be explicitly marked during transfer and
1.790 + storage. If the file has no record structure, the <CRLF>
1.791 + end-of-line sequence is used to separate printing lines,
1.792 + but these format effectors are overridden by the ASA
1.793 + controls.
1.794 +
1.795 +
1.796 +
1.797 +
1.798 +
1.799 +
1.800 +Postel & Reynolds [Page 14]
1.801 +
1.802 +
1.803 +
1.804 +RFC 959 October 1985
1.805 +File Transfer Protocol
1.806 +
1.807 +
1.808 + 3.1.2. DATA STRUCTURES
1.809 +
1.810 + In addition to different representation types, FTP allows the
1.811 + structure of a file to be specified. Three file structures are
1.812 + defined in FTP:
1.813 +
1.814 + file-structure, where there is no internal structure and
1.815 + the file is considered to be a
1.816 + continuous sequence of data bytes,
1.817 +
1.818 + record-structure, where the file is made up of sequential
1.819 + records,
1.820 +
1.821 + and page-structure, where the file is made up of independent
1.822 + indexed pages.
1.823 +
1.824 + File-structure is the default to be assumed if the STRUcture
1.825 + command has not been used but both file and record structures
1.826 + must be accepted for "text" files (i.e., files with TYPE ASCII
1.827 + or EBCDIC) by all FTP implementations. The structure of a file
1.828 + will affect both the transfer mode of a file (see the Section
1.829 + on Transmission Modes) and the interpretation and storage of
1.830 + the file.
1.831 +
1.832 + The "natural" structure of a file will depend on which host
1.833 + stores the file. A source-code file will usually be stored on
1.834 + an IBM Mainframe in fixed length records but on a DEC TOPS-20
1.835 + as a stream of characters partitioned into lines, for example
1.836 + by <CRLF>. If the transfer of files between such disparate
1.837 + sites is to be useful, there must be some way for one site to
1.838 + recognize the other's assumptions about the file.
1.839 +
1.840 + With some sites being naturally file-oriented and others
1.841 + naturally record-oriented there may be problems if a file with
1.842 + one structure is sent to a host oriented to the other. If a
1.843 + text file is sent with record-structure to a host which is file
1.844 + oriented, then that host should apply an internal
1.845 + transformation to the file based on the record structure.
1.846 + Obviously, this transformation should be useful, but it must
1.847 + also be invertible so that an identical file may be retrieved
1.848 + using record structure.
1.849 +
1.850 + In the case of a file being sent with file-structure to a
1.851 + record-oriented host, there exists the question of what
1.852 + criteria the host should use to divide the file into records
1.853 + which can be processed locally. If this division is necessary,
1.854 + the FTP implementation should use the end-of-line sequence,
1.855 +
1.856 +
1.857 +Postel & Reynolds [Page 15]
1.858 +
1.859 +
1.860 +
1.861 +RFC 959 October 1985
1.862 +File Transfer Protocol
1.863 +
1.864 +
1.865 + <CRLF> for ASCII, or <NL> for EBCDIC text files, as the
1.866 + delimiter. If an FTP implementation adopts this technique, it
1.867 + must be prepared to reverse the transformation if the file is
1.868 + retrieved with file-structure.
1.869 +
1.870 + 3.1.2.1. FILE STRUCTURE
1.871 +
1.872 + File structure is the default to be assumed if the STRUcture
1.873 + command has not been used.
1.874 +
1.875 + In file-structure there is no internal structure and the
1.876 + file is considered to be a continuous sequence of data
1.877 + bytes.
1.878 +
1.879 + 3.1.2.2. RECORD STRUCTURE
1.880 +
1.881 + Record structures must be accepted for "text" files (i.e.,
1.882 + files with TYPE ASCII or EBCDIC) by all FTP implementations.
1.883 +
1.884 + In record-structure the file is made up of sequential
1.885 + records.
1.886 +
1.887 + 3.1.2.3. PAGE STRUCTURE
1.888 +
1.889 + To transmit files that are discontinuous, FTP defines a page
1.890 + structure. Files of this type are sometimes known as
1.891 + "random access files" or even as "holey files". In these
1.892 + files there is sometimes other information associated with
1.893 + the file as a whole (e.g., a file descriptor), or with a
1.894 + section of the file (e.g., page access controls), or both.
1.895 + In FTP, the sections of the file are called pages.
1.896 +
1.897 + To provide for various page sizes and associated
1.898 + information, each page is sent with a page header. The page
1.899 + header has the following defined fields:
1.900 +
1.901 + Header Length
1.902 +
1.903 + The number of logical bytes in the page header
1.904 + including this byte. The minimum header length is 4.
1.905 +
1.906 + Page Index
1.907 +
1.908 + The logical page number of this section of the file.
1.909 + This is not the transmission sequence number of this
1.910 + page, but the index used to identify this page of the
1.911 + file.
1.912 +
1.913 +
1.914 +Postel & Reynolds [Page 16]
1.915 +
1.916 +
1.917 +
1.918 +RFC 959 October 1985
1.919 +File Transfer Protocol
1.920 +
1.921 +
1.922 + Data Length
1.923 +
1.924 + The number of logical bytes in the page data. The
1.925 + minimum data length is 0.
1.926 +
1.927 + Page Type
1.928 +
1.929 + The type of page this is. The following page types
1.930 + are defined:
1.931 +
1.932 + 0 = Last Page
1.933 +
1.934 + This is used to indicate the end of a paged
1.935 + structured transmission. The header length must
1.936 + be 4, and the data length must be 0.
1.937 +
1.938 + 1 = Simple Page
1.939 +
1.940 + This is the normal type for simple paged files
1.941 + with no page level associated control
1.942 + information. The header length must be 4.
1.943 +
1.944 + 2 = Descriptor Page
1.945 +
1.946 + This type is used to transmit the descriptive
1.947 + information for the file as a whole.
1.948 +
1.949 + 3 = Access Controlled Page
1.950 +
1.951 + This type includes an additional header field
1.952 + for paged files with page level access control
1.953 + information. The header length must be 5.
1.954 +
1.955 + Optional Fields
1.956 +
1.957 + Further header fields may be used to supply per page
1.958 + control information, for example, per page access
1.959 + control.
1.960 +
1.961 + All fields are one logical byte in length. The logical byte
1.962 + size is specified by the TYPE command. See Appendix I for
1.963 + further details and a specific case at the page structure.
1.964 +
1.965 + A note of caution about parameters: a file must be stored and
1.966 + retrieved with the same parameters if the retrieved version is to
1.967 +
1.968 +
1.969 +
1.970 +
1.971 +Postel & Reynolds [Page 17]
1.972 +
1.973 +
1.974 +
1.975 +RFC 959 October 1985
1.976 +File Transfer Protocol
1.977 +
1.978 +
1.979 + be identical to the version originally transmitted. Conversely,
1.980 + FTP implementations must return a file identical to the original
1.981 + if the parameters used to store and retrieve a file are the same.
1.982 +
1.983 + 3.2. ESTABLISHING DATA CONNECTIONS
1.984 +
1.985 + The mechanics of transferring data consists of setting up the data
1.986 + connection to the appropriate ports and choosing the parameters
1.987 + for transfer. Both the user and the server-DTPs have a default
1.988 + data port. The user-process default data port is the same as the
1.989 + control connection port (i.e., U). The server-process default
1.990 + data port is the port adjacent to the control connection port
1.991 + (i.e., L-1).
1.992 +
1.993 + The transfer byte size is 8-bit bytes. This byte size is relevant
1.994 + only for the actual transfer of the data; it has no bearing on
1.995 + representation of the data within a host's file system.
1.996 +
1.997 + The passive data transfer process (this may be a user-DTP or a
1.998 + second server-DTP) shall "listen" on the data port prior to
1.999 + sending a transfer request command. The FTP request command
1.1000 + determines the direction of the data transfer. The server, upon
1.1001 + receiving the transfer request, will initiate the data connection
1.1002 + to the port. When the connection is established, the data
1.1003 + transfer begins between DTP's, and the server-PI sends a
1.1004 + confirming reply to the user-PI.
1.1005 +
1.1006 + Every FTP implementation must support the use of the default data
1.1007 + ports, and only the USER-PI can initiate a change to non-default
1.1008 + ports.
1.1009 +
1.1010 + It is possible for the user to specify an alternate data port by
1.1011 + use of the PORT command. The user may want a file dumped on a TAC
1.1012 + line printer or retrieved from a third party host. In the latter
1.1013 + case, the user-PI sets up control connections with both
1.1014 + server-PI's. One server is then told (by an FTP command) to
1.1015 + "listen" for a connection which the other will initiate. The
1.1016 + user-PI sends one server-PI a PORT command indicating the data
1.1017 + port of the other. Finally, both are sent the appropriate
1.1018 + transfer commands. The exact sequence of commands and replies
1.1019 + sent between the user-controller and the servers is defined in the
1.1020 + Section on FTP Replies.
1.1021 +
1.1022 + In general, it is the server's responsibility to maintain the data
1.1023 + connection--to initiate it and to close it. The exception to this
1.1024 +
1.1025 +
1.1026 +
1.1027 +
1.1028 +Postel & Reynolds [Page 18]
1.1029 +
1.1030 +
1.1031 +
1.1032 +RFC 959 October 1985
1.1033 +File Transfer Protocol
1.1034 +
1.1035 +
1.1036 + is when the user-DTP is sending the data in a transfer mode that
1.1037 + requires the connection to be closed to indicate EOF. The server
1.1038 + MUST close the data connection under the following conditions:
1.1039 +
1.1040 + 1. The server has completed sending data in a transfer mode
1.1041 + that requires a close to indicate EOF.
1.1042 +
1.1043 + 2. The server receives an ABORT command from the user.
1.1044 +
1.1045 + 3. The port specification is changed by a command from the
1.1046 + user.
1.1047 +
1.1048 + 4. The control connection is closed legally or otherwise.
1.1049 +
1.1050 + 5. An irrecoverable error condition occurs.
1.1051 +
1.1052 + Otherwise the close is a server option, the exercise of which the
1.1053 + server must indicate to the user-process by either a 250 or 226
1.1054 + reply only.
1.1055 +
1.1056 + 3.3. DATA CONNECTION MANAGEMENT
1.1057 +
1.1058 + Default Data Connection Ports: All FTP implementations must
1.1059 + support use of the default data connection ports, and only the
1.1060 + User-PI may initiate the use of non-default ports.
1.1061 +
1.1062 + Negotiating Non-Default Data Ports: The User-PI may specify a
1.1063 + non-default user side data port with the PORT command. The
1.1064 + User-PI may request the server side to identify a non-default
1.1065 + server side data port with the PASV command. Since a connection
1.1066 + is defined by the pair of addresses, either of these actions is
1.1067 + enough to get a different data connection, still it is permitted
1.1068 + to do both commands to use new ports on both ends of the data
1.1069 + connection.
1.1070 +
1.1071 + Reuse of the Data Connection: When using the stream mode of data
1.1072 + transfer the end of the file must be indicated by closing the
1.1073 + connection. This causes a problem if multiple files are to be
1.1074 + transfered in the session, due to need for TCP to hold the
1.1075 + connection record for a time out period to guarantee the reliable
1.1076 + communication. Thus the connection can not be reopened at once.
1.1077 +
1.1078 + There are two solutions to this problem. The first is to
1.1079 + negotiate a non-default port. The second is to use another
1.1080 + transfer mode.
1.1081 +
1.1082 + A comment on transfer modes. The stream transfer mode is
1.1083 +
1.1084 +
1.1085 +Postel & Reynolds [Page 19]
1.1086 +
1.1087 +
1.1088 +
1.1089 +RFC 959 October 1985
1.1090 +File Transfer Protocol
1.1091 +
1.1092 +
1.1093 + inherently unreliable, since one can not determine if the
1.1094 + connection closed prematurely or not. The other transfer modes
1.1095 + (Block, Compressed) do not close the connection to indicate the
1.1096 + end of file. They have enough FTP encoding that the data
1.1097 + connection can be parsed to determine the end of the file.
1.1098 + Thus using these modes one can leave the data connection open
1.1099 + for multiple file transfers.
1.1100 +
1.1101 + 3.4. TRANSMISSION MODES
1.1102 +
1.1103 + The next consideration in transferring data is choosing the
1.1104 + appropriate transmission mode. There are three modes: one which
1.1105 + formats the data and allows for restart procedures; one which also
1.1106 + compresses the data for efficient transfer; and one which passes
1.1107 + the data with little or no processing. In this last case the mode
1.1108 + interacts with the structure attribute to determine the type of
1.1109 + processing. In the compressed mode, the representation type
1.1110 + determines the filler byte.
1.1111 +
1.1112 + All data transfers must be completed with an end-of-file (EOF)
1.1113 + which may be explicitly stated or implied by the closing of the
1.1114 + data connection. For files with record structure, all the
1.1115 + end-of-record markers (EOR) are explicit, including the final one.
1.1116 + For files transmitted in page structure a "last-page" page type is
1.1117 + used.
1.1118 +
1.1119 + NOTE: In the rest of this section, byte means "transfer byte"
1.1120 + except where explicitly stated otherwise.
1.1121 +
1.1122 + For the purpose of standardized transfer, the sending host will
1.1123 + translate its internal end of line or end of record denotation
1.1124 + into the representation prescribed by the transfer mode and file
1.1125 + structure, and the receiving host will perform the inverse
1.1126 + translation to its internal denotation. An IBM Mainframe record
1.1127 + count field may not be recognized at another host, so the
1.1128 + end-of-record information may be transferred as a two byte control
1.1129 + code in Stream mode or as a flagged bit in a Block or Compressed
1.1130 + mode descriptor. End-of-line in an ASCII or EBCDIC file with no
1.1131 + record structure should be indicated by <CRLF> or <NL>,
1.1132 + respectively. Since these transformations imply extra work for
1.1133 + some systems, identical systems transferring non-record structured
1.1134 + text files might wish to use a binary representation and stream
1.1135 + mode for the transfer.
1.1136 +
1.1137 +
1.1138 +
1.1139 +
1.1140 +
1.1141 +
1.1142 +Postel & Reynolds [Page 20]
1.1143 +
1.1144 +
1.1145 +
1.1146 +RFC 959 October 1985
1.1147 +File Transfer Protocol
1.1148 +
1.1149 +
1.1150 + The following transmission modes are defined in FTP:
1.1151 +
1.1152 + 3.4.1. STREAM MODE
1.1153 +
1.1154 + The data is transmitted as a stream of bytes. There is no
1.1155 + restriction on the representation type used; record structures
1.1156 + are allowed.
1.1157 +
1.1158 + In a record structured file EOR and EOF will each be indicated
1.1159 + by a two-byte control code. The first byte of the control code
1.1160 + will be all ones, the escape character. The second byte will
1.1161 + have the low order bit on and zeros elsewhere for EOR and the
1.1162 + second low order bit on for EOF; that is, the byte will have
1.1163 + value 1 for EOR and value 2 for EOF. EOR and EOF may be
1.1164 + indicated together on the last byte transmitted by turning both
1.1165 + low order bits on (i.e., the value 3). If a byte of all ones
1.1166 + was intended to be sent as data, it should be repeated in the
1.1167 + second byte of the control code.
1.1168 +
1.1169 + If the structure is a file structure, the EOF is indicated by
1.1170 + the sending host closing the data connection and all bytes are
1.1171 + data bytes.
1.1172 +
1.1173 + 3.4.2. BLOCK MODE
1.1174 +
1.1175 + The file is transmitted as a series of data blocks preceded by
1.1176 + one or more header bytes. The header bytes contain a count
1.1177 + field, and descriptor code. The count field indicates the
1.1178 + total length of the data block in bytes, thus marking the
1.1179 + beginning of the next data block (there are no filler bits).
1.1180 + The descriptor code defines: last block in the file (EOF) last
1.1181 + block in the record (EOR), restart marker (see the Section on
1.1182 + Error Recovery and Restart) or suspect data (i.e., the data
1.1183 + being transferred is suspected of errors and is not reliable).
1.1184 + This last code is NOT intended for error control within FTP.
1.1185 + It is motivated by the desire of sites exchanging certain types
1.1186 + of data (e.g., seismic or weather data) to send and receive all
1.1187 + the data despite local errors (such as "magnetic tape read
1.1188 + errors"), but to indicate in the transmission that certain
1.1189 + portions are suspect). Record structures are allowed in this
1.1190 + mode, and any representation type may be used.
1.1191 +
1.1192 + The header consists of the three bytes. Of the 24 bits of
1.1193 + header information, the 16 low order bits shall represent byte
1.1194 + count, and the 8 high order bits shall represent descriptor
1.1195 + codes as shown below.
1.1196 +
1.1197 +
1.1198 +
1.1199 +Postel & Reynolds [Page 21]
1.1200 +
1.1201 +
1.1202 +
1.1203 +RFC 959 October 1985
1.1204 +File Transfer Protocol
1.1205 +
1.1206 +
1.1207 + Block Header
1.1208 +
1.1209 + +----------------+----------------+----------------+
1.1210 + | Descriptor | Byte Count |
1.1211 + | 8 bits | 16 bits |
1.1212 + +----------------+----------------+----------------+
1.1213 +
1.1214 +
1.1215 + The descriptor codes are indicated by bit flags in the
1.1216 + descriptor byte. Four codes have been assigned, where each
1.1217 + code number is the decimal value of the corresponding bit in
1.1218 + the byte.
1.1219 +
1.1220 + Code Meaning
1.1221 +
1.1222 + 128 End of data block is EOR
1.1223 + 64 End of data block is EOF
1.1224 + 32 Suspected errors in data block
1.1225 + 16 Data block is a restart marker
1.1226 +
1.1227 + With this encoding, more than one descriptor coded condition
1.1228 + may exist for a particular block. As many bits as necessary
1.1229 + may be flagged.
1.1230 +
1.1231 + The restart marker is embedded in the data stream as an
1.1232 + integral number of 8-bit bytes representing printable
1.1233 + characters in the language being used over the control
1.1234 + connection (e.g., default--NVT-ASCII). <SP> (Space, in the
1.1235 + appropriate language) must not be used WITHIN a restart marker.
1.1236 +
1.1237 + For example, to transmit a six-character marker, the following
1.1238 + would be sent:
1.1239 +
1.1240 + +--------+--------+--------+
1.1241 + |Descrptr| Byte count |
1.1242 + |code= 16| = 6 |
1.1243 + +--------+--------+--------+
1.1244 +
1.1245 + +--------+--------+--------+
1.1246 + | Marker | Marker | Marker |
1.1247 + | 8 bits | 8 bits | 8 bits |
1.1248 + +--------+--------+--------+
1.1249 +
1.1250 + +--------+--------+--------+
1.1251 + | Marker | Marker | Marker |
1.1252 + | 8 bits | 8 bits | 8 bits |
1.1253 + +--------+--------+--------+
1.1254 +
1.1255 +
1.1256 +Postel & Reynolds [Page 22]
1.1257 +
1.1258 +
1.1259 +
1.1260 +RFC 959 October 1985
1.1261 +File Transfer Protocol
1.1262 +
1.1263 +
1.1264 + 3.4.3. COMPRESSED MODE
1.1265 +
1.1266 + There are three kinds of information to be sent: regular data,
1.1267 + sent in a byte string; compressed data, consisting of
1.1268 + replications or filler; and control information, sent in a
1.1269 + two-byte escape sequence. If n>0 bytes (up to 127) of regular
1.1270 + data are sent, these n bytes are preceded by a byte with the
1.1271 + left-most bit set to 0 and the right-most 7 bits containing the
1.1272 + number n.
1.1273 +
1.1274 + Byte string:
1.1275 +
1.1276 + 1 7 8 8
1.1277 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
1.1278 + |0| n | | d(1) | ... | d(n) |
1.1279 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
1.1280 + ^ ^
1.1281 + |---n bytes---|
1.1282 + of data
1.1283 +
1.1284 + String of n data bytes d(1),..., d(n)
1.1285 + Count n must be positive.
1.1286 +
1.1287 + To compress a string of n replications of the data byte d, the
1.1288 + following 2 bytes are sent:
1.1289 +
1.1290 + Replicated Byte:
1.1291 +
1.1292 + 2 6 8
1.1293 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
1.1294 + |1 0| n | | d |
1.1295 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
1.1296 +
1.1297 + A string of n filler bytes can be compressed into a single
1.1298 + byte, where the filler byte varies with the representation
1.1299 + type. If the type is ASCII or EBCDIC the filler byte is <SP>
1.1300 + (Space, ASCII code 32, EBCDIC code 64). If the type is Image
1.1301 + or Local byte the filler is a zero byte.
1.1302 +
1.1303 + Filler String:
1.1304 +
1.1305 + 2 6
1.1306 + +-+-+-+-+-+-+-+-+
1.1307 + |1 1| n |
1.1308 + +-+-+-+-+-+-+-+-+
1.1309 +
1.1310 + The escape sequence is a double byte, the first of which is the
1.1311 +
1.1312 +
1.1313 +Postel & Reynolds [Page 23]
1.1314 +
1.1315 +
1.1316 +
1.1317 +RFC 959 October 1985
1.1318 +File Transfer Protocol
1.1319 +
1.1320 +
1.1321 + escape byte (all zeros) and the second of which contains
1.1322 + descriptor codes as defined in Block mode. The descriptor
1.1323 + codes have the same meaning as in Block mode and apply to the
1.1324 + succeeding string of bytes.
1.1325 +
1.1326 + Compressed mode is useful for obtaining increased bandwidth on
1.1327 + very large network transmissions at a little extra CPU cost.
1.1328 + It can be most effectively used to reduce the size of printer
1.1329 + files such as those generated by RJE hosts.
1.1330 +
1.1331 + 3.5. ERROR RECOVERY AND RESTART
1.1332 +
1.1333 + There is no provision for detecting bits lost or scrambled in data
1.1334 + transfer; this level of error control is handled by the TCP.
1.1335 + However, a restart procedure is provided to protect users from
1.1336 + gross system failures (including failures of a host, an
1.1337 + FTP-process, or the underlying network).
1.1338 +
1.1339 + The restart procedure is defined only for the block and compressed
1.1340 + modes of data transfer. It requires the sender of data to insert
1.1341 + a special marker code in the data stream with some marker
1.1342 + information. The marker information has meaning only to the
1.1343 + sender, but must consist of printable characters in the default or
1.1344 + negotiated language of the control connection (ASCII or EBCDIC).
1.1345 + The marker could represent a bit-count, a record-count, or any
1.1346 + other information by which a system may identify a data
1.1347 + checkpoint. The receiver of data, if it implements the restart
1.1348 + procedure, would then mark the corresponding position of this
1.1349 + marker in the receiving system, and return this information to the
1.1350 + user.
1.1351 +
1.1352 + In the event of a system failure, the user can restart the data
1.1353 + transfer by identifying the marker point with the FTP restart
1.1354 + procedure. The following example illustrates the use of the
1.1355 + restart procedure.
1.1356 +
1.1357 + The sender of the data inserts an appropriate marker block in the
1.1358 + data stream at a convenient point. The receiving host marks the
1.1359 + corresponding data point in its file system and conveys the last
1.1360 + known sender and receiver marker information to the user, either
1.1361 + directly or over the control connection in a 110 reply (depending
1.1362 + on who is the sender). In the event of a system failure, the user
1.1363 + or controller process restarts the server at the last server
1.1364 + marker by sending a restart command with server's marker code as
1.1365 + its argument. The restart command is transmitted over the control
1.1366 +
1.1367 +
1.1368 +
1.1369 +
1.1370 +Postel & Reynolds [Page 24]
1.1371 +
1.1372 +
1.1373 +
1.1374 +RFC 959 October 1985
1.1375 +File Transfer Protocol
1.1376 +
1.1377 +
1.1378 + connection and is immediately followed by the command (such as
1.1379 + RETR, STOR or LIST) which was being executed when the system
1.1380 + failure occurred.
1.1381 +
1.1382 +4. FILE TRANSFER FUNCTIONS
1.1383 +
1.1384 + The communication channel from the user-PI to the server-PI is
1.1385 + established as a TCP connection from the user to the standard server
1.1386 + port. The user protocol interpreter is responsible for sending FTP
1.1387 + commands and interpreting the replies received; the server-PI
1.1388 + interprets commands, sends replies and directs its DTP to set up the
1.1389 + data connection and transfer the data. If the second party to the
1.1390 + data transfer (the passive transfer process) is the user-DTP, then it
1.1391 + is governed through the internal protocol of the user-FTP host; if it
1.1392 + is a second server-DTP, then it is governed by its PI on command from
1.1393 + the user-PI. The FTP replies are discussed in the next section. In
1.1394 + the description of a few of the commands in this section, it is
1.1395 + helpful to be explicit about the possible replies.
1.1396 +
1.1397 + 4.1. FTP COMMANDS
1.1398 +
1.1399 + 4.1.1. ACCESS CONTROL COMMANDS
1.1400 +
1.1401 + The following commands specify access control identifiers
1.1402 + (command codes are shown in parentheses).
1.1403 +
1.1404 + USER NAME (USER)
1.1405 +
1.1406 + The argument field is a Telnet string identifying the user.
1.1407 + The user identification is that which is required by the
1.1408 + server for access to its file system. This command will
1.1409 + normally be the first command transmitted by the user after
1.1410 + the control connections are made (some servers may require
1.1411 + this). Additional identification information in the form of
1.1412 + a password and/or an account command may also be required by
1.1413 + some servers. Servers may allow a new USER command to be
1.1414 + entered at any point in order to change the access control
1.1415 + and/or accounting information. This has the effect of
1.1416 + flushing any user, password, and account information already
1.1417 + supplied and beginning the login sequence again. All
1.1418 + transfer parameters are unchanged and any file transfer in
1.1419 + progress is completed under the old access control
1.1420 + parameters.
1.1421 +
1.1422 +
1.1423 +
1.1424 +
1.1425 +
1.1426 +
1.1427 +Postel & Reynolds [Page 25]
1.1428 +
1.1429 +
1.1430 +
1.1431 +RFC 959 October 1985
1.1432 +File Transfer Protocol
1.1433 +
1.1434 +
1.1435 + PASSWORD (PASS)
1.1436 +
1.1437 + The argument field is a Telnet string specifying the user's
1.1438 + password. This command must be immediately preceded by the
1.1439 + user name command, and, for some sites, completes the user's
1.1440 + identification for access control. Since password
1.1441 + information is quite sensitive, it is desirable in general
1.1442 + to "mask" it or suppress typeout. It appears that the
1.1443 + server has no foolproof way to achieve this. It is
1.1444 + therefore the responsibility of the user-FTP process to hide
1.1445 + the sensitive password information.
1.1446 +
1.1447 + ACCOUNT (ACCT)
1.1448 +
1.1449 + The argument field is a Telnet string identifying the user's
1.1450 + account. The command is not necessarily related to the USER
1.1451 + command, as some sites may require an account for login and
1.1452 + others only for specific access, such as storing files. In
1.1453 + the latter case the command may arrive at any time.
1.1454 +
1.1455 + There are reply codes to differentiate these cases for the
1.1456 + automation: when account information is required for login,
1.1457 + the response to a successful PASSword command is reply code
1.1458 + 332. On the other hand, if account information is NOT
1.1459 + required for login, the reply to a successful PASSword
1.1460 + command is 230; and if the account information is needed for
1.1461 + a command issued later in the dialogue, the server should
1.1462 + return a 332 or 532 reply depending on whether it stores
1.1463 + (pending receipt of the ACCounT command) or discards the
1.1464 + command, respectively.
1.1465 +
1.1466 + CHANGE WORKING DIRECTORY (CWD)
1.1467 +
1.1468 + This command allows the user to work with a different
1.1469 + directory or dataset for file storage or retrieval without
1.1470 + altering his login or accounting information. Transfer
1.1471 + parameters are similarly unchanged. The argument is a
1.1472 + pathname specifying a directory or other system dependent
1.1473 + file group designator.
1.1474 +
1.1475 + CHANGE TO PARENT DIRECTORY (CDUP)
1.1476 +
1.1477 + This command is a special case of CWD, and is included to
1.1478 + simplify the implementation of programs for transferring
1.1479 + directory trees between operating systems having different
1.1480 +
1.1481 +
1.1482 +
1.1483 +
1.1484 +Postel & Reynolds [Page 26]
1.1485 +
1.1486 +
1.1487 +
1.1488 +RFC 959 October 1985
1.1489 +File Transfer Protocol
1.1490 +
1.1491 +
1.1492 + syntaxes for naming the parent directory. The reply codes
1.1493 + shall be identical to the reply codes of CWD. See
1.1494 + Appendix II for further details.
1.1495 +
1.1496 + STRUCTURE MOUNT (SMNT)
1.1497 +
1.1498 + This command allows the user to mount a different file
1.1499 + system data structure without altering his login or
1.1500 + accounting information. Transfer parameters are similarly
1.1501 + unchanged. The argument is a pathname specifying a
1.1502 + directory or other system dependent file group designator.
1.1503 +
1.1504 + REINITIALIZE (REIN)
1.1505 +
1.1506 + This command terminates a USER, flushing all I/O and account
1.1507 + information, except to allow any transfer in progress to be
1.1508 + completed. All parameters are reset to the default settings
1.1509 + and the control connection is left open. This is identical
1.1510 + to the state in which a user finds himself immediately after
1.1511 + the control connection is opened. A USER command may be
1.1512 + expected to follow.
1.1513 +
1.1514 + LOGOUT (QUIT)
1.1515 +
1.1516 + This command terminates a USER and if file transfer is not
1.1517 + in progress, the server closes the control connection. If
1.1518 + file transfer is in progress, the connection will remain
1.1519 + open for result response and the server will then close it.
1.1520 + If the user-process is transferring files for several USERs
1.1521 + but does not wish to close and then reopen connections for
1.1522 + each, then the REIN command should be used instead of QUIT.
1.1523 +
1.1524 + An unexpected close on the control connection will cause the
1.1525 + server to take the effective action of an abort (ABOR) and a
1.1526 + logout (QUIT).
1.1527 +
1.1528 + 4.1.2. TRANSFER PARAMETER COMMANDS
1.1529 +
1.1530 + All data transfer parameters have default values, and the
1.1531 + commands specifying data transfer parameters are required only
1.1532 + if the default parameter values are to be changed. The default
1.1533 + value is the last specified value, or if no value has been
1.1534 + specified, the standard default value is as stated here. This
1.1535 + implies that the server must "remember" the applicable default
1.1536 + values. The commands may be in any order except that they must
1.1537 + precede the FTP service request. The following commands
1.1538 + specify data transfer parameters:
1.1539 +
1.1540 +
1.1541 +Postel & Reynolds [Page 27]
1.1542 +
1.1543 +
1.1544 +
1.1545 +RFC 959 October 1985
1.1546 +File Transfer Protocol
1.1547 +
1.1548 +
1.1549 + DATA PORT (PORT)
1.1550 +
1.1551 + The argument is a HOST-PORT specification for the data port
1.1552 + to be used in data connection. There are defaults for both
1.1553 + the user and server data ports, and under normal
1.1554 + circumstances this command and its reply are not needed. If
1.1555 + this command is used, the argument is the concatenation of a
1.1556 + 32-bit internet host address and a 16-bit TCP port address.
1.1557 + This address information is broken into 8-bit fields and the
1.1558 + value of each field is transmitted as a decimal number (in
1.1559 + character string representation). The fields are separated
1.1560 + by commas. A port command would be:
1.1561 +
1.1562 + PORT h1,h2,h3,h4,p1,p2
1.1563 +
1.1564 + where h1 is the high order 8 bits of the internet host
1.1565 + address.
1.1566 +
1.1567 + PASSIVE (PASV)
1.1568 +
1.1569 + This command requests the server-DTP to "listen" on a data
1.1570 + port (which is not its default data port) and to wait for a
1.1571 + connection rather than initiate one upon receipt of a
1.1572 + transfer command. The response to this command includes the
1.1573 + host and port address this server is listening on.
1.1574 +
1.1575 + REPRESENTATION TYPE (TYPE)
1.1576 +
1.1577 + The argument specifies the representation type as described
1.1578 + in the Section on Data Representation and Storage. Several
1.1579 + types take a second parameter. The first parameter is
1.1580 + denoted by a single Telnet character, as is the second
1.1581 + Format parameter for ASCII and EBCDIC; the second parameter
1.1582 + for local byte is a decimal integer to indicate Bytesize.
1.1583 + The parameters are separated by a <SP> (Space, ASCII code
1.1584 + 32).
1.1585 +
1.1586 + The following codes are assigned for type:
1.1587 +
1.1588 + \ /
1.1589 + A - ASCII | | N - Non-print
1.1590 + |-><-| T - Telnet format effectors
1.1591 + E - EBCDIC| | C - Carriage Control (ASA)
1.1592 + / \
1.1593 + I - Image
1.1594 +
1.1595 + L <byte size> - Local byte Byte size
1.1596 +
1.1597 +
1.1598 +Postel & Reynolds [Page 28]
1.1599 +
1.1600 +
1.1601 +
1.1602 +RFC 959 October 1985
1.1603 +File Transfer Protocol
1.1604 +
1.1605 +
1.1606 + The default representation type is ASCII Non-print. If the
1.1607 + Format parameter is changed, and later just the first
1.1608 + argument is changed, Format then returns to the Non-print
1.1609 + default.
1.1610 +
1.1611 + FILE STRUCTURE (STRU)
1.1612 +
1.1613 + The argument is a single Telnet character code specifying
1.1614 + file structure described in the Section on Data
1.1615 + Representation and Storage.
1.1616 +
1.1617 + The following codes are assigned for structure:
1.1618 +
1.1619 + F - File (no record structure)
1.1620 + R - Record structure
1.1621 + P - Page structure
1.1622 +
1.1623 + The default structure is File.
1.1624 +
1.1625 + TRANSFER MODE (MODE)
1.1626 +
1.1627 + The argument is a single Telnet character code specifying
1.1628 + the data transfer modes described in the Section on
1.1629 + Transmission Modes.
1.1630 +
1.1631 + The following codes are assigned for transfer modes:
1.1632 +
1.1633 + S - Stream
1.1634 + B - Block
1.1635 + C - Compressed
1.1636 +
1.1637 + The default transfer mode is Stream.
1.1638 +
1.1639 + 4.1.3. FTP SERVICE COMMANDS
1.1640 +
1.1641 + The FTP service commands define the file transfer or the file
1.1642 + system function requested by the user. The argument of an FTP
1.1643 + service command will normally be a pathname. The syntax of
1.1644 + pathnames must conform to server site conventions (with
1.1645 + standard defaults applicable), and the language conventions of
1.1646 + the control connection. The suggested default handling is to
1.1647 + use the last specified device, directory or file name, or the
1.1648 + standard default defined for local users. The commands may be
1.1649 + in any order except that a "rename from" command must be
1.1650 + followed by a "rename to" command and the restart command must
1.1651 + be followed by the interrupted service command (e.g., STOR or
1.1652 + RETR). The data, when transferred in response to FTP service
1.1653 +
1.1654 +
1.1655 +Postel & Reynolds [Page 29]
1.1656 +
1.1657 +
1.1658 +
1.1659 +RFC 959 October 1985
1.1660 +File Transfer Protocol
1.1661 +
1.1662 +
1.1663 + commands, shall always be sent over the data connection, except
1.1664 + for certain informative replies. The following commands
1.1665 + specify FTP service requests:
1.1666 +
1.1667 + RETRIEVE (RETR)
1.1668 +
1.1669 + This command causes the server-DTP to transfer a copy of the
1.1670 + file, specified in the pathname, to the server- or user-DTP
1.1671 + at the other end of the data connection. The status and
1.1672 + contents of the file at the server site shall be unaffected.
1.1673 +
1.1674 + STORE (STOR)
1.1675 +
1.1676 + This command causes the server-DTP to accept the data
1.1677 + transferred via the data connection and to store the data as
1.1678 + a file at the server site. If the file specified in the
1.1679 + pathname exists at the server site, then its contents shall
1.1680 + be replaced by the data being transferred. A new file is
1.1681 + created at the server site if the file specified in the
1.1682 + pathname does not already exist.
1.1683 +
1.1684 + STORE UNIQUE (STOU)
1.1685 +
1.1686 + This command behaves like STOR except that the resultant
1.1687 + file is to be created in the current directory under a name
1.1688 + unique to that directory. The 250 Transfer Started response
1.1689 + must include the name generated.
1.1690 +
1.1691 + APPEND (with create) (APPE)
1.1692 +
1.1693 + This command causes the server-DTP to accept the data
1.1694 + transferred via the data connection and to store the data in
1.1695 + a file at the server site. If the file specified in the
1.1696 + pathname exists at the server site, then the data shall be
1.1697 + appended to that file; otherwise the file specified in the
1.1698 + pathname shall be created at the server site.
1.1699 +
1.1700 + ALLOCATE (ALLO)
1.1701 +
1.1702 + This command may be required by some servers to reserve
1.1703 + sufficient storage to accommodate the new file to be
1.1704 + transferred. The argument shall be a decimal integer
1.1705 + representing the number of bytes (using the logical byte
1.1706 + size) of storage to be reserved for the file. For files
1.1707 + sent with record or page structure a maximum record or page
1.1708 + size (in logical bytes) might also be necessary; this is
1.1709 + indicated by a decimal integer in a second argument field of
1.1710 +
1.1711 +
1.1712 +Postel & Reynolds [Page 30]
1.1713 +
1.1714 +
1.1715 +
1.1716 +RFC 959 October 1985
1.1717 +File Transfer Protocol
1.1718 +
1.1719 +
1.1720 + the command. This second argument is optional, but when
1.1721 + present should be separated from the first by the three
1.1722 + Telnet characters <SP> R <SP>. This command shall be
1.1723 + followed by a STORe or APPEnd command. The ALLO command
1.1724 + should be treated as a NOOP (no operation) by those servers
1.1725 + which do not require that the maximum size of the file be
1.1726 + declared beforehand, and those servers interested in only
1.1727 + the maximum record or page size should accept a dummy value
1.1728 + in the first argument and ignore it.
1.1729 +
1.1730 + RESTART (REST)
1.1731 +
1.1732 + The argument field represents the server marker at which
1.1733 + file transfer is to be restarted. This command does not
1.1734 + cause file transfer but skips over the file to the specified
1.1735 + data checkpoint. This command shall be immediately followed
1.1736 + by the appropriate FTP service command which shall cause
1.1737 + file transfer to resume.
1.1738 +
1.1739 + RENAME FROM (RNFR)
1.1740 +
1.1741 + This command specifies the old pathname of the file which is
1.1742 + to be renamed. This command must be immediately followed by
1.1743 + a "rename to" command specifying the new file pathname.
1.1744 +
1.1745 + RENAME TO (RNTO)
1.1746 +
1.1747 + This command specifies the new pathname of the file
1.1748 + specified in the immediately preceding "rename from"
1.1749 + command. Together the two commands cause a file to be
1.1750 + renamed.
1.1751 +
1.1752 + ABORT (ABOR)
1.1753 +
1.1754 + This command tells the server to abort the previous FTP
1.1755 + service command and any associated transfer of data. The
1.1756 + abort command may require "special action", as discussed in
1.1757 + the Section on FTP Commands, to force recognition by the
1.1758 + server. No action is to be taken if the previous command
1.1759 + has been completed (including data transfer). The control
1.1760 + connection is not to be closed by the server, but the data
1.1761 + connection must be closed.
1.1762 +
1.1763 + There are two cases for the server upon receipt of this
1.1764 + command: (1) the FTP service command was already completed,
1.1765 + or (2) the FTP service command is still in progress.
1.1766 +
1.1767 +
1.1768 +
1.1769 +Postel & Reynolds [Page 31]
1.1770 +
1.1771 +
1.1772 +
1.1773 +RFC 959 October 1985
1.1774 +File Transfer Protocol
1.1775 +
1.1776 +
1.1777 + In the first case, the server closes the data connection
1.1778 + (if it is open) and responds with a 226 reply, indicating
1.1779 + that the abort command was successfully processed.
1.1780 +
1.1781 + In the second case, the server aborts the FTP service in
1.1782 + progress and closes the data connection, returning a 426
1.1783 + reply to indicate that the service request terminated
1.1784 + abnormally. The server then sends a 226 reply,
1.1785 + indicating that the abort command was successfully
1.1786 + processed.
1.1787 +
1.1788 + DELETE (DELE)
1.1789 +
1.1790 + This command causes the file specified in the pathname to be
1.1791 + deleted at the server site. If an extra level of protection
1.1792 + is desired (such as the query, "Do you really wish to
1.1793 + delete?"), it should be provided by the user-FTP process.
1.1794 +
1.1795 + REMOVE DIRECTORY (RMD)
1.1796 +
1.1797 + This command causes the directory specified in the pathname
1.1798 + to be removed as a directory (if the pathname is absolute)
1.1799 + or as a subdirectory of the current working directory (if
1.1800 + the pathname is relative). See Appendix II.
1.1801 +
1.1802 + MAKE DIRECTORY (MKD)
1.1803 +
1.1804 + This command causes the directory specified in the pathname
1.1805 + to be created as a directory (if the pathname is absolute)
1.1806 + or as a subdirectory of the current working directory (if
1.1807 + the pathname is relative). See Appendix II.
1.1808 +
1.1809 + PRINT WORKING DIRECTORY (PWD)
1.1810 +
1.1811 + This command causes the name of the current working
1.1812 + directory to be returned in the reply. See Appendix II.
1.1813 +
1.1814 + LIST (LIST)
1.1815 +
1.1816 + This command causes a list to be sent from the server to the
1.1817 + passive DTP. If the pathname specifies a directory or other
1.1818 + group of files, the server should transfer a list of files
1.1819 + in the specified directory. If the pathname specifies a
1.1820 + file then the server should send current information on the
1.1821 + file. A null argument implies the user's current working or
1.1822 + default directory. The data transfer is over the data
1.1823 + connection in type ASCII or type EBCDIC. (The user must
1.1824 +
1.1825 +
1.1826 +Postel & Reynolds [Page 32]
1.1827 +
1.1828 +
1.1829 +
1.1830 +RFC 959 October 1985
1.1831 +File Transfer Protocol
1.1832 +
1.1833 +
1.1834 + ensure that the TYPE is appropriately ASCII or EBCDIC).
1.1835 + Since the information on a file may vary widely from system
1.1836 + to system, this information may be hard to use automatically
1.1837 + in a program, but may be quite useful to a human user.
1.1838 +
1.1839 + NAME LIST (NLST)
1.1840 +
1.1841 + This command causes a directory listing to be sent from
1.1842 + server to user site. The pathname should specify a
1.1843 + directory or other system-specific file group descriptor; a
1.1844 + null argument implies the current directory. The server
1.1845 + will return a stream of names of files and no other
1.1846 + information. The data will be transferred in ASCII or
1.1847 + EBCDIC type over the data connection as valid pathname
1.1848 + strings separated by <CRLF> or <NL>. (Again the user must
1.1849 + ensure that the TYPE is correct.) This command is intended
1.1850 + to return information that can be used by a program to
1.1851 + further process the files automatically. For example, in
1.1852 + the implementation of a "multiple get" function.
1.1853 +
1.1854 + SITE PARAMETERS (SITE)
1.1855 +
1.1856 + This command is used by the server to provide services
1.1857 + specific to his system that are essential to file transfer
1.1858 + but not sufficiently universal to be included as commands in
1.1859 + the protocol. The nature of these services and the
1.1860 + specification of their syntax can be stated in a reply to
1.1861 + the HELP SITE command.
1.1862 +
1.1863 + SYSTEM (SYST)
1.1864 +
1.1865 + This command is used to find out the type of operating
1.1866 + system at the server. The reply shall have as its first
1.1867 + word one of the system names listed in the current version
1.1868 + of the Assigned Numbers document [4].
1.1869 +
1.1870 + STATUS (STAT)
1.1871 +
1.1872 + This command shall cause a status response to be sent over
1.1873 + the control connection in the form of a reply. The command
1.1874 + may be sent during a file transfer (along with the Telnet IP
1.1875 + and Synch signals--see the Section on FTP Commands) in which
1.1876 + case the server will respond with the status of the
1.1877 + operation in progress, or it may be sent between file
1.1878 + transfers. In the latter case, the command may have an
1.1879 + argument field. If the argument is a pathname, the command
1.1880 + is analogous to the "list" command except that data shall be
1.1881 +
1.1882 +
1.1883 +Postel & Reynolds [Page 33]
1.1884 +
1.1885 +
1.1886 +
1.1887 +RFC 959 October 1985
1.1888 +File Transfer Protocol
1.1889 +
1.1890 +
1.1891 + transferred over the control connection. If a partial
1.1892 + pathname is given, the server may respond with a list of
1.1893 + file names or attributes associated with that specification.
1.1894 + If no argument is given, the server should return general
1.1895 + status information about the server FTP process. This
1.1896 + should include current values of all transfer parameters and
1.1897 + the status of connections.
1.1898 +
1.1899 + HELP (HELP)
1.1900 +
1.1901 + This command shall cause the server to send helpful
1.1902 + information regarding its implementation status over the
1.1903 + control connection to the user. The command may take an
1.1904 + argument (e.g., any command name) and return more specific
1.1905 + information as a response. The reply is type 211 or 214.
1.1906 + It is suggested that HELP be allowed before entering a USER
1.1907 + command. The server may use this reply to specify
1.1908 + site-dependent parameters, e.g., in response to HELP SITE.
1.1909 +
1.1910 + NOOP (NOOP)
1.1911 +
1.1912 + This command does not affect any parameters or previously
1.1913 + entered commands. It specifies no action other than that the
1.1914 + server send an OK reply.
1.1915 +
1.1916 + The File Transfer Protocol follows the specifications of the Telnet
1.1917 + protocol for all communications over the control connection. Since
1.1918 + the language used for Telnet communication may be a negotiated
1.1919 + option, all references in the next two sections will be to the
1.1920 + "Telnet language" and the corresponding "Telnet end-of-line code".
1.1921 + Currently, one may take these to mean NVT-ASCII and <CRLF>. No other
1.1922 + specifications of the Telnet protocol will be cited.
1.1923 +
1.1924 + FTP commands are "Telnet strings" terminated by the "Telnet end of
1.1925 + line code". The command codes themselves are alphabetic characters
1.1926 + terminated by the character <SP> (Space) if parameters follow and
1.1927 + Telnet-EOL otherwise. The command codes and the semantics of
1.1928 + commands are described in this section; the detailed syntax of
1.1929 + commands is specified in the Section on Commands, the reply sequences
1.1930 + are discussed in the Section on Sequencing of Commands and Replies,
1.1931 + and scenarios illustrating the use of commands are provided in the
1.1932 + Section on Typical FTP Scenarios.
1.1933 +
1.1934 + FTP commands may be partitioned as those specifying access-control
1.1935 + identifiers, data transfer parameters, or FTP service requests.
1.1936 + Certain commands (such as ABOR, STAT, QUIT) may be sent over the
1.1937 + control connection while a data transfer is in progress. Some
1.1938 +
1.1939 +
1.1940 +Postel & Reynolds [Page 34]
1.1941 +
1.1942 +
1.1943 +
1.1944 +RFC 959 October 1985
1.1945 +File Transfer Protocol
1.1946 +
1.1947 +
1.1948 + servers may not be able to monitor the control and data connections
1.1949 + simultaneously, in which case some special action will be necessary
1.1950 + to get the server's attention. The following ordered format is
1.1951 + tentatively recommended:
1.1952 +
1.1953 + 1. User system inserts the Telnet "Interrupt Process" (IP) signal
1.1954 + in the Telnet stream.
1.1955 +
1.1956 + 2. User system sends the Telnet "Synch" signal.
1.1957 +
1.1958 + 3. User system inserts the command (e.g., ABOR) in the Telnet
1.1959 + stream.
1.1960 +
1.1961 + 4. Server PI, after receiving "IP", scans the Telnet stream for
1.1962 + EXACTLY ONE FTP command.
1.1963 +
1.1964 + (For other servers this may not be necessary but the actions listed
1.1965 + above should have no unusual effect.)
1.1966 +
1.1967 + 4.2. FTP REPLIES
1.1968 +
1.1969 + Replies to File Transfer Protocol commands are devised to ensure
1.1970 + the synchronization of requests and actions in the process of file
1.1971 + transfer, and to guarantee that the user process always knows the
1.1972 + state of the Server. Every command must generate at least one
1.1973 + reply, although there may be more than one; in the latter case,
1.1974 + the multiple replies must be easily distinguished. In addition,
1.1975 + some commands occur in sequential groups, such as USER, PASS and
1.1976 + ACCT, or RNFR and RNTO. The replies show the existence of an
1.1977 + intermediate state if all preceding commands have been successful.
1.1978 + A failure at any point in the sequence necessitates the repetition
1.1979 + of the entire sequence from the beginning.
1.1980 +
1.1981 + The details of the command-reply sequence are made explicit in
1.1982 + a set of state diagrams below.
1.1983 +
1.1984 + An FTP reply consists of a three digit number (transmitted as
1.1985 + three alphanumeric characters) followed by some text. The number
1.1986 + is intended for use by automata to determine what state to enter
1.1987 + next; the text is intended for the human user. It is intended
1.1988 + that the three digits contain enough encoded information that the
1.1989 + user-process (the User-PI) will not need to examine the text and
1.1990 + may either discard it or pass it on to the user, as appropriate.
1.1991 + In particular, the text may be server-dependent, so there are
1.1992 + likely to be varying texts for each reply code.
1.1993 +
1.1994 + A reply is defined to contain the 3-digit code, followed by Space
1.1995 +
1.1996 +
1.1997 +Postel & Reynolds [Page 35]
1.1998 +
1.1999 +
1.2000 +
1.2001 +RFC 959 October 1985
1.2002 +File Transfer Protocol
1.2003 +
1.2004 +
1.2005 + <SP>, followed by one line of text (where some maximum line length
1.2006 + has been specified), and terminated by the Telnet end-of-line
1.2007 + code. There will be cases however, where the text is longer than
1.2008 + a single line. In these cases the complete text must be bracketed
1.2009 + so the User-process knows when it may stop reading the reply (i.e.
1.2010 + stop processing input on the control connection) and go do other
1.2011 + things. This requires a special format on the first line to
1.2012 + indicate that more than one line is coming, and another on the
1.2013 + last line to designate it as the last. At least one of these must
1.2014 + contain the appropriate reply code to indicate the state of the
1.2015 + transaction. To satisfy all factions, it was decided that both
1.2016 + the first and last line codes should be the same.
1.2017 +
1.2018 + Thus the format for multi-line replies is that the first line
1.2019 + will begin with the exact required reply code, followed
1.2020 + immediately by a Hyphen, "-" (also known as Minus), followed by
1.2021 + text. The last line will begin with the same code, followed
1.2022 + immediately by Space <SP>, optionally some text, and the Telnet
1.2023 + end-of-line code.
1.2024 +
1.2025 + For example:
1.2026 + 123-First line
1.2027 + Second line
1.2028 + 234 A line beginning with numbers
1.2029 + 123 The last line
1.2030 +
1.2031 + The user-process then simply needs to search for the second
1.2032 + occurrence of the same reply code, followed by <SP> (Space), at
1.2033 + the beginning of a line, and ignore all intermediary lines. If
1.2034 + an intermediary line begins with a 3-digit number, the Server
1.2035 + must pad the front to avoid confusion.
1.2036 +
1.2037 + This scheme allows standard system routines to be used for
1.2038 + reply information (such as for the STAT reply), with
1.2039 + "artificial" first and last lines tacked on. In rare cases
1.2040 + where these routines are able to generate three digits and a
1.2041 + Space at the beginning of any line, the beginning of each
1.2042 + text line should be offset by some neutral text, like Space.
1.2043 +
1.2044 + This scheme assumes that multi-line replies may not be nested.
1.2045 +
1.2046 + The three digits of the reply each have a special significance.
1.2047 + This is intended to allow a range of very simple to very
1.2048 + sophisticated responses by the user-process. The first digit
1.2049 + denotes whether the response is good, bad or incomplete.
1.2050 + (Referring to the state diagram), an unsophisticated user-process
1.2051 + will be able to determine its next action (proceed as planned,
1.2052 +
1.2053 +
1.2054 +Postel & Reynolds [Page 36]
1.2055 +
1.2056 +
1.2057 +
1.2058 +RFC 959 October 1985
1.2059 +File Transfer Protocol
1.2060 +
1.2061 +
1.2062 + redo, retrench, etc.) by simply examining this first digit. A
1.2063 + user-process that wants to know approximately what kind of error
1.2064 + occurred (e.g. file system error, command syntax error) may
1.2065 + examine the second digit, reserving the third digit for the finest
1.2066 + gradation of information (e.g., RNTO command without a preceding
1.2067 + RNFR).
1.2068 +
1.2069 + There are five values for the first digit of the reply code:
1.2070 +
1.2071 + 1yz Positive Preliminary reply
1.2072 +
1.2073 + The requested action is being initiated; expect another
1.2074 + reply before proceeding with a new command. (The
1.2075 + user-process sending another command before the
1.2076 + completion reply would be in violation of protocol; but
1.2077 + server-FTP processes should queue any commands that
1.2078 + arrive while a preceding command is in progress.) This
1.2079 + type of reply can be used to indicate that the command
1.2080 + was accepted and the user-process may now pay attention
1.2081 + to the data connections, for implementations where
1.2082 + simultaneous monitoring is difficult. The server-FTP
1.2083 + process may send at most, one 1yz reply per command.
1.2084 +
1.2085 + 2yz Positive Completion reply
1.2086 +
1.2087 + The requested action has been successfully completed. A
1.2088 + new request may be initiated.
1.2089 +
1.2090 + 3yz Positive Intermediate reply
1.2091 +
1.2092 + The command has been accepted, but the requested action
1.2093 + is being held in abeyance, pending receipt of further
1.2094 + information. The user should send another command
1.2095 + specifying this information. This reply is used in
1.2096 + command sequence groups.
1.2097 +
1.2098 + 4yz Transient Negative Completion reply
1.2099 +
1.2100 + The command was not accepted and the requested action did
1.2101 + not take place, but the error condition is temporary and
1.2102 + the action may be requested again. The user should
1.2103 + return to the beginning of the command sequence, if any.
1.2104 + It is difficult to assign a meaning to "transient",
1.2105 + particularly when two distinct sites (Server- and
1.2106 + User-processes) have to agree on the interpretation.
1.2107 + Each reply in the 4yz category might have a slightly
1.2108 + different time value, but the intent is that the
1.2109 +
1.2110 +
1.2111 +Postel & Reynolds [Page 37]
1.2112 +
1.2113 +
1.2114 +
1.2115 +RFC 959 October 1985
1.2116 +File Transfer Protocol
1.2117 +
1.2118 +
1.2119 + user-process is encouraged to try again. A rule of thumb
1.2120 + in determining if a reply fits into the 4yz or the 5yz
1.2121 + (Permanent Negative) category is that replies are 4yz if
1.2122 + the commands can be repeated without any change in
1.2123 + command form or in properties of the User or Server
1.2124 + (e.g., the command is spelled the same with the same
1.2125 + arguments used; the user does not change his file access
1.2126 + or user name; the server does not put up a new
1.2127 + implementation.)
1.2128 +
1.2129 + 5yz Permanent Negative Completion reply
1.2130 +
1.2131 + The command was not accepted and the requested action did
1.2132 + not take place. The User-process is discouraged from
1.2133 + repeating the exact request (in the same sequence). Even
1.2134 + some "permanent" error conditions can be corrected, so
1.2135 + the human user may want to direct his User-process to
1.2136 + reinitiate the command sequence by direct action at some
1.2137 + point in the future (e.g., after the spelling has been
1.2138 + changed, or the user has altered his directory status.)
1.2139 +
1.2140 + The following function groupings are encoded in the second
1.2141 + digit:
1.2142 +
1.2143 + x0z Syntax - These replies refer to syntax errors,
1.2144 + syntactically correct commands that don't fit any
1.2145 + functional category, unimplemented or superfluous
1.2146 + commands.
1.2147 +
1.2148 + x1z Information - These are replies to requests for
1.2149 + information, such as status or help.
1.2150 +
1.2151 + x2z Connections - Replies referring to the control and
1.2152 + data connections.
1.2153 +
1.2154 + x3z Authentication and accounting - Replies for the login
1.2155 + process and accounting procedures.
1.2156 +
1.2157 + x4z Unspecified as yet.
1.2158 +
1.2159 + x5z File system - These replies indicate the status of the
1.2160 + Server file system vis-a-vis the requested transfer or
1.2161 + other file system action.
1.2162 +
1.2163 + The third digit gives a finer gradation of meaning in each of
1.2164 + the function categories, specified by the second digit. The
1.2165 + list of replies below will illustrate this. Note that the text
1.2166 +
1.2167 +
1.2168 +Postel & Reynolds [Page 38]
1.2169 +
1.2170 +
1.2171 +
1.2172 +RFC 959 October 1985
1.2173 +File Transfer Protocol
1.2174 +
1.2175 +
1.2176 + associated with each reply is recommended, rather than
1.2177 + mandatory, and may even change according to the command with
1.2178 + which it is associated. The reply codes, on the other hand,
1.2179 + must strictly follow the specifications in the last section;
1.2180 + that is, Server implementations should not invent new codes for
1.2181 + situations that are only slightly different from the ones
1.2182 + described here, but rather should adapt codes already defined.
1.2183 +
1.2184 + A command such as TYPE or ALLO whose successful execution
1.2185 + does not offer the user-process any new information will
1.2186 + cause a 200 reply to be returned. If the command is not
1.2187 + implemented by a particular Server-FTP process because it
1.2188 + has no relevance to that computer system, for example ALLO
1.2189 + at a TOPS20 site, a Positive Completion reply is still
1.2190 + desired so that the simple User-process knows it can proceed
1.2191 + with its course of action. A 202 reply is used in this case
1.2192 + with, for example, the reply text: "No storage allocation
1.2193 + necessary." If, on the other hand, the command requests a
1.2194 + non-site-specific action and is unimplemented, the response
1.2195 + is 502. A refinement of that is the 504 reply for a command
1.2196 + that is implemented, but that requests an unimplemented
1.2197 + parameter.
1.2198 +
1.2199 + 4.2.1 Reply Codes by Function Groups
1.2200 +
1.2201 + 200 Command okay.
1.2202 + 500 Syntax error, command unrecognized.
1.2203 + This may include errors such as command line too long.
1.2204 + 501 Syntax error in parameters or arguments.
1.2205 + 202 Command not implemented, superfluous at this site.
1.2206 + 502 Command not implemented.
1.2207 + 503 Bad sequence of commands.
1.2208 + 504 Command not implemented for that parameter.
1.2209 +
1.2210 +
1.2211 +
1.2212 +
1.2213 +
1.2214 +
1.2215 +
1.2216 +
1.2217 +
1.2218 +
1.2219 +
1.2220 +
1.2221 +
1.2222 +
1.2223 +
1.2224 +
1.2225 +Postel & Reynolds [Page 39]
1.2226 +
1.2227 +
1.2228 +
1.2229 +RFC 959 October 1985
1.2230 +File Transfer Protocol
1.2231 +
1.2232 +
1.2233 + 110 Restart marker reply.
1.2234 + In this case, the text is exact and not left to the
1.2235 + particular implementation; it must read:
1.2236 + MARK yyyy = mmmm
1.2237 + Where yyyy is User-process data stream marker, and mmmm
1.2238 + server's equivalent marker (note the spaces between markers
1.2239 + and "=").
1.2240 + 211 System status, or system help reply.
1.2241 + 212 Directory status.
1.2242 + 213 File status.
1.2243 + 214 Help message.
1.2244 + On how to use the server or the meaning of a particular
1.2245 + non-standard command. This reply is useful only to the
1.2246 + human user.
1.2247 + 215 NAME system type.
1.2248 + Where NAME is an official system name from the list in the
1.2249 + Assigned Numbers document.
1.2250 +
1.2251 + 120 Service ready in nnn minutes.
1.2252 + 220 Service ready for new user.
1.2253 + 221 Service closing control connection.
1.2254 + Logged out if appropriate.
1.2255 + 421 Service not available, closing control connection.
1.2256 + This may be a reply to any command if the service knows it
1.2257 + must shut down.
1.2258 + 125 Data connection already open; transfer starting.
1.2259 + 225 Data connection open; no transfer in progress.
1.2260 + 425 Can't open data connection.
1.2261 + 226 Closing data connection.
1.2262 + Requested file action successful (for example, file
1.2263 + transfer or file abort).
1.2264 + 426 Connection closed; transfer aborted.
1.2265 + 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
1.2266 +
1.2267 + 230 User logged in, proceed.
1.2268 + 530 Not logged in.
1.2269 + 331 User name okay, need password.
1.2270 + 332 Need account for login.
1.2271 + 532 Need account for storing files.
1.2272 +
1.2273 +
1.2274 +
1.2275 +
1.2276 +
1.2277 +
1.2278 +
1.2279 +
1.2280 +
1.2281 +
1.2282 +Postel & Reynolds [Page 40]
1.2283 +
1.2284 +
1.2285 +
1.2286 +RFC 959 October 1985
1.2287 +File Transfer Protocol
1.2288 +
1.2289 +
1.2290 + 150 File status okay; about to open data connection.
1.2291 + 250 Requested file action okay, completed.
1.2292 + 257 "PATHNAME" created.
1.2293 + 350 Requested file action pending further information.
1.2294 + 450 Requested file action not taken.
1.2295 + File unavailable (e.g., file busy).
1.2296 + 550 Requested action not taken.
1.2297 + File unavailable (e.g., file not found, no access).
1.2298 + 451 Requested action aborted. Local error in processing.
1.2299 + 551 Requested action aborted. Page type unknown.
1.2300 + 452 Requested action not taken.
1.2301 + Insufficient storage space in system.
1.2302 + 552 Requested file action aborted.
1.2303 + Exceeded storage allocation (for current directory or
1.2304 + dataset).
1.2305 + 553 Requested action not taken.
1.2306 + File name not allowed.
1.2307 +
1.2308 +
1.2309 + 4.2.2 Numeric Order List of Reply Codes
1.2310 +
1.2311 + 110 Restart marker reply.
1.2312 + In this case, the text is exact and not left to the
1.2313 + particular implementation; it must read:
1.2314 + MARK yyyy = mmmm
1.2315 + Where yyyy is User-process data stream marker, and mmmm
1.2316 + server's equivalent marker (note the spaces between markers
1.2317 + and "=").
1.2318 + 120 Service ready in nnn minutes.
1.2319 + 125 Data connection already open; transfer starting.
1.2320 + 150 File status okay; about to open data connection.
1.2321 +
1.2322 +
1.2323 +
1.2324 +
1.2325 +
1.2326 +
1.2327 +
1.2328 +
1.2329 +
1.2330 +
1.2331 +
1.2332 +
1.2333 +
1.2334 +
1.2335 +
1.2336 +
1.2337 +
1.2338 +
1.2339 +Postel & Reynolds [Page 41]
1.2340 +
1.2341 +
1.2342 +
1.2343 +RFC 959 October 1985
1.2344 +File Transfer Protocol
1.2345 +
1.2346 +
1.2347 + 200 Command okay.
1.2348 + 202 Command not implemented, superfluous at this site.
1.2349 + 211 System status, or system help reply.
1.2350 + 212 Directory status.
1.2351 + 213 File status.
1.2352 + 214 Help message.
1.2353 + On how to use the server or the meaning of a particular
1.2354 + non-standard command. This reply is useful only to the
1.2355 + human user.
1.2356 + 215 NAME system type.
1.2357 + Where NAME is an official system name from the list in the
1.2358 + Assigned Numbers document.
1.2359 + 220 Service ready for new user.
1.2360 + 221 Service closing control connection.
1.2361 + Logged out if appropriate.
1.2362 + 225 Data connection open; no transfer in progress.
1.2363 + 226 Closing data connection.
1.2364 + Requested file action successful (for example, file
1.2365 + transfer or file abort).
1.2366 + 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
1.2367 + 230 User logged in, proceed.
1.2368 + 250 Requested file action okay, completed.
1.2369 + 257 "PATHNAME" created.
1.2370 +
1.2371 + 331 User name okay, need password.
1.2372 + 332 Need account for login.
1.2373 + 350 Requested file action pending further information.
1.2374 +
1.2375 + 421 Service not available, closing control connection.
1.2376 + This may be a reply to any command if the service knows it
1.2377 + must shut down.
1.2378 + 425 Can't open data connection.
1.2379 + 426 Connection closed; transfer aborted.
1.2380 + 450 Requested file action not taken.
1.2381 + File unavailable (e.g., file busy).
1.2382 + 451 Requested action aborted: local error in processing.
1.2383 + 452 Requested action not taken.
1.2384 + Insufficient storage space in system.
1.2385 +
1.2386 +
1.2387 +
1.2388 +
1.2389 +
1.2390 +
1.2391 +
1.2392 +
1.2393 +
1.2394 +
1.2395 +
1.2396 +Postel & Reynolds [Page 42]
1.2397 +
1.2398 +
1.2399 +
1.2400 +RFC 959 October 1985
1.2401 +File Transfer Protocol
1.2402 +
1.2403 +
1.2404 + 500 Syntax error, command unrecognized.
1.2405 + This may include errors such as command line too long.
1.2406 + 501 Syntax error in parameters or arguments.
1.2407 + 502 Command not implemented.
1.2408 + 503 Bad sequence of commands.
1.2409 + 504 Command not implemented for that parameter.
1.2410 + 530 Not logged in.
1.2411 + 532 Need account for storing files.
1.2412 + 550 Requested action not taken.
1.2413 + File unavailable (e.g., file not found, no access).
1.2414 + 551 Requested action aborted: page type unknown.
1.2415 + 552 Requested file action aborted.
1.2416 + Exceeded storage allocation (for current directory or
1.2417 + dataset).
1.2418 + 553 Requested action not taken.
1.2419 + File name not allowed.
1.2420 +
1.2421 +
1.2422 +5. DECLARATIVE SPECIFICATIONS
1.2423 +
1.2424 + 5.1. MINIMUM IMPLEMENTATION
1.2425 +
1.2426 + In order to make FTP workable without needless error messages, the
1.2427 + following minimum implementation is required for all servers:
1.2428 +
1.2429 + TYPE - ASCII Non-print
1.2430 + MODE - Stream
1.2431 + STRUCTURE - File, Record
1.2432 + COMMANDS - USER, QUIT, PORT,
1.2433 + TYPE, MODE, STRU,
1.2434 + for the default values
1.2435 + RETR, STOR,
1.2436 + NOOP.
1.2437 +
1.2438 + The default values for transfer parameters are:
1.2439 +
1.2440 + TYPE - ASCII Non-print
1.2441 + MODE - Stream
1.2442 + STRU - File
1.2443 +
1.2444 + All hosts must accept the above as the standard defaults.
1.2445 +
1.2446 +
1.2447 +
1.2448 +
1.2449 +
1.2450 +
1.2451 +
1.2452 +
1.2453 +Postel & Reynolds [Page 43]
1.2454 +
1.2455 +
1.2456 +
1.2457 +RFC 959 October 1985
1.2458 +File Transfer Protocol
1.2459 +
1.2460 +
1.2461 + 5.2. CONNECTIONS
1.2462 +
1.2463 + The server protocol interpreter shall "listen" on Port L. The
1.2464 + user or user protocol interpreter shall initiate the full-duplex
1.2465 + control connection. Server- and user- processes should follow the
1.2466 + conventions of the Telnet protocol as specified in the
1.2467 + ARPA-Internet Protocol Handbook [1]. Servers are under no
1.2468 + obligation to provide for editing of command lines and may require
1.2469 + that it be done in the user host. The control connection shall be
1.2470 + closed by the server at the user's request after all transfers and
1.2471 + replies are completed.
1.2472 +
1.2473 + The user-DTP must "listen" on the specified data port; this may be
1.2474 + the default user port (U) or a port specified in the PORT command.
1.2475 + The server shall initiate the data connection from his own default
1.2476 + data port (L-1) using the specified user data port. The direction
1.2477 + of the transfer and the port used will be determined by the FTP
1.2478 + service command.
1.2479 +
1.2480 + Note that all FTP implementation must support data transfer using
1.2481 + the default port, and that only the USER-PI may initiate the use
1.2482 + of non-default ports.
1.2483 +
1.2484 + When data is to be transferred between two servers, A and B (refer
1.2485 + to Figure 2), the user-PI, C, sets up control connections with
1.2486 + both server-PI's. One of the servers, say A, is then sent a PASV
1.2487 + command telling him to "listen" on his data port rather than
1.2488 + initiate a connection when he receives a transfer service command.
1.2489 + When the user-PI receives an acknowledgment to the PASV command,
1.2490 + which includes the identity of the host and port being listened
1.2491 + on, the user-PI then sends A's port, a, to B in a PORT command; a
1.2492 + reply is returned. The user-PI may then send the corresponding
1.2493 + service commands to A and B. Server B initiates the connection
1.2494 + and the transfer proceeds. The command-reply sequence is listed
1.2495 + below where the messages are vertically synchronous but
1.2496 + horizontally asynchronous:
1.2497 +
1.2498 +
1.2499 +
1.2500 +
1.2501 +
1.2502 +
1.2503 +
1.2504 +
1.2505 +
1.2506 +
1.2507 +
1.2508 +
1.2509 +
1.2510 +Postel & Reynolds [Page 44]
1.2511 +
1.2512 +
1.2513 +
1.2514 +RFC 959 October 1985
1.2515 +File Transfer Protocol
1.2516 +
1.2517 +
1.2518 + User-PI - Server A User-PI - Server B
1.2519 + ------------------ ------------------
1.2520 +
1.2521 + C->A : Connect C->B : Connect
1.2522 + C->A : PASV
1.2523 + A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
1.2524 + C->B : PORT A1,A2,A3,A4,a1,a2
1.2525 + B->C : 200 Okay
1.2526 + C->A : STOR C->B : RETR
1.2527 + B->A : Connect to HOST-A, PORT-a
1.2528 +
1.2529 + Figure 3
1.2530 +
1.2531 + The data connection shall be closed by the server under the
1.2532 + conditions described in the Section on Establishing Data
1.2533 + Connections. If the data connection is to be closed following a
1.2534 + data transfer where closing the connection is not required to
1.2535 + indicate the end-of-file, the server must do so immediately.
1.2536 + Waiting until after a new transfer command is not permitted
1.2537 + because the user-process will have already tested the data
1.2538 + connection to see if it needs to do a "listen"; (remember that the
1.2539 + user must "listen" on a closed data port BEFORE sending the
1.2540 + transfer request). To prevent a race condition here, the server
1.2541 + sends a reply (226) after closing the data connection (or if the
1.2542 + connection is left open, a "file transfer completed" reply (250)
1.2543 + and the user-PI should wait for one of these replies before
1.2544 + issuing a new transfer command).
1.2545 +
1.2546 + Any time either the user or server see that the connection is
1.2547 + being closed by the other side, it should promptly read any
1.2548 + remaining data queued on the connection and issue the close on its
1.2549 + own side.
1.2550 +
1.2551 + 5.3. COMMANDS
1.2552 +
1.2553 + The commands are Telnet character strings transmitted over the
1.2554 + control connections as described in the Section on FTP Commands.
1.2555 + The command functions and semantics are described in the Section
1.2556 + on Access Control Commands, Transfer Parameter Commands, FTP
1.2557 + Service Commands, and Miscellaneous Commands. The command syntax
1.2558 + is specified here.
1.2559 +
1.2560 + The commands begin with a command code followed by an argument
1.2561 + field. The command codes are four or fewer alphabetic characters.
1.2562 + Upper and lower case alphabetic characters are to be treated
1.2563 + identically. Thus, any of the following may represent the
1.2564 + retrieve command:
1.2565 +
1.2566 +
1.2567 +Postel & Reynolds [Page 45]
1.2568 +
1.2569 +
1.2570 +
1.2571 +RFC 959 October 1985
1.2572 +File Transfer Protocol
1.2573 +
1.2574 +
1.2575 + RETR Retr retr ReTr rETr
1.2576 +
1.2577 + This also applies to any symbols representing parameter values,
1.2578 + such as A or a for ASCII TYPE. The command codes and the argument
1.2579 + fields are separated by one or more spaces.
1.2580 +
1.2581 + The argument field consists of a variable length character string
1.2582 + ending with the character sequence <CRLF> (Carriage Return, Line
1.2583 + Feed) for NVT-ASCII representation; for other negotiated languages
1.2584 + a different end of line character might be used. It should be
1.2585 + noted that the server is to take no action until the end of line
1.2586 + code is received.
1.2587 +
1.2588 + The syntax is specified below in NVT-ASCII. All characters in the
1.2589 + argument field are ASCII characters including any ASCII
1.2590 + represented decimal integers. Square brackets denote an optional
1.2591 + argument field. If the option is not taken, the appropriate
1.2592 + default is implied.
1.2593 +
1.2594 +
1.2595 +
1.2596 +
1.2597 +
1.2598 +
1.2599 +
1.2600 +
1.2601 +
1.2602 +
1.2603 +
1.2604 +
1.2605 +
1.2606 +
1.2607 +
1.2608 +
1.2609 +
1.2610 +
1.2611 +
1.2612 +
1.2613 +
1.2614 +
1.2615 +
1.2616 +
1.2617 +
1.2618 +
1.2619 +
1.2620 +
1.2621 +
1.2622 +
1.2623 +
1.2624 +Postel & Reynolds [Page 46]
1.2625 +
1.2626 +
1.2627 +
1.2628 +RFC 959 October 1985
1.2629 +File Transfer Protocol
1.2630 +
1.2631 +
1.2632 + 5.3.1. FTP COMMANDS
1.2633 +
1.2634 + The following are the FTP commands:
1.2635 +
1.2636 + USER <SP> <username> <CRLF>
1.2637 + PASS <SP> <password> <CRLF>
1.2638 + ACCT <SP> <account-information> <CRLF>
1.2639 + CWD <SP> <pathname> <CRLF>
1.2640 + CDUP <CRLF>
1.2641 + SMNT <SP> <pathname> <CRLF>
1.2642 + QUIT <CRLF>
1.2643 + REIN <CRLF>
1.2644 + PORT <SP> <host-port> <CRLF>
1.2645 + PASV <CRLF>
1.2646 + TYPE <SP> <type-code> <CRLF>
1.2647 + STRU <SP> <structure-code> <CRLF>
1.2648 + MODE <SP> <mode-code> <CRLF>
1.2649 + RETR <SP> <pathname> <CRLF>
1.2650 + STOR <SP> <pathname> <CRLF>
1.2651 + STOU <CRLF>
1.2652 + APPE <SP> <pathname> <CRLF>
1.2653 + ALLO <SP> <decimal-integer>
1.2654 + [<SP> R <SP> <decimal-integer>] <CRLF>
1.2655 + REST <SP> <marker> <CRLF>
1.2656 + RNFR <SP> <pathname> <CRLF>
1.2657 + RNTO <SP> <pathname> <CRLF>
1.2658 + ABOR <CRLF>
1.2659 + DELE <SP> <pathname> <CRLF>
1.2660 + RMD <SP> <pathname> <CRLF>
1.2661 + MKD <SP> <pathname> <CRLF>
1.2662 + PWD <CRLF>
1.2663 + LIST [<SP> <pathname>] <CRLF>
1.2664 + NLST [<SP> <pathname>] <CRLF>
1.2665 + SITE <SP> <string> <CRLF>
1.2666 + SYST <CRLF>
1.2667 + STAT [<SP> <pathname>] <CRLF>
1.2668 + HELP [<SP> <string>] <CRLF>
1.2669 + NOOP <CRLF>
1.2670 +
1.2671 +
1.2672 +
1.2673 +
1.2674 +
1.2675 +
1.2676 +
1.2677 +
1.2678 +
1.2679 +
1.2680 +
1.2681 +Postel & Reynolds [Page 47]
1.2682 +
1.2683 +
1.2684 +
1.2685 +RFC 959 October 1985
1.2686 +File Transfer Protocol
1.2687 +
1.2688 +
1.2689 + 5.3.2. FTP COMMAND ARGUMENTS
1.2690 +
1.2691 + The syntax of the above argument fields (using BNF notation
1.2692 + where applicable) is:
1.2693 +
1.2694 + <username> ::= <string>
1.2695 + <password> ::= <string>
1.2696 + <account-information> ::= <string>
1.2697 + <string> ::= <char> | <char><string>
1.2698 + <char> ::= any of the 128 ASCII characters except <CR> and
1.2699 + <LF>
1.2700 + <marker> ::= <pr-string>
1.2701 + <pr-string> ::= <pr-char> | <pr-char><pr-string>
1.2702 + <pr-char> ::= printable characters, any
1.2703 + ASCII code 33 through 126
1.2704 + <byte-size> ::= <number>
1.2705 + <host-port> ::= <host-number>,<port-number>
1.2706 + <host-number> ::= <number>,<number>,<number>,<number>
1.2707 + <port-number> ::= <number>,<number>
1.2708 + <number> ::= any decimal integer 1 through 255
1.2709 + <form-code> ::= N | T | C
1.2710 + <type-code> ::= A [<sp> <form-code>]
1.2711 + | E [<sp> <form-code>]
1.2712 + | I
1.2713 + | L <sp> <byte-size>
1.2714 + <structure-code> ::= F | R | P
1.2715 + <mode-code> ::= S | B | C
1.2716 + <pathname> ::= <string>
1.2717 + <decimal-integer> ::= any decimal integer
1.2718 +
1.2719 +
1.2720 +
1.2721 +
1.2722 +
1.2723 +
1.2724 +
1.2725 +
1.2726 +
1.2727 +
1.2728 +
1.2729 +
1.2730 +
1.2731 +
1.2732 +
1.2733 +
1.2734 +
1.2735 +
1.2736 +
1.2737 +
1.2738 +Postel & Reynolds [Page 48]
1.2739 +
1.2740 +
1.2741 +
1.2742 +RFC 959 October 1985
1.2743 +File Transfer Protocol
1.2744 +
1.2745 +
1.2746 + 5.4. SEQUENCING OF COMMANDS AND REPLIES
1.2747 +
1.2748 + The communication between the user and server is intended to be an
1.2749 + alternating dialogue. As such, the user issues an FTP command and
1.2750 + the server responds with a prompt primary reply. The user should
1.2751 + wait for this initial primary success or failure response before
1.2752 + sending further commands.
1.2753 +
1.2754 + Certain commands require a second reply for which the user should
1.2755 + also wait. These replies may, for example, report on the progress
1.2756 + or completion of file transfer or the closing of the data
1.2757 + connection. They are secondary replies to file transfer commands.
1.2758 +
1.2759 + One important group of informational replies is the connection
1.2760 + greetings. Under normal circumstances, a server will send a 220
1.2761 + reply, "awaiting input", when the connection is completed. The
1.2762 + user should wait for this greeting message before sending any
1.2763 + commands. If the server is unable to accept input right away, a
1.2764 + 120 "expected delay" reply should be sent immediately and a 220
1.2765 + reply when ready. The user will then know not to hang up if there
1.2766 + is a delay.
1.2767 +
1.2768 + Spontaneous Replies
1.2769 +
1.2770 + Sometimes "the system" spontaneously has a message to be sent
1.2771 + to a user (usually all users). For example, "System going down
1.2772 + in 15 minutes". There is no provision in FTP for such
1.2773 + spontaneous information to be sent from the server to the user.
1.2774 + It is recommended that such information be queued in the
1.2775 + server-PI and delivered to the user-PI in the next reply
1.2776 + (possibly making it a multi-line reply).
1.2777 +
1.2778 + The table below lists alternative success and failure replies for
1.2779 + each command. These must be strictly adhered to; a server may
1.2780 + substitute text in the replies, but the meaning and action implied
1.2781 + by the code numbers and by the specific command reply sequence
1.2782 + cannot be altered.
1.2783 +
1.2784 + Command-Reply Sequences
1.2785 +
1.2786 + In this section, the command-reply sequence is presented. Each
1.2787 + command is listed with its possible replies; command groups are
1.2788 + listed together. Preliminary replies are listed first (with
1.2789 + their succeeding replies indented and under them), then
1.2790 + positive and negative completion, and finally intermediary
1.2791 +
1.2792 +
1.2793 +
1.2794 +
1.2795 +Postel & Reynolds [Page 49]
1.2796 +
1.2797 +
1.2798 +
1.2799 +RFC 959 October 1985
1.2800 +File Transfer Protocol
1.2801 +
1.2802 +
1.2803 + replies with the remaining commands from the sequence
1.2804 + following. This listing forms the basis for the state
1.2805 + diagrams, which will be presented separately.
1.2806 +
1.2807 + Connection Establishment
1.2808 + 120
1.2809 + 220
1.2810 + 220
1.2811 + 421
1.2812 + Login
1.2813 + USER
1.2814 + 230
1.2815 + 530
1.2816 + 500, 501, 421
1.2817 + 331, 332
1.2818 + PASS
1.2819 + 230
1.2820 + 202
1.2821 + 530
1.2822 + 500, 501, 503, 421
1.2823 + 332
1.2824 + ACCT
1.2825 + 230
1.2826 + 202
1.2827 + 530
1.2828 + 500, 501, 503, 421
1.2829 + CWD
1.2830 + 250
1.2831 + 500, 501, 502, 421, 530, 550
1.2832 + CDUP
1.2833 + 200
1.2834 + 500, 501, 502, 421, 530, 550
1.2835 + SMNT
1.2836 + 202, 250
1.2837 + 500, 501, 502, 421, 530, 550
1.2838 + Logout
1.2839 + REIN
1.2840 + 120
1.2841 + 220
1.2842 + 220
1.2843 + 421
1.2844 + 500, 502
1.2845 + QUIT
1.2846 + 221
1.2847 + 500
1.2848 +
1.2849 +
1.2850 +
1.2851 +
1.2852 +Postel & Reynolds [Page 50]
1.2853 +
1.2854 +
1.2855 +
1.2856 +RFC 959 October 1985
1.2857 +File Transfer Protocol
1.2858 +
1.2859 +
1.2860 + Transfer parameters
1.2861 + PORT
1.2862 + 200
1.2863 + 500, 501, 421, 530
1.2864 + PASV
1.2865 + 227
1.2866 + 500, 501, 502, 421, 530
1.2867 + MODE
1.2868 + 200
1.2869 + 500, 501, 504, 421, 530
1.2870 + TYPE
1.2871 + 200
1.2872 + 500, 501, 504, 421, 530
1.2873 + STRU
1.2874 + 200
1.2875 + 500, 501, 504, 421, 530
1.2876 + File action commands
1.2877 + ALLO
1.2878 + 200
1.2879 + 202
1.2880 + 500, 501, 504, 421, 530
1.2881 + REST
1.2882 + 500, 501, 502, 421, 530
1.2883 + 350
1.2884 + STOR
1.2885 + 125, 150
1.2886 + (110)
1.2887 + 226, 250
1.2888 + 425, 426, 451, 551, 552
1.2889 + 532, 450, 452, 553
1.2890 + 500, 501, 421, 530
1.2891 + STOU
1.2892 + 125, 150
1.2893 + (110)
1.2894 + 226, 250
1.2895 + 425, 426, 451, 551, 552
1.2896 + 532, 450, 452, 553
1.2897 + 500, 501, 421, 530
1.2898 + RETR
1.2899 + 125, 150
1.2900 + (110)
1.2901 + 226, 250
1.2902 + 425, 426, 451
1.2903 + 450, 550
1.2904 + 500, 501, 421, 530
1.2905 +
1.2906 +
1.2907 +
1.2908 +
1.2909 +Postel & Reynolds [Page 51]
1.2910 +
1.2911 +
1.2912 +
1.2913 +RFC 959 October 1985
1.2914 +File Transfer Protocol
1.2915 +
1.2916 +
1.2917 + LIST
1.2918 + 125, 150
1.2919 + 226, 250
1.2920 + 425, 426, 451
1.2921 + 450
1.2922 + 500, 501, 502, 421, 530
1.2923 + NLST
1.2924 + 125, 150
1.2925 + 226, 250
1.2926 + 425, 426, 451
1.2927 + 450
1.2928 + 500, 501, 502, 421, 530
1.2929 + APPE
1.2930 + 125, 150
1.2931 + (110)
1.2932 + 226, 250
1.2933 + 425, 426, 451, 551, 552
1.2934 + 532, 450, 550, 452, 553
1.2935 + 500, 501, 502, 421, 530
1.2936 + RNFR
1.2937 + 450, 550
1.2938 + 500, 501, 502, 421, 530
1.2939 + 350
1.2940 + RNTO
1.2941 + 250
1.2942 + 532, 553
1.2943 + 500, 501, 502, 503, 421, 530
1.2944 + DELE
1.2945 + 250
1.2946 + 450, 550
1.2947 + 500, 501, 502, 421, 530
1.2948 + RMD
1.2949 + 250
1.2950 + 500, 501, 502, 421, 530, 550
1.2951 + MKD
1.2952 + 257
1.2953 + 500, 501, 502, 421, 530, 550
1.2954 + PWD
1.2955 + 257
1.2956 + 500, 501, 502, 421, 550
1.2957 + ABOR
1.2958 + 225, 226
1.2959 + 500, 501, 502, 421
1.2960 +
1.2961 +
1.2962 +
1.2963 +
1.2964 +
1.2965 +
1.2966 +Postel & Reynolds [Page 52]
1.2967 +
1.2968 +
1.2969 +
1.2970 +RFC 959 October 1985
1.2971 +File Transfer Protocol
1.2972 +
1.2973 +
1.2974 + Informational commands
1.2975 + SYST
1.2976 + 215
1.2977 + 500, 501, 502, 421
1.2978 + STAT
1.2979 + 211, 212, 213
1.2980 + 450
1.2981 + 500, 501, 502, 421, 530
1.2982 + HELP
1.2983 + 211, 214
1.2984 + 500, 501, 502, 421
1.2985 + Miscellaneous commands
1.2986 + SITE
1.2987 + 200
1.2988 + 202
1.2989 + 500, 501, 530
1.2990 + NOOP
1.2991 + 200
1.2992 + 500 421
1.2993 +
1.2994 +
1.2995 +
1.2996 +
1.2997 +
1.2998 +
1.2999 +
1.3000 +
1.3001 +
1.3002 +
1.3003 +
1.3004 +
1.3005 +
1.3006 +
1.3007 +
1.3008 +
1.3009 +
1.3010 +
1.3011 +
1.3012 +
1.3013 +
1.3014 +
1.3015 +
1.3016 +
1.3017 +
1.3018 +
1.3019 +
1.3020 +
1.3021 +
1.3022 +
1.3023 +Postel & Reynolds [Page 53]
1.3024 +
1.3025 +
1.3026 +
1.3027 +RFC 959 October 1985
1.3028 +File Transfer Protocol
1.3029 +
1.3030 +
1.3031 +6. STATE DIAGRAMS
1.3032 +
1.3033 + Here we present state diagrams for a very simple minded FTP
1.3034 + implementation. Only the first digit of the reply codes is used.
1.3035 + There is one state diagram for each group of FTP commands or command
1.3036 + sequences.
1.3037 +
1.3038 + The command groupings were determined by constructing a model for
1.3039 + each command then collecting together the commands with structurally
1.3040 + identical models.
1.3041 +
1.3042 + For each command or command sequence there are three possible
1.3043 + outcomes: success (S), failure (F), and error (E). In the state
1.3044 + diagrams below we use the symbol B for "begin", and the symbol W for
1.3045 + "wait for reply".
1.3046 +
1.3047 + We first present the diagram that represents the largest group of FTP
1.3048 + commands:
1.3049 +
1.3050 +
1.3051 + 1,3 +---+
1.3052 + ----------->| E |
1.3053 + | +---+
1.3054 + |
1.3055 + +---+ cmd +---+ 2 +---+
1.3056 + | B |---------->| W |---------->| S |
1.3057 + +---+ +---+ +---+
1.3058 + |
1.3059 + | 4,5 +---+
1.3060 + ----------->| F |
1.3061 + +---+
1.3062 +
1.3063 +
1.3064 + This diagram models the commands:
1.3065 +
1.3066 + ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
1.3067 + QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE.
1.3068 +
1.3069 +
1.3070 +
1.3071 +
1.3072 +
1.3073 +
1.3074 +
1.3075 +
1.3076 +
1.3077 +
1.3078 +
1.3079 +
1.3080 +Postel & Reynolds [Page 54]
1.3081 +
1.3082 +
1.3083 +
1.3084 +RFC 959 October 1985
1.3085 +File Transfer Protocol
1.3086 +
1.3087 +
1.3088 + The other large group of commands is represented by a very similar
1.3089 + diagram:
1.3090 +
1.3091 +
1.3092 + 3 +---+
1.3093 + ----------->| E |
1.3094 + | +---+
1.3095 + |
1.3096 + +---+ cmd +---+ 2 +---+
1.3097 + | B |---------->| W |---------->| S |
1.3098 + +---+ --->+---+ +---+
1.3099 + | | |
1.3100 + | | | 4,5 +---+
1.3101 + | 1 | ----------->| F |
1.3102 + ----- +---+
1.3103 +
1.3104 +
1.3105 + This diagram models the commands:
1.3106 +
1.3107 + APPE, LIST, NLST, REIN, RETR, STOR, and STOU.
1.3108 +
1.3109 + Note that this second model could also be used to represent the first
1.3110 + group of commands, the only difference being that in the first group
1.3111 + the 100 series replies are unexpected and therefore treated as error,
1.3112 + while the second group expects (some may require) 100 series replies.
1.3113 + Remember that at most, one 100 series reply is allowed per command.
1.3114 +
1.3115 + The remaining diagrams model command sequences, perhaps the simplest
1.3116 + of these is the rename sequence:
1.3117 +
1.3118 +
1.3119 + +---+ RNFR +---+ 1,2 +---+
1.3120 + | B |---------->| W |---------->| E |
1.3121 + +---+ +---+ -->+---+
1.3122 + | | |
1.3123 + 3 | | 4,5 |
1.3124 + -------------- ------ |
1.3125 + | | | +---+
1.3126 + | ------------->| S |
1.3127 + | | 1,3 | | +---+
1.3128 + | 2| --------
1.3129 + | | | |
1.3130 + V | | |
1.3131 + +---+ RNTO +---+ 4,5 ----->+---+
1.3132 + | |---------->| W |---------->| F |
1.3133 + +---+ +---+ +---+
1.3134 +
1.3135 +
1.3136 +
1.3137 +Postel & Reynolds [Page 55]
1.3138 +
1.3139 +
1.3140 +
1.3141 +RFC 959 October 1985
1.3142 +File Transfer Protocol
1.3143 +
1.3144 +
1.3145 + The next diagram is a simple model of the Restart command:
1.3146 +
1.3147 +
1.3148 + +---+ REST +---+ 1,2 +---+
1.3149 + | B |---------->| W |---------->| E |
1.3150 + +---+ +---+ -->+---+
1.3151 + | | |
1.3152 + 3 | | 4,5 |
1.3153 + -------------- ------ |
1.3154 + | | | +---+
1.3155 + | ------------->| S |
1.3156 + | | 3 | | +---+
1.3157 + | 2| --------
1.3158 + | | | |
1.3159 + V | | |
1.3160 + +---+ cmd +---+ 4,5 ----->+---+
1.3161 + | |---------->| W |---------->| F |
1.3162 + +---+ -->+---+ +---+
1.3163 + | |
1.3164 + | 1 |
1.3165 + ------
1.3166 +
1.3167 +
1.3168 + Where "cmd" is APPE, STOR, or RETR.
1.3169 +
1.3170 + We note that the above three models are similar. The Restart differs
1.3171 + from the Rename two only in the treatment of 100 series replies at
1.3172 + the second stage, while the second group expects (some may require)
1.3173 + 100 series replies. Remember that at most, one 100 series reply is
1.3174 + allowed per command.
1.3175 +
1.3176 +
1.3177 +
1.3178 +
1.3179 +
1.3180 +
1.3181 +
1.3182 +
1.3183 +
1.3184 +
1.3185 +
1.3186 +
1.3187 +
1.3188 +
1.3189 +
1.3190 +
1.3191 +
1.3192 +
1.3193 +
1.3194 +Postel & Reynolds [Page 56]
1.3195 +
1.3196 +
1.3197 +
1.3198 +RFC 959 October 1985
1.3199 +File Transfer Protocol
1.3200 +
1.3201 +
1.3202 + The most complicated diagram is for the Login sequence:
1.3203 +
1.3204 +
1.3205 + 1
1.3206 + +---+ USER +---+------------->+---+
1.3207 + | B |---------->| W | 2 ---->| E |
1.3208 + +---+ +---+------ | -->+---+
1.3209 + | | | | |
1.3210 + 3 | | 4,5 | | |
1.3211 + -------------- ----- | | |
1.3212 + | | | | |
1.3213 + | | | | |
1.3214 + | --------- |
1.3215 + | 1| | | |
1.3216 + V | | | |
1.3217 + +---+ PASS +---+ 2 | ------>+---+
1.3218 + | |---------->| W |------------->| S |
1.3219 + +---+ +---+ ---------->+---+
1.3220 + | | | | |
1.3221 + 3 | |4,5| | |
1.3222 + -------------- -------- |
1.3223 + | | | | |
1.3224 + | | | | |
1.3225 + | -----------
1.3226 + | 1,3| | | |
1.3227 + V | 2| | |
1.3228 + +---+ ACCT +---+-- | ----->+---+
1.3229 + | |---------->| W | 4,5 -------->| F |
1.3230 + +---+ +---+------------->+---+
1.3231 +
1.3232 +
1.3233 +
1.3234 +
1.3235 +
1.3236 +
1.3237 +
1.3238 +
1.3239 +
1.3240 +
1.3241 +
1.3242 +
1.3243 +
1.3244 +
1.3245 +
1.3246 +
1.3247 +
1.3248 +
1.3249 +
1.3250 +
1.3251 +Postel & Reynolds [Page 57]
1.3252 +
1.3253 +
1.3254 +
1.3255 +RFC 959 October 1985
1.3256 +File Transfer Protocol
1.3257 +
1.3258 +
1.3259 + Finally, we present a generalized diagram that could be used to model
1.3260 + the command and reply interchange:
1.3261 +
1.3262 +
1.3263 + ------------------------------------
1.3264 + | |
1.3265 + Begin | |
1.3266 + | V |
1.3267 + | +---+ cmd +---+ 2 +---+ |
1.3268 + -->| |------->| |---------->| | |
1.3269 + | | | W | | S |-----|
1.3270 + -->| | -->| |----- | | |
1.3271 + | +---+ | +---+ 4,5 | +---+ |
1.3272 + | | | | | | |
1.3273 + | | | 1| |3 | +---+ |
1.3274 + | | | | | | | | |
1.3275 + | | ---- | ---->| F |-----
1.3276 + | | | | |
1.3277 + | | | +---+
1.3278 + -------------------
1.3279 + |
1.3280 + |
1.3281 + V
1.3282 + End
1.3283 +
1.3284 +
1.3285 +
1.3286 +
1.3287 +
1.3288 +
1.3289 +
1.3290 +
1.3291 +
1.3292 +
1.3293 +
1.3294 +
1.3295 +
1.3296 +
1.3297 +
1.3298 +
1.3299 +
1.3300 +
1.3301 +
1.3302 +
1.3303 +
1.3304 +
1.3305 +
1.3306 +
1.3307 +
1.3308 +Postel & Reynolds [Page 58]
1.3309 +
1.3310 +
1.3311 +
1.3312 +RFC 959 October 1985
1.3313 +File Transfer Protocol
1.3314 +
1.3315 +
1.3316 +7. TYPICAL FTP SCENARIO
1.3317 +
1.3318 + User at host U wanting to transfer files to/from host S:
1.3319 +
1.3320 + In general, the user will communicate to the server via a mediating
1.3321 + user-FTP process. The following may be a typical scenario. The
1.3322 + user-FTP prompts are shown in parentheses, '---->' represents
1.3323 + commands from host U to host S, and '<----' represents replies from
1.3324 + host S to host U.
1.3325 +
1.3326 + LOCAL COMMANDS BY USER ACTION INVOLVED
1.3327 +
1.3328 + ftp (host) multics<CR> Connect to host S, port L,
1.3329 + establishing control connections.
1.3330 + <---- 220 Service ready <CRLF>.
1.3331 + username Doe <CR> USER Doe<CRLF>---->
1.3332 + <---- 331 User name ok,
1.3333 + need password<CRLF>.
1.3334 + password mumble <CR> PASS mumble<CRLF>---->
1.3335 + <---- 230 User logged in<CRLF>.
1.3336 + retrieve (local type) ASCII<CR>
1.3337 + (local pathname) test 1 <CR> User-FTP opens local file in ASCII.
1.3338 + (for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
1.3339 + <---- 150 File status okay;
1.3340 + about to open data
1.3341 + connection<CRLF>.
1.3342 + Server makes data connection
1.3343 + to port U.
1.3344 +
1.3345 + <---- 226 Closing data connection,
1.3346 + file transfer successful<CRLF>.
1.3347 + type Image<CR> TYPE I<CRLF> ---->
1.3348 + <---- 200 Command OK<CRLF>
1.3349 + store (local type) image<CR>
1.3350 + (local pathname) file dump<CR> User-FTP opens local file in Image.
1.3351 + (for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
1.3352 + <---- 550 Access denied<CRLF>
1.3353 + terminate QUIT <CRLF> ---->
1.3354 + Server closes all
1.3355 + connections.
1.3356 +
1.3357 +8. CONNECTION ESTABLISHMENT
1.3358 +
1.3359 + The FTP control connection is established via TCP between the user
1.3360 + process port U and the server process port L. This protocol is
1.3361 + assigned the service port 21 (25 octal), that is L=21.
1.3362 +
1.3363 +
1.3364 +
1.3365 +Postel & Reynolds [Page 59]
1.3366 +
1.3367 +
1.3368 +
1.3369 +RFC 959 October 1985
1.3370 +File Transfer Protocol
1.3371 +
1.3372 +
1.3373 +APPENDIX I - PAGE STRUCTURE
1.3374 +
1.3375 + The need for FTP to support page structure derives principally from
1.3376 + the need to support efficient transmission of files between TOPS-20
1.3377 + systems, particularly the files used by NLS.
1.3378 +
1.3379 + The file system of TOPS-20 is based on the concept of pages. The
1.3380 + operating system is most efficient at manipulating files as pages.
1.3381 + The operating system provides an interface to the file system so that
1.3382 + many applications view files as sequential streams of characters.
1.3383 + However, a few applications use the underlying page structures
1.3384 + directly, and some of these create holey files.
1.3385 +
1.3386 + A TOPS-20 disk file consists of four things: a pathname, a page
1.3387 + table, a (possibly empty) set of pages, and a set of attributes.
1.3388 +
1.3389 + The pathname is specified in the RETR or STOR command. It includes
1.3390 + the directory name, file name, file name extension, and generation
1.3391 + number.
1.3392 +
1.3393 + The page table contains up to 2**18 entries. Each entry may be
1.3394 + EMPTY, or may point to a page. If it is not empty, there are also
1.3395 + some page-specific access bits; not all pages of a file need have the
1.3396 + same access protection.
1.3397 +
1.3398 + A page is a contiguous set of 512 words of 36 bits each.
1.3399 +
1.3400 + The attributes of the file, in the File Descriptor Block (FDB),
1.3401 + contain such things as creation time, write time, read time, writer's
1.3402 + byte-size, end-of-file pointer, count of reads and writes, backup
1.3403 + system tape numbers, etc.
1.3404 +
1.3405 + Note that there is NO requirement that entries in the page table be
1.3406 + contiguous. There may be empty page table slots between occupied
1.3407 + ones. Also, the end of file pointer is simply a number. There is no
1.3408 + requirement that it in fact point at the "last" datum in the file.
1.3409 + Ordinary sequential I/O calls in TOPS-20 will cause the end of file
1.3410 + pointer to be left after the last datum written, but other operations
1.3411 + may cause it not to be so, if a particular programming system so
1.3412 + requires.
1.3413 +
1.3414 + In fact, in both of these special cases, "holey" files and
1.3415 + end-of-file pointers NOT at the end of the file, occur with NLS data
1.3416 + files.
1.3417 +
1.3418 +
1.3419 +
1.3420 +
1.3421 +
1.3422 +Postel & Reynolds [Page 60]
1.3423 +
1.3424 +
1.3425 +
1.3426 +RFC 959 October 1985
1.3427 +File Transfer Protocol
1.3428 +
1.3429 +
1.3430 + The TOPS-20 paged files can be sent with the FTP transfer parameters:
1.3431 + TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).
1.3432 +
1.3433 + Each page of information has a header. Each header field, which is a
1.3434 + logical byte, is a TOPS-20 word, since the TYPE is L 36.
1.3435 +
1.3436 + The header fields are:
1.3437 +
1.3438 + Word 0: Header Length.
1.3439 +
1.3440 + The header length is 5.
1.3441 +
1.3442 + Word 1: Page Index.
1.3443 +
1.3444 + If the data is a disk file page, this is the number of that
1.3445 + page in the file's page map. Empty pages (holes) in the file
1.3446 + are simply not sent. Note that a hole is NOT the same as a
1.3447 + page of zeros.
1.3448 +
1.3449 + Word 2: Data Length.
1.3450 +
1.3451 + The number of data words in this page, following the header.
1.3452 + Thus, the total length of the transmission unit is the Header
1.3453 + Length plus the Data Length.
1.3454 +
1.3455 + Word 3: Page Type.
1.3456 +
1.3457 + A code for what type of chunk this is. A data page is type 3,
1.3458 + the FDB page is type 2.
1.3459 +
1.3460 + Word 4: Page Access Control.
1.3461 +
1.3462 + The access bits associated with the page in the file's page
1.3463 + map. (This full word quantity is put into AC2 of an SPACS by
1.3464 + the program reading from net to disk.)
1.3465 +
1.3466 + After the header are Data Length data words. Data Length is
1.3467 + currently either 512 for a data page or 31 for an FDB. Trailing
1.3468 + zeros in a disk file page may be discarded, making Data Length less
1.3469 + than 512 in that case.
1.3470 +
1.3471 +
1.3472 +
1.3473 +
1.3474 +
1.3475 +
1.3476 +
1.3477 +
1.3478 +
1.3479 +Postel & Reynolds [Page 61]
1.3480 +
1.3481 +
1.3482 +
1.3483 +RFC 959 October 1985
1.3484 +File Transfer Protocol
1.3485 +
1.3486 +
1.3487 +APPENDIX II - DIRECTORY COMMANDS
1.3488 +
1.3489 + Since UNIX has a tree-like directory structure in which directories
1.3490 + are as easy to manipulate as ordinary files, it is useful to expand
1.3491 + the FTP servers on these machines to include commands which deal with
1.3492 + the creation of directories. Since there are other hosts on the
1.3493 + ARPA-Internet which have tree-like directories (including TOPS-20 and
1.3494 + Multics), these commands are as general as possible.
1.3495 +
1.3496 + Four directory commands have been added to FTP:
1.3497 +
1.3498 + MKD pathname
1.3499 +
1.3500 + Make a directory with the name "pathname".
1.3501 +
1.3502 + RMD pathname
1.3503 +
1.3504 + Remove the directory with the name "pathname".
1.3505 +
1.3506 + PWD
1.3507 +
1.3508 + Print the current working directory name.
1.3509 +
1.3510 + CDUP
1.3511 +
1.3512 + Change to the parent of the current working directory.
1.3513 +
1.3514 + The "pathname" argument should be created (removed) as a
1.3515 + subdirectory of the current working directory, unless the "pathname"
1.3516 + string contains sufficient information to specify otherwise to the
1.3517 + server, e.g., "pathname" is an absolute pathname (in UNIX and
1.3518 + Multics), or pathname is something like "<abso.lute.path>" to
1.3519 + TOPS-20.
1.3520 +
1.3521 + REPLY CODES
1.3522 +
1.3523 + The CDUP command is a special case of CWD, and is included to
1.3524 + simplify the implementation of programs for transferring directory
1.3525 + trees between operating systems having different syntaxes for
1.3526 + naming the parent directory. The reply codes for CDUP be
1.3527 + identical to the reply codes of CWD.
1.3528 +
1.3529 + The reply codes for RMD be identical to the reply codes for its
1.3530 + file analogue, DELE.
1.3531 +
1.3532 + The reply codes for MKD, however, are a bit more complicated. A
1.3533 + freshly created directory will probably be the object of a future
1.3534 +
1.3535 +
1.3536 +Postel & Reynolds [Page 62]
1.3537 +
1.3538 +
1.3539 +
1.3540 +RFC 959 October 1985
1.3541 +File Transfer Protocol
1.3542 +
1.3543 +
1.3544 + CWD command. Unfortunately, the argument to MKD may not always be
1.3545 + a suitable argument for CWD. This is the case, for example, when
1.3546 + a TOPS-20 subdirectory is created by giving just the subdirectory
1.3547 + name. That is, with a TOPS-20 server FTP, the command sequence
1.3548 +
1.3549 + MKD MYDIR
1.3550 + CWD MYDIR
1.3551 +
1.3552 + will fail. The new directory may only be referred to by its
1.3553 + "absolute" name; e.g., if the MKD command above were issued while
1.3554 + connected to the directory <DFRANKLIN>, the new subdirectory
1.3555 + could only be referred to by the name <DFRANKLIN.MYDIR>.
1.3556 +
1.3557 + Even on UNIX and Multics, however, the argument given to MKD may
1.3558 + not be suitable. If it is a "relative" pathname (i.e., a pathname
1.3559 + which is interpreted relative to the current directory), the user
1.3560 + would need to be in the same current directory in order to reach
1.3561 + the subdirectory. Depending on the application, this may be
1.3562 + inconvenient. It is not very robust in any case.
1.3563 +
1.3564 + To solve these problems, upon successful completion of an MKD
1.3565 + command, the server should return a line of the form:
1.3566 +
1.3567 + 257<space>"<directory-name>"<space><commentary>
1.3568 +
1.3569 + That is, the server will tell the user what string to use when
1.3570 + referring to the created directory. The directory name can
1.3571 + contain any character; embedded double-quotes should be escaped by
1.3572 + double-quotes (the "quote-doubling" convention).
1.3573 +
1.3574 + For example, a user connects to the directory /usr/dm, and creates
1.3575 + a subdirectory, named pathname:
1.3576 +
1.3577 + CWD /usr/dm
1.3578 + 200 directory changed to /usr/dm
1.3579 + MKD pathname
1.3580 + 257 "/usr/dm/pathname" directory created
1.3581 +
1.3582 + An example with an embedded double quote:
1.3583 +
1.3584 + MKD foo"bar
1.3585 + 257 "/usr/dm/foo""bar" directory created
1.3586 + CWD /usr/dm/foo"bar
1.3587 + 200 directory changed to /usr/dm/foo"bar
1.3588 +
1.3589 +
1.3590 +
1.3591 +
1.3592 +
1.3593 +Postel & Reynolds [Page 63]
1.3594 +
1.3595 +
1.3596 +
1.3597 +RFC 959 October 1985
1.3598 +File Transfer Protocol
1.3599 +
1.3600 +
1.3601 + The prior existence of a subdirectory with the same name is an
1.3602 + error, and the server must return an "access denied" error reply
1.3603 + in that case.
1.3604 +
1.3605 + CWD /usr/dm
1.3606 + 200 directory changed to /usr/dm
1.3607 + MKD pathname
1.3608 + 521-"/usr/dm/pathname" directory already exists;
1.3609 + 521 taking no action.
1.3610 +
1.3611 + The failure replies for MKD are analogous to its file creating
1.3612 + cousin, STOR. Also, an "access denied" return is given if a file
1.3613 + name with the same name as the subdirectory will conflict with the
1.3614 + creation of the subdirectory (this is a problem on UNIX, but
1.3615 + shouldn't be one on TOPS-20).
1.3616 +
1.3617 + Essentially because the PWD command returns the same type of
1.3618 + information as the successful MKD command, the successful PWD
1.3619 + command uses the 257 reply code as well.
1.3620 +
1.3621 + SUBTLETIES
1.3622 +
1.3623 + Because these commands will be most useful in transferring
1.3624 + subtrees from one machine to another, carefully observe that the
1.3625 + argument to MKD is to be interpreted as a sub-directory of the
1.3626 + current working directory, unless it contains enough information
1.3627 + for the destination host to tell otherwise. A hypothetical
1.3628 + example of its use in the TOPS-20 world:
1.3629 +
1.3630 + CWD <some.where>
1.3631 + 200 Working directory changed
1.3632 + MKD overrainbow
1.3633 + 257 "<some.where.overrainbow>" directory created
1.3634 + CWD overrainbow
1.3635 + 431 No such directory
1.3636 + CWD <some.where.overrainbow>
1.3637 + 200 Working directory changed
1.3638 +
1.3639 + CWD <some.where>
1.3640 + 200 Working directory changed to <some.where>
1.3641 + MKD <unambiguous>
1.3642 + 257 "<unambiguous>" directory created
1.3643 + CWD <unambiguous>
1.3644 +
1.3645 + Note that the first example results in a subdirectory of the
1.3646 + connected directory. In contrast, the argument in the second
1.3647 + example contains enough information for TOPS-20 to tell that the
1.3648 +
1.3649 +
1.3650 +Postel & Reynolds [Page 64]
1.3651 +
1.3652 +
1.3653 +
1.3654 +RFC 959 October 1985
1.3655 +File Transfer Protocol
1.3656 +
1.3657 +
1.3658 + <unambiguous> directory is a top-level directory. Note also that
1.3659 + in the first example the user "violated" the protocol by
1.3660 + attempting to access the freshly created directory with a name
1.3661 + other than the one returned by TOPS-20. Problems could have
1.3662 + resulted in this case had there been an <overrainbow> directory;
1.3663 + this is an ambiguity inherent in some TOPS-20 implementations.
1.3664 + Similar considerations apply to the RMD command. The point is
1.3665 + this: except where to do so would violate a host's conventions for
1.3666 + denoting relative versus absolute pathnames, the host should treat
1.3667 + the operands of the MKD and RMD commands as subdirectories. The
1.3668 + 257 reply to the MKD command must always contain the absolute
1.3669 + pathname of the created directory.
1.3670 +
1.3671 +
1.3672 +
1.3673 +
1.3674 +
1.3675 +
1.3676 +
1.3677 +
1.3678 +
1.3679 +
1.3680 +
1.3681 +
1.3682 +
1.3683 +
1.3684 +
1.3685 +
1.3686 +
1.3687 +
1.3688 +
1.3689 +
1.3690 +
1.3691 +
1.3692 +
1.3693 +
1.3694 +
1.3695 +
1.3696 +
1.3697 +
1.3698 +
1.3699 +
1.3700 +
1.3701 +
1.3702 +
1.3703 +
1.3704 +
1.3705 +
1.3706 +
1.3707 +Postel & Reynolds [Page 65]
1.3708 +
1.3709 +
1.3710 +
1.3711 +RFC 959 October 1985
1.3712 +File Transfer Protocol
1.3713 +
1.3714 +
1.3715 +APPENDIX III - RFCs on FTP
1.3716 +
1.3717 + Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
1.3718 + MIT-Project MAC, 16 April 1971.
1.3719 +
1.3720 + Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
1.3721 + Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.
1.3722 +
1.3723 + Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
1.3724 + (NIC 6794), MIT-Project MAC, 23 June 1971.
1.3725 +
1.3726 + Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663),
1.3727 + UCLA/CCN, 29 September 1971.
1.3728 +
1.3729 + Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
1.3730 + (NIC 7813), MIT-Project MAC, 17 November 1971.
1.3731 +
1.3732 + McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
1.3733 + RFC 281 (NIC 8163), BBN, 8 December 1971.
1.3734 +
1.3735 + Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
1.3736 + Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
1.3737 + 25 January 1972.
1.3738 +
1.3739 + Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
1.3740 + MIT-Project MAC, 8 July 1972.
1.3741 +
1.3742 + Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
1.3743 + RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.
1.3744 +
1.3745 + Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
1.3746 + 27 November 1972.
1.3747 +
1.3748 + Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
1.3749 + Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.
1.3750 +
1.3751 + Braden, Bob, "Comments on File Transfer Protocol", RFC 430
1.3752 + (NIC 13299), UCLA/CCN, 7 February 1973.
1.3753 +
1.3754 + Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
1.3755 + RFC 438 (NIC 13770), BBN, 15 January 1973.
1.3756 +
1.3757 + Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN,
1.3758 + 27 February 1973.
1.3759 +
1.3760 + McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN,
1.3761 + 16 February 1973.
1.3762 +
1.3763 +
1.3764 +Postel & Reynolds [Page 66]
1.3765 +
1.3766 +
1.3767 +
1.3768 +RFC 959 October 1985
1.3769 +File Transfer Protocol
1.3770 +
1.3771 +
1.3772 + Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458
1.3773 + (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.
1.3774 +
1.3775 + Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN,
1.3776 + 12 July 1973.
1.3777 +
1.3778 + Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
1.3779 + Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974.
1.3780 +
1.3781 + Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the
1.3782 + File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974.
1.3783 +
1.3784 + Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
1.3785 + "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB,
1.3786 + Ames Research Center, SRI-ARC, 28 February 1974.
1.3787 +
1.3788 + Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463
1.3789 + (NIC 14573), MIT-DMCG, 21 February 1973.
1.3790 +
1.3791 + Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN,
1.3792 + 8 March 1973.
1.3793 +
1.3794 + Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919),
1.3795 + MIT-DMCG, 6 March 1973.
1.3796 +
1.3797 + Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
1.3798 + RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.
1.3799 +
1.3800 + White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
1.3801 + SRI-ARC, 8 March 1973.
1.3802 +
1.3803 + White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
1.3804 + SRI-ARC, 8 March 1973.
1.3805 +
1.3806 + Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506
1.3807 + (NIC 16157), MIT-Multics, 26 June 1973.
1.3808 +
1.3809 + Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
1.3810 + RFC 520 (NIC 16819), Illinois, 25 June 1973.
1.3811 +
1.3812 + Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532
1.3813 + (NIC 17451), UCSD-CC, 22 June 1973.
1.3814 +
1.3815 + Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN,
1.3816 + 15 November 1973.
1.3817 +
1.3818 +
1.3819 +
1.3820 +
1.3821 +Postel & Reynolds [Page 67]
1.3822 +
1.3823 +
1.3824 +
1.3825 +RFC 959 October 1985
1.3826 +File Transfer Protocol
1.3827 +
1.3828 +
1.3829 + McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
1.3830 + Schedule Change", RFC 593 (NIC 20615), BBN and MITRE,
1.3831 + 29 November 1973.
1.3832 +
1.3833 + Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
1.3834 + Service", RFC 630 (NIC 30237), BBN, 10 April 1974.
1.3835 +
1.3836 + Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843),
1.3837 + UCLA/NMC, 5 June 1974.
1.3838 +
1.3839 + Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481),
1.3840 + SU-AI, 10 May 1975.
1.3841 +
1.3842 + Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI,
1.3843 + 28 May 1975.
1.3844 +
1.3845 + Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975.
1.3846 +
1.3847 + Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
1.3848 + 31 October 1977.
1.3849 +
1.3850 + Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
1.3851 + SRI-KL, 30 December 1977.
1.3852 +
1.3853 + Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT,
1.3854 + 10 December 1978.
1.3855 +
1.3856 + Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI,
1.3857 + June 1980.
1.3858 +
1.3859 + Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
1.3860 + Commands", RFC 776, BBN, December 1980.
1.3861 +
1.3862 + Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE,
1.3863 + July 1985.
1.3864 +
1.3865 +
1.3866 +
1.3867 +
1.3868 +
1.3869 +
1.3870 +
1.3871 +
1.3872 +
1.3873 +
1.3874 +
1.3875 +
1.3876 +
1.3877 +
1.3878 +Postel & Reynolds [Page 68]
1.3879 +
1.3880 +
1.3881 +
1.3882 +RFC 959 October 1985
1.3883 +File Transfer Protocol
1.3884 +
1.3885 +
1.3886 +REFERENCES
1.3887 +
1.3888 + [1] Feinler, Elizabeth, "Internet Protocol Transition Workbook",
1.3889 + Network Information Center, SRI International, March 1982.
1.3890 +
1.3891 + [2] Postel, Jon, "Transmission Control Protocol - DARPA Internet
1.3892 + Program Protocol Specification", RFC 793, DARPA, September 1981.
1.3893 +
1.3894 + [3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol
1.3895 + Specification", RFC 854, ISI, May 1983.
1.3896 +
1.3897 + [4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943,
1.3898 + ISI, April 1985.
1.3899 +
1.3900 +
1.3901 +
1.3902 +
1.3903 +
1.3904 +
1.3905 +
1.3906 +
1.3907 +
1.3908 +
1.3909 +
1.3910 +
1.3911 +
1.3912 +
1.3913 +
1.3914 +
1.3915 +
1.3916 +
1.3917 +
1.3918 +
1.3919 +
1.3920 +
1.3921 +
1.3922 +
1.3923 +
1.3924 +
1.3925 +
1.3926 +
1.3927 +
1.3928 +
1.3929 +
1.3930 +
1.3931 +
1.3932 +
1.3933 +
1.3934 +
1.3935 +Postel & Reynolds [Page 69]
1.3936 +
