1 2 3Network Working Group J. Postel 4Request for Comments: 959 J. Reynolds 5 ISI 6Obsoletes RFC: 765 (IEN 149) October 1985 7 8 FILE TRANSFER PROTOCOL (FTP) 9 10 11Status of this Memo 12 13 This memo is the official specification of the File Transfer 14 Protocol (FTP). Distribution of this memo is unlimited. 15 16 The following new optional commands are included in this edition of 17 the specification: 18 19 CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU 20 (Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD 21 (Print Directory), and SYST (System). 22 23 Note that this specification is compatible with the previous edition. 24 251. INTRODUCTION 26 27 The objectives of FTP are 1) to promote sharing of files (computer 28 programs and/or data), 2) to encourage indirect or implicit (via 29 programs) use of remote computers, 3) to shield a user from 30 variations in file storage systems among hosts, and 4) to transfer 31 data reliably and efficiently. FTP, though usable directly by a user 32 at a terminal, is designed mainly for use by programs. 33 34 The attempt in this specification is to satisfy the diverse needs of 35 users of maxi-hosts, mini-hosts, personal workstations, and TACs, 36 with a simple, and easily implemented protocol design. 37 38 This paper assumes knowledge of the Transmission Control Protocol 39 (TCP) [2] and the Telnet Protocol [3]. These documents are contained 40 in the ARPA-Internet protocol handbook [1]. 41 422. OVERVIEW 43 44 In this section, the history, the terminology, and the FTP model are 45 discussed. The terms defined in this section are only those that 46 have special significance in FTP. Some of the terminology is very 47 specific to the FTP model; some readers may wish to turn to the 48 section on the FTP model while reviewing the terminology. 49 50 51 52 53 54 55 56Postel & Reynolds [Page 1] 57 58 59 60RFC 959 October 1985 61File Transfer Protocol 62 63 64 2.1. HISTORY 65 66 FTP has had a long evolution over the years. Appendix III is a 67 chronological compilation of Request for Comments documents 68 relating to FTP. These include the first proposed file transfer 69 mechanisms in 1971 that were developed for implementation on hosts 70 at M.I.T. (RFC 114), plus comments and discussion in RFC 141. 71 72 RFC 172 provided a user-level oriented protocol for file transfer 73 between host computers (including terminal IMPs). A revision of 74 this as RFC 265, restated FTP for additional review, while RFC 281 75 suggested further changes. The use of a "Set Data Type" 76 transaction was proposed in RFC 294 in January 1982. 77 78 RFC 354 obsoleted RFCs 264 and 265. The File Transfer Protocol 79 was now defined as a protocol for file transfer between HOSTs on 80 the ARPANET, with the primary function of FTP defined as 81 transfering files efficiently and reliably among hosts and 82 allowing the convenient use of remote file storage capabilities. 83 RFC 385 further commented on errors, emphasis points, and 84 additions to the protocol, while RFC 414 provided a status report 85 on the working server and user FTPs. RFC 430, issued in 1973, 86 (among other RFCs too numerous to mention) presented further 87 comments on FTP. Finally, an "official" FTP document was 88 published as RFC 454. 89 90 By July 1973, considerable changes from the last versions of FTP 91 were made, but the general structure remained the same. RFC 542 92 was published as a new "official" specification to reflect these 93 changes. However, many implementations based on the older 94 specification were not updated. 95 96 In 1974, RFCs 607 and 614 continued comments on FTP. RFC 624 97 proposed further design changes and minor modifications. In 1975, 98 RFC 686 entitled, "Leaving Well Enough Alone", discussed the 99 differences between all of the early and later versions of FTP. 100 RFC 691 presented a minor revision of RFC 686, regarding the 101 subject of print files. 102 103 Motivated by the transition from the NCP to the TCP as the 104 underlying protocol, a phoenix was born out of all of the above 105 efforts in RFC 765 as the specification of FTP for use on TCP. 106 107 This current edition of the FTP specification is intended to 108 correct some minor documentation errors, to improve the 109 explanation of some protocol features, and to add some new 110 optional commands. 111 112 113Postel & Reynolds [Page 2] 114 115 116 117RFC 959 October 1985 118File Transfer Protocol 119 120 121 In particular, the following new optional commands are included in 122 this edition of the specification: 123 124 CDUP - Change to Parent Directory 125 126 SMNT - Structure Mount 127 128 STOU - Store Unique 129 130 RMD - Remove Directory 131 132 MKD - Make Directory 133 134 PWD - Print Directory 135 136 SYST - System 137 138 This specification is compatible with the previous edition. A 139 program implemented in conformance to the previous specification 140 should automatically be in conformance to this specification. 141 142 2.2. TERMINOLOGY 143 144 ASCII 145 146 The ASCII character set is as defined in the ARPA-Internet 147 Protocol Handbook. In FTP, ASCII characters are defined to be 148 the lower half of an eight-bit code set (i.e., the most 149 significant bit is zero). 150 151 access controls 152 153 Access controls define users' access privileges to the use of a 154 system, and to the files in that system. Access controls are 155 necessary to prevent unauthorized or accidental use of files. 156 It is the prerogative of a server-FTP process to invoke access 157 controls. 158 159 byte size 160 161 There are two byte sizes of interest in FTP: the logical byte 162 size of the file, and the transfer byte size used for the 163 transmission of the data. The transfer byte size is always 8 164 bits. The transfer byte size is not necessarily the byte size 165 in which data is to be stored in a system, nor the logical byte 166 size for interpretation of the structure of the data. 167 168 169 170Postel & Reynolds [Page 3] 171 172 173 174RFC 959 October 1985 175File Transfer Protocol 176 177 178 control connection 179 180 The communication path between the USER-PI and SERVER-PI for 181 the exchange of commands and replies. This connection follows 182 the Telnet Protocol. 183 184 data connection 185 186 A full duplex connection over which data is transferred, in a 187 specified mode and type. The data transferred may be a part of 188 a file, an entire file or a number of files. The path may be 189 between a server-DTP and a user-DTP, or between two 190 server-DTPs. 191 192 data port 193 194 The passive data transfer process "listens" on the data port 195 for a connection from the active transfer process in order to 196 open the data connection. 197 198 DTP 199 200 The data transfer process establishes and manages the data 201 connection. The DTP can be passive or active. 202 203 End-of-Line 204 205 The end-of-line sequence defines the separation of printing 206 lines. The sequence is Carriage Return, followed by Line Feed. 207 208 EOF 209 210 The end-of-file condition that defines the end of a file being 211 transferred. 212 213 EOR 214 215 The end-of-record condition that defines the end of a record 216 being transferred. 217 218 error recovery 219 220 A procedure that allows a user to recover from certain errors 221 such as failure of either host system or transfer process. In 222 FTP, error recovery may involve restarting a file transfer at a 223 given checkpoint. 224 225 226 227Postel & Reynolds [Page 4] 228 229 230 231RFC 959 October 1985 232File Transfer Protocol 233 234 235 FTP commands 236 237 A set of commands that comprise the control information flowing 238 from the user-FTP to the server-FTP process. 239 240 file 241 242 An ordered set of computer data (including programs), of 243 arbitrary length, uniquely identified by a pathname. 244 245 mode 246 247 The mode in which data is to be transferred via the data 248 connection. The mode defines the data format during transfer 249 including EOR and EOF. The transfer modes defined in FTP are 250 described in the Section on Transmission Modes. 251 252 NVT 253 254 The Network Virtual Terminal as defined in the Telnet Protocol. 255 256 NVFS 257 258 The Network Virtual File System. A concept which defines a 259 standard network file system with standard commands and 260 pathname conventions. 261 262 page 263 264 A file may be structured as a set of independent parts called 265 pages. FTP supports the transmission of discontinuous files as 266 independent indexed pages. 267 268 pathname 269 270 Pathname is defined to be the character string which must be 271 input to a file system by a user in order to identify a file. 272 Pathname normally contains device and/or directory names, and 273 file name specification. FTP does not yet specify a standard 274 pathname convention. Each user must follow the file naming 275 conventions of the file systems involved in the transfer. 276 277 PI 278 279 The protocol interpreter. The user and server sides of the 280 protocol have distinct roles implemented in a user-PI and a 281 server-PI. 282 283 284Postel & Reynolds [Page 5] 285 286 287 288RFC 959 October 1985 289File Transfer Protocol 290 291 292 record 293 294 A sequential file may be structured as a number of contiguous 295 parts called records. Record structures are supported by FTP 296 but a file need not have record structure. 297 298 reply 299 300 A reply is an acknowledgment (positive or negative) sent from 301 server to user via the control connection in response to FTP 302 commands. The general form of a reply is a completion code 303 (including error codes) followed by a text string. The codes 304 are for use by programs and the text is usually intended for 305 human users. 306 307 server-DTP 308 309 The data transfer process, in its normal "active" state, 310 establishes the data connection with the "listening" data port. 311 It sets up parameters for transfer and storage, and transfers 312 data on command from its PI. The DTP can be placed in a 313 "passive" state to listen for, rather than initiate a 314 connection on the data port. 315 316 server-FTP process 317 318 A process or set of processes which perform the function of 319 file transfer in cooperation with a user-FTP process and, 320 possibly, another server. The functions consist of a protocol 321 interpreter (PI) and a data transfer process (DTP). 322 323 server-PI 324 325 The server protocol interpreter "listens" on Port L for a 326 connection from a user-PI and establishes a control 327 communication connection. It receives standard FTP commands 328 from the user-PI, sends replies, and governs the server-DTP. 329 330 type 331 332 The data representation type used for data transfer and 333 storage. Type implies certain transformations between the time 334 of data storage and data transfer. The representation types 335 defined in FTP are described in the Section on Establishing 336 Data Connections. 337 338 339 340 341Postel & Reynolds [Page 6] 342 343 344 345RFC 959 October 1985 346File Transfer Protocol 347 348 349 user 350 351 A person or a process on behalf of a person wishing to obtain 352 file transfer service. The human user may interact directly 353 with a server-FTP process, but use of a user-FTP process is 354 preferred since the protocol design is weighted towards 355 automata. 356 357 user-DTP 358 359 The data transfer process "listens" on the data port for a 360 connection from a server-FTP process. If two servers are 361 transferring data between them, the user-DTP is inactive. 362 363 user-FTP process 364 365 A set of functions including a protocol interpreter, a data 366 transfer process and a user interface which together perform 367 the function of file transfer in cooperation with one or more 368 server-FTP processes. The user interface allows a local 369 language to be used in the command-reply dialogue with the 370 user. 371 372 user-PI 373 374 The user protocol interpreter initiates the control connection 375 from its port U to the server-FTP process, initiates FTP 376 commands, and governs the user-DTP if that process is part of 377 the file transfer. 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398Postel & Reynolds [Page 7] 399 400 401 402RFC 959 October 1985 403File Transfer Protocol 404 405 406 2.3. THE FTP MODEL 407 408 With the above definitions in mind, the following model (shown in 409 Figure 1) may be diagrammed for an FTP service. 410 411 ------------- 412 |/---------\| 413 || User || -------- 414 ||Interface|<--->| User | 415 |\----^----/| -------- 416 ---------- | | | 417 |/------\| FTP Commands |/----V----\| 418 ||Server|<---------------->| User || 419 || PI || FTP Replies || PI || 420 |\--^---/| |\----^----/| 421 | | | | | | 422 -------- |/--V---\| Data |/----V----\| -------- 423 | File |<--->|Server|<---------------->| User |<--->| File | 424 |System| || DTP || Connection || DTP || |System| 425 -------- |\------/| |\---------/| -------- 426 ---------- ------------- 427 428 Server-FTP USER-FTP 429 430 NOTES: 1. The data connection may be used in either direction. 431 2. The data connection need not exist all of the time. 432 433 Figure 1 Model for FTP Use 434 435 In the model described in Figure 1, the user-protocol interpreter 436 initiates the control connection. The control connection follows 437 the Telnet protocol. At the initiation of the user, standard FTP 438 commands are generated by the user-PI and transmitted to the 439 server process via the control connection. (The user may 440 establish a direct control connection to the server-FTP, from a 441 TAC terminal for example, and generate standard FTP commands 442 independently, bypassing the user-FTP process.) Standard replies 443 are sent from the server-PI to the user-PI over the control 444 connection in response to the commands. 445 446 The FTP commands specify the parameters for the data connection 447 (data port, transfer mode, representation type, and structure) and 448 the nature of file system operation (store, retrieve, append, 449 delete, etc.). The user-DTP or its designate should "listen" on 450 the specified data port, and the server initiate the data 451 connection and data transfer in accordance with the specified 452 parameters. It should be noted that the data port need not be in 453 454 455Postel & Reynolds [Page 8] 456 457 458 459RFC 959 October 1985 460File Transfer Protocol 461 462 463 the same host that initiates the FTP commands via the control 464 connection, but the user or the user-FTP process must ensure a 465 "listen" on the specified data port. It ought to also be noted 466 that the data connection may be used for simultaneous sending and 467 receiving. 468 469 In another situation a user might wish to transfer files between 470 two hosts, neither of which is a local host. The user sets up 471 control connections to the two servers and then arranges for a 472 data connection between them. In this manner, control information 473 is passed to the user-PI but data is transferred between the 474 server data transfer processes. Following is a model of this 475 server-server interaction. 476 477 478 Control ------------ Control 479 ---------->| User-FTP |<----------- 480 | | User-PI | | 481 | | "C" | | 482 V ------------ V 483 -------------- -------------- 484 | Server-FTP | Data Connection | Server-FTP | 485 | "A" |<---------------------->| "B" | 486 -------------- Port (A) Port (B) -------------- 487 488 489 Figure 2 490 491 The protocol requires that the control connections be open while 492 data transfer is in progress. It is the responsibility of the 493 user to request the closing of the control connections when 494 finished using the FTP service, while it is the server who takes 495 the action. The server may abort data transfer if the control 496 connections are closed without command. 497 498 The Relationship between FTP and Telnet: 499 500 The FTP uses the Telnet protocol on the control connection. 501 This can be achieved in two ways: first, the user-PI or the 502 server-PI may implement the rules of the Telnet Protocol 503 directly in their own procedures; or, second, the user-PI or 504 the server-PI may make use of the existing Telnet module in the 505 system. 506 507 Ease of implementaion, sharing code, and modular programming 508 argue for the second approach. Efficiency and independence 509 510 511 512Postel & Reynolds [Page 9] 513 514 515 516RFC 959 October 1985 517File Transfer Protocol 518 519 520 argue for the first approach. In practice, FTP relies on very 521 little of the Telnet Protocol, so the first approach does not 522 necessarily involve a large amount of code. 523 5243. DATA TRANSFER FUNCTIONS 525 526 Files are transferred only via the data connection. The control 527 connection is used for the transfer of commands, which describe the 528 functions to be performed, and the replies to these commands (see the 529 Section on FTP Replies). Several commands are concerned with the 530 transfer of data between hosts. These data transfer commands include 531 the MODE command which specify how the bits of the data are to be 532 transmitted, and the STRUcture and TYPE commands, which are used to 533 define the way in which the data are to be represented. The 534 transmission and representation are basically independent but the 535 "Stream" transmission mode is dependent on the file structure 536 attribute and if "Compressed" transmission mode is used, the nature 537 of the filler byte depends on the representation type. 538 539 3.1. DATA REPRESENTATION AND STORAGE 540 541 Data is transferred from a storage device in the sending host to a 542 storage device in the receiving host. Often it is necessary to 543 perform certain transformations on the data because data storage 544 representations in the two systems are different. For example, 545 NVT-ASCII has different data storage representations in different 546 systems. DEC TOPS-20s's generally store NVT-ASCII as five 7-bit 547 ASCII characters, left-justified in a 36-bit word. IBM Mainframe's 548 store NVT-ASCII as 8-bit EBCDIC codes. Multics stores NVT-ASCII 549 as four 9-bit characters in a 36-bit word. It is desirable to 550 convert characters into the standard NVT-ASCII representation when 551 transmitting text between dissimilar systems. The sending and 552 receiving sites would have to perform the necessary 553 transformations between the standard representation and their 554 internal representations. 555 556 A different problem in representation arises when transmitting 557 binary data (not character codes) between host systems with 558 different word lengths. It is not always clear how the sender 559 should send data, and the receiver store it. For example, when 560 transmitting 32-bit bytes from a 32-bit word-length system to a 561 36-bit word-length system, it may be desirable (for reasons of 562 efficiency and usefulness) to store the 32-bit bytes 563 right-justified in a 36-bit word in the latter system. In any 564 case, the user should have the option of specifying data 565 representation and transformation functions. It should be noted 566 567 568 569Postel & Reynolds [Page 10] 570 571 572 573RFC 959 October 1985 574File Transfer Protocol 575 576 577 that FTP provides for very limited data type representations. 578 Transformations desired beyond this limited capability should be 579 performed by the user directly. 580 581 3.1.1. DATA TYPES 582 583 Data representations are handled in FTP by a user specifying a 584 representation type. This type may implicitly (as in ASCII or 585 EBCDIC) or explicitly (as in Local byte) define a byte size for 586 interpretation which is referred to as the "logical byte size." 587 Note that this has nothing to do with the byte size used for 588 transmission over the data connection, called the "transfer 589 byte size", and the two should not be confused. For example, 590 NVT-ASCII has a logical byte size of 8 bits. If the type is 591 Local byte, then the TYPE command has an obligatory second 592 parameter specifying the logical byte size. The transfer byte 593 size is always 8 bits. 594 595 3.1.1.1. ASCII TYPE 596 597 This is the default type and must be accepted by all FTP 598 implementations. It is intended primarily for the transfer 599 of text files, except when both hosts would find the EBCDIC 600 type more convenient. 601 602 The sender converts the data from an internal character 603 representation to the standard 8-bit NVT-ASCII 604 representation (see the Telnet specification). The receiver 605 will convert the data from the standard form to his own 606 internal form. 607 608 In accordance with the NVT standard, the <CRLF> sequence 609 should be used where necessary to denote the end of a line 610 of text. (See the discussion of file structure at the end 611 of the Section on Data Representation and Storage.) 612 613 Using the standard NVT-ASCII representation means that data 614 must be interpreted as 8-bit bytes. 615 616 The Format parameter for ASCII and EBCDIC types is discussed 617 below. 618 619 620 621 622 623 624 625 626Postel & Reynolds [Page 11] 627 628 629 630RFC 959 October 1985 631File Transfer Protocol 632 633 634 3.1.1.2. EBCDIC TYPE 635 636 This type is intended for efficient transfer between hosts 637 which use EBCDIC for their internal character 638 representation. 639 640 For transmission, the data are represented as 8-bit EBCDIC 641 characters. The character code is the only difference 642 between the functional specifications of EBCDIC and ASCII 643 types. 644 645 End-of-line (as opposed to end-of-record--see the discussion 646 of structure) will probably be rarely used with EBCDIC type 647 for purposes of denoting structure, but where it is 648 necessary the <NL> character should be used. 649 650 3.1.1.3. IMAGE TYPE 651 652 The data are sent as contiguous bits which, for transfer, 653 are packed into the 8-bit transfer bytes. The receiving 654 site must store the data as contiguous bits. The structure 655 of the storage system might necessitate the padding of the 656 file (or of each record, for a record-structured file) to 657 some convenient boundary (byte, word or block). This 658 padding, which must be all zeros, may occur only at the end 659 of the file (or at the end of each record) and there must be 660 a way of identifying the padding bits so that they may be 661 stripped off if the file is retrieved. The padding 662 transformation should be well publicized to enable a user to 663 process a file at the storage site. 664 665 Image type is intended for the efficient storage and 666 retrieval of files and for the transfer of binary data. It 667 is recommended that this type be accepted by all FTP 668 implementations. 669 670 3.1.1.4. LOCAL TYPE 671 672 The data is transferred in logical bytes of the size 673 specified by the obligatory second parameter, Byte size. 674 The value of Byte size must be a decimal integer; there is 675 no default value. The logical byte size is not necessarily 676 the same as the transfer byte size. If there is a 677 difference in byte sizes, then the logical bytes should be 678 packed contiguously, disregarding transfer byte boundaries 679 and with any necessary padding at the end. 680 681 682 683Postel & Reynolds [Page 12] 684 685 686 687RFC 959 October 1985 688File Transfer Protocol 689 690 691 When the data reaches the receiving host, it will be 692 transformed in a manner dependent on the logical byte size 693 and the particular host. This transformation must be 694 invertible (i.e., an identical file can be retrieved if the 695 same parameters are used) and should be well publicized by 696 the FTP implementors. 697 698 For example, a user sending 36-bit floating-point numbers to 699 a host with a 32-bit word could send that data as Local byte 700 with a logical byte size of 36. The receiving host would 701 then be expected to store the logical bytes so that they 702 could be easily manipulated; in this example putting the 703 36-bit logical bytes into 64-bit double words should 704 suffice. 705 706 In another example, a pair of hosts with a 36-bit word size 707 may send data to one another in words by using TYPE L 36. 708 The data would be sent in the 8-bit transmission bytes 709 packed so that 9 transmission bytes carried two host words. 710 711 3.1.1.5. FORMAT CONTROL 712 713 The types ASCII and EBCDIC also take a second (optional) 714 parameter; this is to indicate what kind of vertical format 715 control, if any, is associated with a file. The following 716 data representation types are defined in FTP: 717 718 A character file may be transferred to a host for one of 719 three purposes: for printing, for storage and later 720 retrieval, or for processing. If a file is sent for 721 printing, the receiving host must know how the vertical 722 format control is represented. In the second case, it must 723 be possible to store a file at a host and then retrieve it 724 later in exactly the same form. Finally, it should be 725 possible to move a file from one host to another and process 726 the file at the second host without undue trouble. A single 727 ASCII or EBCDIC format does not satisfy all these 728 conditions. Therefore, these types have a second parameter 729 specifying one of the following three formats: 730 731 3.1.1.5.1. NON PRINT 732 733 This is the default format to be used if the second 734 (format) parameter is omitted. Non-print format must be 735 accepted by all FTP implementations. 736 737 738 739 740Postel & Reynolds [Page 13] 741 742 743 744RFC 959 October 1985 745File Transfer Protocol 746 747 748 The file need contain no vertical format information. If 749 it is passed to a printer process, this process may 750 assume standard values for spacing and margins. 751 752 Normally, this format will be used with files destined 753 for processing or just storage. 754 755 3.1.1.5.2. TELNET FORMAT CONTROLS 756 757 The file contains ASCII/EBCDIC vertical format controls 758 (i.e., <CR>, <LF>, <NL>, <VT>, <FF>) which the printer 759 process will interpret appropriately. <CRLF>, in exactly 760 this sequence, also denotes end-of-line. 761 762 3.1.1.5.2. CARRIAGE CONTROL (ASA) 763 764 The file contains ASA (FORTRAN) vertical format control 765 characters. (See RFC 740 Appendix C; and Communications 766 of the ACM, Vol. 7, No. 10, p. 606, October 1964.) In a 767 line or a record formatted according to the ASA Standard, 768 the first character is not to be printed. Instead, it 769 should be used to determine the vertical movement of the 770 paper which should take place before the rest of the 771 record is printed. 772 773 The ASA Standard specifies the following control 774 characters: 775 776 Character Vertical Spacing 777 778 blank Move paper up one line 779 0 Move paper up two lines 780 1 Move paper to top of next page 781 + No movement, i.e., overprint 782 783 Clearly there must be some way for a printer process to 784 distinguish the end of the structural entity. If a file 785 has record structure (see below) this is no problem; 786 records will be explicitly marked during transfer and 787 storage. If the file has no record structure, the <CRLF> 788 end-of-line sequence is used to separate printing lines, 789 but these format effectors are overridden by the ASA 790 controls. 791 792 793 794 795 796 797Postel & Reynolds [Page 14] 798 799 800 801RFC 959 October 1985 802File Transfer Protocol 803 804 805 3.1.2. DATA STRUCTURES 806 807 In addition to different representation types, FTP allows the 808 structure of a file to be specified. Three file structures are 809 defined in FTP: 810 811 file-structure, where there is no internal structure and 812 the file is considered to be a 813 continuous sequence of data bytes, 814 815 record-structure, where the file is made up of sequential 816 records, 817 818 and page-structure, where the file is made up of independent 819 indexed pages. 820 821 File-structure is the default to be assumed if the STRUcture 822 command has not been used but both file and record structures 823 must be accepted for "text" files (i.e., files with TYPE ASCII 824 or EBCDIC) by all FTP implementations. The structure of a file 825 will affect both the transfer mode of a file (see the Section 826 on Transmission Modes) and the interpretation and storage of 827 the file. 828 829 The "natural" structure of a file will depend on which host 830 stores the file. A source-code file will usually be stored on 831 an IBM Mainframe in fixed length records but on a DEC TOPS-20 832 as a stream of characters partitioned into lines, for example 833 by <CRLF>. If the transfer of files between such disparate 834 sites is to be useful, there must be some way for one site to 835 recognize the other's assumptions about the file. 836 837 With some sites being naturally file-oriented and others 838 naturally record-oriented there may be problems if a file with 839 one structure is sent to a host oriented to the other. If a 840 text file is sent with record-structure to a host which is file 841 oriented, then that host should apply an internal 842 transformation to the file based on the record structure. 843 Obviously, this transformation should be useful, but it must 844 also be invertible so that an identical file may be retrieved 845 using record structure. 846 847 In the case of a file being sent with file-structure to a 848 record-oriented host, there exists the question of what 849 criteria the host should use to divide the file into records 850 which can be processed locally. If this division is necessary, 851 the FTP implementation should use the end-of-line sequence, 852 853 854Postel & Reynolds [Page 15] 855 856 857 858RFC 959 October 1985 859File Transfer Protocol 860 861 862 <CRLF> for ASCII, or <NL> for EBCDIC text files, as the 863 delimiter. If an FTP implementation adopts this technique, it 864 must be prepared to reverse the transformation if the file is 865 retrieved with file-structure. 866 867 3.1.2.1. FILE STRUCTURE 868 869 File structure is the default to be assumed if the STRUcture 870 command has not been used. 871 872 In file-structure there is no internal structure and the 873 file is considered to be a continuous sequence of data 874 bytes. 875 876 3.1.2.2. RECORD STRUCTURE 877 878 Record structures must be accepted for "text" files (i.e., 879 files with TYPE ASCII or EBCDIC) by all FTP implementations. 880 881 In record-structure the file is made up of sequential 882 records. 883 884 3.1.2.3. PAGE STRUCTURE 885 886 To transmit files that are discontinuous, FTP defines a page 887 structure. Files of this type are sometimes known as 888 "random access files" or even as "holey files". In these 889 files there is sometimes other information associated with 890 the file as a whole (e.g., a file descriptor), or with a 891 section of the file (e.g., page access controls), or both. 892 In FTP, the sections of the file are called pages. 893 894 To provide for various page sizes and associated 895 information, each page is sent with a page header. The page 896 header has the following defined fields: 897 898 Header Length 899 900 The number of logical bytes in the page header 901 including this byte. The minimum header length is 4. 902 903 Page Index 904 905 The logical page number of this section of the file. 906 This is not the transmission sequence number of this 907 page, but the index used to identify this page of the 908 file. 909 910 911Postel & Reynolds [Page 16] 912 913 914 915RFC 959 October 1985 916File Transfer Protocol 917 918 919 Data Length 920 921 The number of logical bytes in the page data. The 922 minimum data length is 0. 923 924 Page Type 925 926 The type of page this is. The following page types 927 are defined: 928 929 0 = Last Page 930 931 This is used to indicate the end of a paged 932 structured transmission. The header length must 933 be 4, and the data length must be 0. 934 935 1 = Simple Page 936 937 This is the normal type for simple paged files 938 with no page level associated control 939 information. The header length must be 4. 940 941 2 = Descriptor Page 942 943 This type is used to transmit the descriptive 944 information for the file as a whole. 945 946 3 = Access Controlled Page 947 948 This type includes an additional header field 949 for paged files with page level access control 950 information. The header length must be 5. 951 952 Optional Fields 953 954 Further header fields may be used to supply per page 955 control information, for example, per page access 956 control. 957 958 All fields are one logical byte in length. The logical byte 959 size is specified by the TYPE command. See Appendix I for 960 further details and a specific case at the page structure. 961 962 A note of caution about parameters: a file must be stored and 963 retrieved with the same parameters if the retrieved version is to 964 965 966 967 968Postel & Reynolds [Page 17] 969 970 971 972RFC 959 October 1985 973File Transfer Protocol 974 975 976 be identical to the version originally transmitted. Conversely, 977 FTP implementations must return a file identical to the original 978 if the parameters used to store and retrieve a file are the same. 979 980 3.2. ESTABLISHING DATA CONNECTIONS 981 982 The mechanics of transferring data consists of setting up the data 983 connection to the appropriate ports and choosing the parameters 984 for transfer. Both the user and the server-DTPs have a default 985 data port. The user-process default data port is the same as the 986 control connection port (i.e., U). The server-process default 987 data port is the port adjacent to the control connection port 988 (i.e., L-1). 989 990 The transfer byte size is 8-bit bytes. This byte size is relevant 991 only for the actual transfer of the data; it has no bearing on 992 representation of the data within a host's file system. 993 994 The passive data transfer process (this may be a user-DTP or a 995 second server-DTP) shall "listen" on the data port prior to 996 sending a transfer request command. The FTP request command 997 determines the direction of the data transfer. The server, upon 998 receiving the transfer request, will initiate the data connection 999 to the port. When the connection is established, the data 1000 transfer begins between DTP's, and the server-PI sends a 1001 confirming reply to the user-PI. 1002 1003 Every FTP implementation must support the use of the default data 1004 ports, and only the USER-PI can initiate a change to non-default 1005 ports. 1006 1007 It is possible for the user to specify an alternate data port by 1008 use of the PORT command. The user may want a file dumped on a TAC 1009 line printer or retrieved from a third party host. In the latter 1010 case, the user-PI sets up control connections with both 1011 server-PI's. One server is then told (by an FTP command) to 1012 "listen" for a connection which the other will initiate. The 1013 user-PI sends one server-PI a PORT command indicating the data 1014 port of the other. Finally, both are sent the appropriate 1015 transfer commands. The exact sequence of commands and replies 1016 sent between the user-controller and the servers is defined in the 1017 Section on FTP Replies. 1018 1019 In general, it is the server's responsibility to maintain the data 1020 connection--to initiate it and to close it. The exception to this 1021 1022 1023 1024 1025Postel & Reynolds [Page 18] 1026 1027 1028 1029RFC 959 October 1985 1030File Transfer Protocol 1031 1032 1033 is when the user-DTP is sending the data in a transfer mode that 1034 requires the connection to be closed to indicate EOF. The server 1035 MUST close the data connection under the following conditions: 1036 1037 1. The server has completed sending data in a transfer mode 1038 that requires a close to indicate EOF. 1039 1040 2. The server receives an ABORT command from the user. 1041 1042 3. The port specification is changed by a command from the 1043 user. 1044 1045 4. The control connection is closed legally or otherwise. 1046 1047 5. An irrecoverable error condition occurs. 1048 1049 Otherwise the close is a server option, the exercise of which the 1050 server must indicate to the user-process by either a 250 or 226 1051 reply only. 1052 1053 3.3. DATA CONNECTION MANAGEMENT 1054 1055 Default Data Connection Ports: All FTP implementations must 1056 support use of the default data connection ports, and only the 1057 User-PI may initiate the use of non-default ports. 1058 1059 Negotiating Non-Default Data Ports: The User-PI may specify a 1060 non-default user side data port with the PORT command. The 1061 User-PI may request the server side to identify a non-default 1062 server side data port with the PASV command. Since a connection 1063 is defined by the pair of addresses, either of these actions is 1064 enough to get a different data connection, still it is permitted 1065 to do both commands to use new ports on both ends of the data 1066 connection. 1067 1068 Reuse of the Data Connection: When using the stream mode of data 1069 transfer the end of the file must be indicated by closing the 1070 connection. This causes a problem if multiple files are to be 1071 transfered in the session, due to need for TCP to hold the 1072 connection record for a time out period to guarantee the reliable 1073 communication. Thus the connection can not be reopened at once. 1074 1075 There are two solutions to this problem. The first is to 1076 negotiate a non-default port. The second is to use another 1077 transfer mode. 1078 1079 A comment on transfer modes. The stream transfer mode is 1080 1081 1082Postel & Reynolds [Page 19] 1083 1084 1085 1086RFC 959 October 1985 1087File Transfer Protocol 1088 1089 1090 inherently unreliable, since one can not determine if the 1091 connection closed prematurely or not. The other transfer modes 1092 (Block, Compressed) do not close the connection to indicate the 1093 end of file. They have enough FTP encoding that the data 1094 connection can be parsed to determine the end of the file. 1095 Thus using these modes one can leave the data connection open 1096 for multiple file transfers. 1097 1098 3.4. TRANSMISSION MODES 1099 1100 The next consideration in transferring data is choosing the 1101 appropriate transmission mode. There are three modes: one which 1102 formats the data and allows for restart procedures; one which also 1103 compresses the data for efficient transfer; and one which passes 1104 the data with little or no processing. In this last case the mode 1105 interacts with the structure attribute to determine the type of 1106 processing. In the compressed mode, the representation type 1107 determines the filler byte. 1108 1109 All data transfers must be completed with an end-of-file (EOF) 1110 which may be explicitly stated or implied by the closing of the 1111 data connection. For files with record structure, all the 1112 end-of-record markers (EOR) are explicit, including the final one. 1113 For files transmitted in page structure a "last-page" page type is 1114 used. 1115 1116 NOTE: In the rest of this section, byte means "transfer byte" 1117 except where explicitly stated otherwise. 1118 1119 For the purpose of standardized transfer, the sending host will 1120 translate its internal end of line or end of record denotation 1121 into the representation prescribed by the transfer mode and file 1122 structure, and the receiving host will perform the inverse 1123 translation to its internal denotation. An IBM Mainframe record 1124 count field may not be recognized at another host, so the 1125 end-of-record information may be transferred as a two byte control 1126 code in Stream mode or as a flagged bit in a Block or Compressed 1127 mode descriptor. End-of-line in an ASCII or EBCDIC file with no 1128 record structure should be indicated by <CRLF> or <NL>, 1129 respectively. Since these transformations imply extra work for 1130 some systems, identical systems transferring non-record structured 1131 text files might wish to use a binary representation and stream 1132 mode for the transfer. 1133 1134 1135 1136 1137 1138 1139Postel & Reynolds [Page 20] 1140 1141 1142 1143RFC 959 October 1985 1144File Transfer Protocol 1145 1146 1147 The following transmission modes are defined in FTP: 1148 1149 3.4.1. STREAM MODE 1150 1151 The data is transmitted as a stream of bytes. There is no 1152 restriction on the representation type used; record structures 1153 are allowed. 1154 1155 In a record structured file EOR and EOF will each be indicated 1156 by a two-byte control code. The first byte of the control code 1157 will be all ones, the escape character. The second byte will 1158 have the low order bit on and zeros elsewhere for EOR and the 1159 second low order bit on for EOF; that is, the byte will have 1160 value 1 for EOR and value 2 for EOF. EOR and EOF may be 1161 indicated together on the last byte transmitted by turning both 1162 low order bits on (i.e., the value 3). If a byte of all ones 1163 was intended to be sent as data, it should be repeated in the 1164 second byte of the control code. 1165 1166 If the structure is a file structure, the EOF is indicated by 1167 the sending host closing the data connection and all bytes are 1168 data bytes. 1169 1170 3.4.2. BLOCK MODE 1171 1172 The file is transmitted as a series of data blocks preceded by 1173 one or more header bytes. The header bytes contain a count 1174 field, and descriptor code. The count field indicates the 1175 total length of the data block in bytes, thus marking the 1176 beginning of the next data block (there are no filler bits). 1177 The descriptor code defines: last block in the file (EOF) last 1178 block in the record (EOR), restart marker (see the Section on 1179 Error Recovery and Restart) or suspect data (i.e., the data 1180 being transferred is suspected of errors and is not reliable). 1181 This last code is NOT intended for error control within FTP. 1182 It is motivated by the desire of sites exchanging certain types 1183 of data (e.g., seismic or weather data) to send and receive all 1184 the data despite local errors (such as "magnetic tape read 1185 errors"), but to indicate in the transmission that certain 1186 portions are suspect). Record structures are allowed in this 1187 mode, and any representation type may be used. 1188 1189 The header consists of the three bytes. Of the 24 bits of 1190 header information, the 16 low order bits shall represent byte 1191 count, and the 8 high order bits shall represent descriptor 1192 codes as shown below. 1193 1194 1195 1196Postel & Reynolds [Page 21] 1197 1198 1199 1200RFC 959 October 1985 1201File Transfer Protocol 1202 1203 1204 Block Header 1205 1206 +----------------+----------------+----------------+ 1207 | Descriptor | Byte Count | 1208 | 8 bits | 16 bits | 1209 +----------------+----------------+----------------+ 1210 1211 1212 The descriptor codes are indicated by bit flags in the 1213 descriptor byte. Four codes have been assigned, where each 1214 code number is the decimal value of the corresponding bit in 1215 the byte. 1216 1217 Code Meaning 1218 1219 128 End of data block is EOR 1220 64 End of data block is EOF 1221 32 Suspected errors in data block 1222 16 Data block is a restart marker 1223 1224 With this encoding, more than one descriptor coded condition 1225 may exist for a particular block. As many bits as necessary 1226 may be flagged. 1227 1228 The restart marker is embedded in the data stream as an 1229 integral number of 8-bit bytes representing printable 1230 characters in the language being used over the control 1231 connection (e.g., default--NVT-ASCII). <SP> (Space, in the 1232 appropriate language) must not be used WITHIN a restart marker. 1233 1234 For example, to transmit a six-character marker, the following 1235 would be sent: 1236 1237 +--------+--------+--------+ 1238 |Descrptr| Byte count | 1239 |code= 16| = 6 | 1240 +--------+--------+--------+ 1241 1242 +--------+--------+--------+ 1243 | Marker | Marker | Marker | 1244 | 8 bits | 8 bits | 8 bits | 1245 +--------+--------+--------+ 1246 1247 +--------+--------+--------+ 1248 | Marker | Marker | Marker | 1249 | 8 bits | 8 bits | 8 bits | 1250 +--------+--------+--------+ 1251 1252 1253Postel & Reynolds [Page 22] 1254 1255 1256 1257RFC 959 October 1985 1258File Transfer Protocol 1259 1260 1261 3.4.3. COMPRESSED MODE 1262 1263 There are three kinds of information to be sent: regular data, 1264 sent in a byte string; compressed data, consisting of 1265 replications or filler; and control information, sent in a 1266 two-byte escape sequence. If n>0 bytes (up to 127) of regular 1267 data are sent, these n bytes are preceded by a byte with the 1268 left-most bit set to 0 and the right-most 7 bits containing the 1269 number n. 1270 1271 Byte string: 1272 1273 1 7 8 8 1274 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1275 |0| n | | d(1) | ... | d(n) | 1276 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1277 ^ ^ 1278 |---n bytes---| 1279 of data 1280 1281 String of n data bytes d(1),..., d(n) 1282 Count n must be positive. 1283 1284 To compress a string of n replications of the data byte d, the 1285 following 2 bytes are sent: 1286 1287 Replicated Byte: 1288 1289 2 6 8 1290 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1291 |1 0| n | | d | 1292 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1293 1294 A string of n filler bytes can be compressed into a single 1295 byte, where the filler byte varies with the representation 1296 type. If the type is ASCII or EBCDIC the filler byte is <SP> 1297 (Space, ASCII code 32, EBCDIC code 64). If the type is Image 1298 or Local byte the filler is a zero byte. 1299 1300 Filler String: 1301 1302 2 6 1303 +-+-+-+-+-+-+-+-+ 1304 |1 1| n | 1305 +-+-+-+-+-+-+-+-+ 1306 1307 The escape sequence is a double byte, the first of which is the 1308 1309 1310Postel & Reynolds [Page 23] 1311 1312 1313 1314RFC 959 October 1985 1315File Transfer Protocol 1316 1317 1318 escape byte (all zeros) and the second of which contains 1319 descriptor codes as defined in Block mode. The descriptor 1320 codes have the same meaning as in Block mode and apply to the 1321 succeeding string of bytes. 1322 1323 Compressed mode is useful for obtaining increased bandwidth on 1324 very large network transmissions at a little extra CPU cost. 1325 It can be most effectively used to reduce the size of printer 1326 files such as those generated by RJE hosts. 1327 1328 3.5. ERROR RECOVERY AND RESTART 1329 1330 There is no provision for detecting bits lost or scrambled in data 1331 transfer; this level of error control is handled by the TCP. 1332 However, a restart procedure is provided to protect users from 1333 gross system failures (including failures of a host, an 1334 FTP-process, or the underlying network). 1335 1336 The restart procedure is defined only for the block and compressed 1337 modes of data transfer. It requires the sender of data to insert 1338 a special marker code in the data stream with some marker 1339 information. The marker information has meaning only to the 1340 sender, but must consist of printable characters in the default or 1341 negotiated language of the control connection (ASCII or EBCDIC). 1342 The marker could represent a bit-count, a record-count, or any 1343 other information by which a system may identify a data 1344 checkpoint. The receiver of data, if it implements the restart 1345 procedure, would then mark the corresponding position of this 1346 marker in the receiving system, and return this information to the 1347 user. 1348 1349 In the event of a system failure, the user can restart the data 1350 transfer by identifying the marker point with the FTP restart 1351 procedure. The following example illustrates the use of the 1352 restart procedure. 1353 1354 The sender of the data inserts an appropriate marker block in the 1355 data stream at a convenient point. The receiving host marks the 1356 corresponding data point in its file system and conveys the last 1357 known sender and receiver marker information to the user, either 1358 directly or over the control connection in a 110 reply (depending 1359 on who is the sender). In the event of a system failure, the user 1360 or controller process restarts the server at the last server 1361 marker by sending a restart command with server's marker code as 1362 its argument. The restart command is transmitted over the control 1363 1364 1365 1366 1367Postel & Reynolds [Page 24] 1368 1369 1370 1371RFC 959 October 1985 1372File Transfer Protocol 1373 1374 1375 connection and is immediately followed by the command (such as 1376 RETR, STOR or LIST) which was being executed when the system 1377 failure occurred. 1378 13794. FILE TRANSFER FUNCTIONS 1380 1381 The communication channel from the user-PI to the server-PI is 1382 established as a TCP connection from the user to the standard server 1383 port. The user protocol interpreter is responsible for sending FTP 1384 commands and interpreting the replies received; the server-PI 1385 interprets commands, sends replies and directs its DTP to set up the 1386 data connection and transfer the data. If the second party to the 1387 data transfer (the passive transfer process) is the user-DTP, then it 1388 is governed through the internal protocol of the user-FTP host; if it 1389 is a second server-DTP, then it is governed by its PI on command from 1390 the user-PI. The FTP replies are discussed in the next section. In 1391 the description of a few of the commands in this section, it is 1392 helpful to be explicit about the possible replies. 1393 1394 4.1. FTP COMMANDS 1395 1396 4.1.1. ACCESS CONTROL COMMANDS 1397 1398 The following commands specify access control identifiers 1399 (command codes are shown in parentheses). 1400 1401 USER NAME (USER) 1402 1403 The argument field is a Telnet string identifying the user. 1404 The user identification is that which is required by the 1405 server for access to its file system. This command will 1406 normally be the first command transmitted by the user after 1407 the control connections are made (some servers may require 1408 this). Additional identification information in the form of 1409 a password and/or an account command may also be required by 1410 some servers. Servers may allow a new USER command to be 1411 entered at any point in order to change the access control 1412 and/or accounting information. This has the effect of 1413 flushing any user, password, and account information already 1414 supplied and beginning the login sequence again. All 1415 transfer parameters are unchanged and any file transfer in 1416 progress is completed under the old access control 1417 parameters. 1418 1419 1420 1421 1422 1423 1424Postel & Reynolds [Page 25] 1425 1426 1427 1428RFC 959 October 1985 1429File Transfer Protocol 1430 1431 1432 PASSWORD (PASS) 1433 1434 The argument field is a Telnet string specifying the user's 1435 password. This command must be immediately preceded by the 1436 user name command, and, for some sites, completes the user's 1437 identification for access control. Since password 1438 information is quite sensitive, it is desirable in general 1439 to "mask" it or suppress typeout. It appears that the 1440 server has no foolproof way to achieve this. It is 1441 therefore the responsibility of the user-FTP process to hide 1442 the sensitive password information. 1443 1444 ACCOUNT (ACCT) 1445 1446 The argument field is a Telnet string identifying the user's 1447 account. The command is not necessarily related to the USER 1448 command, as some sites may require an account for login and 1449 others only for specific access, such as storing files. In 1450 the latter case the command may arrive at any time. 1451 1452 There are reply codes to differentiate these cases for the 1453 automation: when account information is required for login, 1454 the response to a successful PASSword command is reply code 1455 332. On the other hand, if account information is NOT 1456 required for login, the reply to a successful PASSword 1457 command is 230; and if the account information is needed for 1458 a command issued later in the dialogue, the server should 1459 return a 332 or 532 reply depending on whether it stores 1460 (pending receipt of the ACCounT command) or discards the 1461 command, respectively. 1462 1463 CHANGE WORKING DIRECTORY (CWD) 1464 1465 This command allows the user to work with a different 1466 directory or dataset for file storage or retrieval without 1467 altering his login or accounting information. Transfer 1468 parameters are similarly unchanged. The argument is a 1469 pathname specifying a directory or other system dependent 1470 file group designator. 1471 1472 CHANGE TO PARENT DIRECTORY (CDUP) 1473 1474 This command is a special case of CWD, and is included to 1475 simplify the implementation of programs for transferring 1476 directory trees between operating systems having different 1477 1478 1479 1480 1481Postel & Reynolds [Page 26] 1482 1483 1484 1485RFC 959 October 1985 1486File Transfer Protocol 1487 1488 1489 syntaxes for naming the parent directory. The reply codes 1490 shall be identical to the reply codes of CWD. See 1491 Appendix II for further details. 1492 1493 STRUCTURE MOUNT (SMNT) 1494 1495 This command allows the user to mount a different file 1496 system data structure without altering his login or 1497 accounting information. Transfer parameters are similarly 1498 unchanged. The argument is a pathname specifying a 1499 directory or other system dependent file group designator. 1500 1501 REINITIALIZE (REIN) 1502 1503 This command terminates a USER, flushing all I/O and account 1504 information, except to allow any transfer in progress to be 1505 completed. All parameters are reset to the default settings 1506 and the control connection is left open. This is identical 1507 to the state in which a user finds himself immediately after 1508 the control connection is opened. A USER command may be 1509 expected to follow. 1510 1511 LOGOUT (QUIT) 1512 1513 This command terminates a USER and if file transfer is not 1514 in progress, the server closes the control connection. If 1515 file transfer is in progress, the connection will remain 1516 open for result response and the server will then close it. 1517 If the user-process is transferring files for several USERs 1518 but does not wish to close and then reopen connections for 1519 each, then the REIN command should be used instead of QUIT. 1520 1521 An unexpected close on the control connection will cause the 1522 server to take the effective action of an abort (ABOR) and a 1523 logout (QUIT). 1524 1525 4.1.2. TRANSFER PARAMETER COMMANDS 1526 1527 All data transfer parameters have default values, and the 1528 commands specifying data transfer parameters are required only 1529 if the default parameter values are to be changed. The default 1530 value is the last specified value, or if no value has been 1531 specified, the standard default value is as stated here. This 1532 implies that the server must "remember" the applicable default 1533 values. The commands may be in any order except that they must 1534 precede the FTP service request. The following commands 1535 specify data transfer parameters: 1536 1537 1538Postel & Reynolds [Page 27] 1539 1540 1541 1542RFC 959 October 1985 1543File Transfer Protocol 1544 1545 1546 DATA PORT (PORT) 1547 1548 The argument is a HOST-PORT specification for the data port 1549 to be used in data connection. There are defaults for both 1550 the user and server data ports, and under normal 1551 circumstances this command and its reply are not needed. If 1552 this command is used, the argument is the concatenation of a 1553 32-bit internet host address and a 16-bit TCP port address. 1554 This address information is broken into 8-bit fields and the 1555 value of each field is transmitted as a decimal number (in 1556 character string representation). The fields are separated 1557 by commas. A port command would be: 1558 1559 PORT h1,h2,h3,h4,p1,p2 1560 1561 where h1 is the high order 8 bits of the internet host 1562 address. 1563 1564 PASSIVE (PASV) 1565 1566 This command requests the server-DTP to "listen" on a data 1567 port (which is not its default data port) and to wait for a 1568 connection rather than initiate one upon receipt of a 1569 transfer command. The response to this command includes the 1570 host and port address this server is listening on. 1571 1572 REPRESENTATION TYPE (TYPE) 1573 1574 The argument specifies the representation type as described 1575 in the Section on Data Representation and Storage. Several 1576 types take a second parameter. The first parameter is 1577 denoted by a single Telnet character, as is the second 1578 Format parameter for ASCII and EBCDIC; the second parameter 1579 for local byte is a decimal integer to indicate Bytesize. 1580 The parameters are separated by a <SP> (Space, ASCII code 1581 32). 1582 1583 The following codes are assigned for type: 1584 1585 \ / 1586 A - ASCII | | N - Non-print 1587 |-><-| T - Telnet format effectors 1588 E - EBCDIC| | C - Carriage Control (ASA) 1589 / \ 1590 I - Image 1591 1592 L <byte size> - Local byte Byte size 1593 1594 1595Postel & Reynolds [Page 28] 1596 1597 1598 1599RFC 959 October 1985 1600File Transfer Protocol 1601 1602 1603 The default representation type is ASCII Non-print. If the 1604 Format parameter is changed, and later just the first 1605 argument is changed, Format then returns to the Non-print 1606 default. 1607 1608 FILE STRUCTURE (STRU) 1609 1610 The argument is a single Telnet character code specifying 1611 file structure described in the Section on Data 1612 Representation and Storage. 1613 1614 The following codes are assigned for structure: 1615 1616 F - File (no record structure) 1617 R - Record structure 1618 P - Page structure 1619 1620 The default structure is File. 1621 1622 TRANSFER MODE (MODE) 1623 1624 The argument is a single Telnet character code specifying 1625 the data transfer modes described in the Section on 1626 Transmission Modes. 1627 1628 The following codes are assigned for transfer modes: 1629 1630 S - Stream 1631 B - Block 1632 C - Compressed 1633 1634 The default transfer mode is Stream. 1635 1636 4.1.3. FTP SERVICE COMMANDS 1637 1638 The FTP service commands define the file transfer or the file 1639 system function requested by the user. The argument of an FTP 1640 service command will normally be a pathname. The syntax of 1641 pathnames must conform to server site conventions (with 1642 standard defaults applicable), and the language conventions of 1643 the control connection. The suggested default handling is to 1644 use the last specified device, directory or file name, or the 1645 standard default defined for local users. The commands may be 1646 in any order except that a "rename from" command must be 1647 followed by a "rename to" command and the restart command must 1648 be followed by the interrupted service command (e.g., STOR or 1649 RETR). The data, when transferred in response to FTP service 1650 1651 1652Postel & Reynolds [Page 29] 1653 1654 1655 1656RFC 959 October 1985 1657File Transfer Protocol 1658 1659 1660 commands, shall always be sent over the data connection, except 1661 for certain informative replies. The following commands 1662 specify FTP service requests: 1663 1664 RETRIEVE (RETR) 1665 1666 This command causes the server-DTP to transfer a copy of the 1667 file, specified in the pathname, to the server- or user-DTP 1668 at the other end of the data connection. The status and 1669 contents of the file at the server site shall be unaffected. 1670 1671 STORE (STOR) 1672 1673 This command causes the server-DTP to accept the data 1674 transferred via the data connection and to store the data as 1675 a file at the server site. If the file specified in the 1676 pathname exists at the server site, then its contents shall 1677 be replaced by the data being transferred. A new file is 1678 created at the server site if the file specified in the 1679 pathname does not already exist. 1680 1681 STORE UNIQUE (STOU) 1682 1683 This command behaves like STOR except that the resultant 1684 file is to be created in the current directory under a name 1685 unique to that directory. The 250 Transfer Started response 1686 must include the name generated. 1687 1688 APPEND (with create) (APPE) 1689 1690 This command causes the server-DTP to accept the data 1691 transferred via the data connection and to store the data in 1692 a file at the server site. If the file specified in the 1693 pathname exists at the server site, then the data shall be 1694 appended to that file; otherwise the file specified in the 1695 pathname shall be created at the server site. 1696 1697 ALLOCATE (ALLO) 1698 1699 This command may be required by some servers to reserve 1700 sufficient storage to accommodate the new file to be 1701 transferred. The argument shall be a decimal integer 1702 representing the number of bytes (using the logical byte 1703 size) of storage to be reserved for the file. For files 1704 sent with record or page structure a maximum record or page 1705 size (in logical bytes) might also be necessary; this is 1706 indicated by a decimal integer in a second argument field of 1707 1708 1709Postel & Reynolds [Page 30] 1710 1711 1712 1713RFC 959 October 1985 1714File Transfer Protocol 1715 1716 1717 the command. This second argument is optional, but when 1718 present should be separated from the first by the three 1719 Telnet characters <SP> R <SP>. This command shall be 1720 followed by a STORe or APPEnd command. The ALLO command 1721 should be treated as a NOOP (no operation) by those servers 1722 which do not require that the maximum size of the file be 1723 declared beforehand, and those servers interested in only 1724 the maximum record or page size should accept a dummy value 1725 in the first argument and ignore it. 1726 1727 RESTART (REST) 1728 1729 The argument field represents the server marker at which 1730 file transfer is to be restarted. This command does not 1731 cause file transfer but skips over the file to the specified 1732 data checkpoint. This command shall be immediately followed 1733 by the appropriate FTP service command which shall cause 1734 file transfer to resume. 1735 1736 RENAME FROM (RNFR) 1737 1738 This command specifies the old pathname of the file which is 1739 to be renamed. This command must be immediately followed by 1740 a "rename to" command specifying the new file pathname. 1741 1742 RENAME TO (RNTO) 1743 1744 This command specifies the new pathname of the file 1745 specified in the immediately preceding "rename from" 1746 command. Together the two commands cause a file to be 1747 renamed. 1748 1749 ABORT (ABOR) 1750 1751 This command tells the server to abort the previous FTP 1752 service command and any associated transfer of data. The 1753 abort command may require "special action", as discussed in 1754 the Section on FTP Commands, to force recognition by the 1755 server. No action is to be taken if the previous command 1756 has been completed (including data transfer). The control 1757 connection is not to be closed by the server, but the data 1758 connection must be closed. 1759 1760 There are two cases for the server upon receipt of this 1761 command: (1) the FTP service command was already completed, 1762 or (2) the FTP service command is still in progress. 1763 1764 1765 1766Postel & Reynolds [Page 31] 1767 1768 1769 1770RFC 959 October 1985 1771File Transfer Protocol 1772 1773 1774 In the first case, the server closes the data connection 1775 (if it is open) and responds with a 226 reply, indicating 1776 that the abort command was successfully processed. 1777 1778 In the second case, the server aborts the FTP service in 1779 progress and closes the data connection, returning a 426 1780 reply to indicate that the service request terminated 1781 abnormally. The server then sends a 226 reply, 1782 indicating that the abort command was successfully 1783 processed. 1784 1785 DELETE (DELE) 1786 1787 This command causes the file specified in the pathname to be 1788 deleted at the server site. If an extra level of protection 1789 is desired (such as the query, "Do you really wish to 1790 delete?"), it should be provided by the user-FTP process. 1791 1792 REMOVE DIRECTORY (RMD) 1793 1794 This command causes the directory specified in the pathname 1795 to be removed as a directory (if the pathname is absolute) 1796 or as a subdirectory of the current working directory (if 1797 the pathname is relative). See Appendix II. 1798 1799 MAKE DIRECTORY (MKD) 1800 1801 This command causes the directory specified in the pathname 1802 to be created as a directory (if the pathname is absolute) 1803 or as a subdirectory of the current working directory (if 1804 the pathname is relative). See Appendix II. 1805 1806 PRINT WORKING DIRECTORY (PWD) 1807 1808 This command causes the name of the current working 1809 directory to be returned in the reply. See Appendix II. 1810 1811 LIST (LIST) 1812 1813 This command causes a list to be sent from the server to the 1814 passive DTP. If the pathname specifies a directory or other 1815 group of files, the server should transfer a list of files 1816 in the specified directory. If the pathname specifies a 1817 file then the server should send current information on the 1818 file. A null argument implies the user's current working or 1819 default directory. The data transfer is over the data 1820 connection in type ASCII or type EBCDIC. (The user must 1821 1822 1823Postel & Reynolds [Page 32] 1824 1825 1826 1827RFC 959 October 1985 1828File Transfer Protocol 1829 1830 1831 ensure that the TYPE is appropriately ASCII or EBCDIC). 1832 Since the information on a file may vary widely from system 1833 to system, this information may be hard to use automatically 1834 in a program, but may be quite useful to a human user. 1835 1836 NAME LIST (NLST) 1837 1838 This command causes a directory listing to be sent from 1839 server to user site. The pathname should specify a 1840 directory or other system-specific file group descriptor; a 1841 null argument implies the current directory. The server 1842 will return a stream of names of files and no other 1843 information. The data will be transferred in ASCII or 1844 EBCDIC type over the data connection as valid pathname 1845 strings separated by <CRLF> or <NL>. (Again the user must 1846 ensure that the TYPE is correct.) This command is intended 1847 to return information that can be used by a program to 1848 further process the files automatically. For example, in 1849 the implementation of a "multiple get" function. 1850 1851 SITE PARAMETERS (SITE) 1852 1853 This command is used by the server to provide services 1854 specific to his system that are essential to file transfer 1855 but not sufficiently universal to be included as commands in 1856 the protocol. The nature of these services and the 1857 specification of their syntax can be stated in a reply to 1858 the HELP SITE command. 1859 1860 SYSTEM (SYST) 1861 1862 This command is used to find out the type of operating 1863 system at the server. The reply shall have as its first 1864 word one of the system names listed in the current version 1865 of the Assigned Numbers document [4]. 1866 1867 STATUS (STAT) 1868 1869 This command shall cause a status response to be sent over 1870 the control connection in the form of a reply. The command 1871 may be sent during a file transfer (along with the Telnet IP 1872 and Synch signals--see the Section on FTP Commands) in which 1873 case the server will respond with the status of the 1874 operation in progress, or it may be sent between file 1875 transfers. In the latter case, the command may have an 1876 argument field. If the argument is a pathname, the command 1877 is analogous to the "list" command except that data shall be 1878 1879 1880Postel & Reynolds [Page 33] 1881 1882 1883 1884RFC 959 October 1985 1885File Transfer Protocol 1886 1887 1888 transferred over the control connection. If a partial 1889 pathname is given, the server may respond with a list of 1890 file names or attributes associated with that specification. 1891 If no argument is given, the server should return general 1892 status information about the server FTP process. This 1893 should include current values of all transfer parameters and 1894 the status of connections. 1895 1896 HELP (HELP) 1897 1898 This command shall cause the server to send helpful 1899 information regarding its implementation status over the 1900 control connection to the user. The command may take an 1901 argument (e.g., any command name) and return more specific 1902 information as a response. The reply is type 211 or 214. 1903 It is suggested that HELP be allowed before entering a USER 1904 command. The server may use this reply to specify 1905 site-dependent parameters, e.g., in response to HELP SITE. 1906 1907 NOOP (NOOP) 1908 1909 This command does not affect any parameters or previously 1910 entered commands. It specifies no action other than that the 1911 server send an OK reply. 1912 1913 The File Transfer Protocol follows the specifications of the Telnet 1914 protocol for all communications over the control connection. Since 1915 the language used for Telnet communication may be a negotiated 1916 option, all references in the next two sections will be to the 1917 "Telnet language" and the corresponding "Telnet end-of-line code". 1918 Currently, one may take these to mean NVT-ASCII and <CRLF>. No other 1919 specifications of the Telnet protocol will be cited. 1920 1921 FTP commands are "Telnet strings" terminated by the "Telnet end of 1922 line code". The command codes themselves are alphabetic characters 1923 terminated by the character <SP> (Space) if parameters follow and 1924 Telnet-EOL otherwise. The command codes and the semantics of 1925 commands are described in this section; the detailed syntax of 1926 commands is specified in the Section on Commands, the reply sequences 1927 are discussed in the Section on Sequencing of Commands and Replies, 1928 and scenarios illustrating the use of commands are provided in the 1929 Section on Typical FTP Scenarios. 1930 1931 FTP commands may be partitioned as those specifying access-control 1932 identifiers, data transfer parameters, or FTP service requests. 1933 Certain commands (such as ABOR, STAT, QUIT) may be sent over the 1934 control connection while a data transfer is in progress. Some 1935 1936 1937Postel & Reynolds [Page 34] 1938 1939 1940 1941RFC 959 October 1985 1942File Transfer Protocol 1943 1944 1945 servers may not be able to monitor the control and data connections 1946 simultaneously, in which case some special action will be necessary 1947 to get the server's attention. The following ordered format is 1948 tentatively recommended: 1949 1950 1. User system inserts the Telnet "Interrupt Process" (IP) signal 1951 in the Telnet stream. 1952 1953 2. User system sends the Telnet "Synch" signal. 1954 1955 3. User system inserts the command (e.g., ABOR) in the Telnet 1956 stream. 1957 1958 4. Server PI, after receiving "IP", scans the Telnet stream for 1959 EXACTLY ONE FTP command. 1960 1961 (For other servers this may not be necessary but the actions listed 1962 above should have no unusual effect.) 1963 1964 4.2. FTP REPLIES 1965 1966 Replies to File Transfer Protocol commands are devised to ensure 1967 the synchronization of requests and actions in the process of file 1968 transfer, and to guarantee that the user process always knows the 1969 state of the Server. Every command must generate at least one 1970 reply, although there may be more than one; in the latter case, 1971 the multiple replies must be easily distinguished. In addition, 1972 some commands occur in sequential groups, such as USER, PASS and 1973 ACCT, or RNFR and RNTO. The replies show the existence of an 1974 intermediate state if all preceding commands have been successful. 1975 A failure at any point in the sequence necessitates the repetition 1976 of the entire sequence from the beginning. 1977 1978 The details of the command-reply sequence are made explicit in 1979 a set of state diagrams below. 1980 1981 An FTP reply consists of a three digit number (transmitted as 1982 three alphanumeric characters) followed by some text. The number 1983 is intended for use by automata to determine what state to enter 1984 next; the text is intended for the human user. It is intended 1985 that the three digits contain enough encoded information that the 1986 user-process (the User-PI) will not need to examine the text and 1987 may either discard it or pass it on to the user, as appropriate. 1988 In particular, the text may be server-dependent, so there are 1989 likely to be varying texts for each reply code. 1990 1991 A reply is defined to contain the 3-digit code, followed by Space 1992 1993 1994Postel & Reynolds [Page 35] 1995 1996 1997 1998RFC 959 October 1985 1999File Transfer Protocol 2000 2001 2002 <SP>, followed by one line of text (where some maximum line length 2003 has been specified), and terminated by the Telnet end-of-line 2004 code. There will be cases however, where the text is longer than 2005 a single line. In these cases the complete text must be bracketed 2006 so the User-process knows when it may stop reading the reply (i.e. 2007 stop processing input on the control connection) and go do other 2008 things. This requires a special format on the first line to 2009 indicate that more than one line is coming, and another on the 2010 last line to designate it as the last. At least one of these must 2011 contain the appropriate reply code to indicate the state of the 2012 transaction. To satisfy all factions, it was decided that both 2013 the first and last line codes should be the same. 2014 2015 Thus the format for multi-line replies is that the first line 2016 will begin with the exact required reply code, followed 2017 immediately by a Hyphen, "-" (also known as Minus), followed by 2018 text. The last line will begin with the same code, followed 2019 immediately by Space <SP>, optionally some text, and the Telnet 2020 end-of-line code. 2021 2022 For example: 2023 123-First line 2024 Second line 2025 234 A line beginning with numbers 2026 123 The last line 2027 2028 The user-process then simply needs to search for the second 2029 occurrence of the same reply code, followed by <SP> (Space), at 2030 the beginning of a line, and ignore all intermediary lines. If 2031 an intermediary line begins with a 3-digit number, the Server 2032 must pad the front to avoid confusion. 2033 2034 This scheme allows standard system routines to be used for 2035 reply information (such as for the STAT reply), with 2036 "artificial" first and last lines tacked on. In rare cases 2037 where these routines are able to generate three digits and a 2038 Space at the beginning of any line, the beginning of each 2039 text line should be offset by some neutral text, like Space. 2040 2041 This scheme assumes that multi-line replies may not be nested. 2042 2043 The three digits of the reply each have a special significance. 2044 This is intended to allow a range of very simple to very 2045 sophisticated responses by the user-process. The first digit 2046 denotes whether the response is good, bad or incomplete. 2047 (Referring to the state diagram), an unsophisticated user-process 2048 will be able to determine its next action (proceed as planned, 2049 2050 2051Postel & Reynolds [Page 36] 2052 2053 2054 2055RFC 959 October 1985 2056File Transfer Protocol 2057 2058 2059 redo, retrench, etc.) by simply examining this first digit. A 2060 user-process that wants to know approximately what kind of error 2061 occurred (e.g. file system error, command syntax error) may 2062 examine the second digit, reserving the third digit for the finest 2063 gradation of information (e.g., RNTO command without a preceding 2064 RNFR). 2065 2066 There are five values for the first digit of the reply code: 2067 2068 1yz Positive Preliminary reply 2069 2070 The requested action is being initiated; expect another 2071 reply before proceeding with a new command. (The 2072 user-process sending another command before the 2073 completion reply would be in violation of protocol; but 2074 server-FTP processes should queue any commands that 2075 arrive while a preceding command is in progress.) This 2076 type of reply can be used to indicate that the command 2077 was accepted and the user-process may now pay attention 2078 to the data connections, for implementations where 2079 simultaneous monitoring is difficult. The server-FTP 2080 process may send at most, one 1yz reply per command. 2081 2082 2yz Positive Completion reply 2083 2084 The requested action has been successfully completed. A 2085 new request may be initiated. 2086 2087 3yz Positive Intermediate reply 2088 2089 The command has been accepted, but the requested action 2090 is being held in abeyance, pending receipt of further 2091 information. The user should send another command 2092 specifying this information. This reply is used in 2093 command sequence groups. 2094 2095 4yz Transient Negative Completion reply 2096 2097 The command was not accepted and the requested action did 2098 not take place, but the error condition is temporary and 2099 the action may be requested again. The user should 2100 return to the beginning of the command sequence, if any. 2101 It is difficult to assign a meaning to "transient", 2102 particularly when two distinct sites (Server- and 2103 User-processes) have to agree on the interpretation. 2104 Each reply in the 4yz category might have a slightly 2105 different time value, but the intent is that the 2106 2107 2108Postel & Reynolds [Page 37] 2109 2110 2111 2112RFC 959 October 1985 2113File Transfer Protocol 2114 2115 2116 user-process is encouraged to try again. A rule of thumb 2117 in determining if a reply fits into the 4yz or the 5yz 2118 (Permanent Negative) category is that replies are 4yz if 2119 the commands can be repeated without any change in 2120 command form or in properties of the User or Server 2121 (e.g., the command is spelled the same with the same 2122 arguments used; the user does not change his file access 2123 or user name; the server does not put up a new 2124 implementation.) 2125 2126 5yz Permanent Negative Completion reply 2127 2128 The command was not accepted and the requested action did 2129 not take place. The User-process is discouraged from 2130 repeating the exact request (in the same sequence). Even 2131 some "permanent" error conditions can be corrected, so 2132 the human user may want to direct his User-process to 2133 reinitiate the command sequence by direct action at some 2134 point in the future (e.g., after the spelling has been 2135 changed, or the user has altered his directory status.) 2136 2137 The following function groupings are encoded in the second 2138 digit: 2139 2140 x0z Syntax - These replies refer to syntax errors, 2141 syntactically correct commands that don't fit any 2142 functional category, unimplemented or superfluous 2143 commands. 2144 2145 x1z Information - These are replies to requests for 2146 information, such as status or help. 2147 2148 x2z Connections - Replies referring to the control and 2149 data connections. 2150 2151 x3z Authentication and accounting - Replies for the login 2152 process and accounting procedures. 2153 2154 x4z Unspecified as yet. 2155 2156 x5z File system - These replies indicate the status of the 2157 Server file system vis-a-vis the requested transfer or 2158 other file system action. 2159 2160 The third digit gives a finer gradation of meaning in each of 2161 the function categories, specified by the second digit. The 2162 list of replies below will illustrate this. Note that the text 2163 2164 2165Postel & Reynolds [Page 38] 2166 2167 2168 2169RFC 959 October 1985 2170File Transfer Protocol 2171 2172 2173 associated with each reply is recommended, rather than 2174 mandatory, and may even change according to the command with 2175 which it is associated. The reply codes, on the other hand, 2176 must strictly follow the specifications in the last section; 2177 that is, Server implementations should not invent new codes for 2178 situations that are only slightly different from the ones 2179 described here, but rather should adapt codes already defined. 2180 2181 A command such as TYPE or ALLO whose successful execution 2182 does not offer the user-process any new information will 2183 cause a 200 reply to be returned. If the command is not 2184 implemented by a particular Server-FTP process because it 2185 has no relevance to that computer system, for example ALLO 2186 at a TOPS20 site, a Positive Completion reply is still 2187 desired so that the simple User-process knows it can proceed 2188 with its course of action. A 202 reply is used in this case 2189 with, for example, the reply text: "No storage allocation 2190 necessary." If, on the other hand, the command requests a 2191 non-site-specific action and is unimplemented, the response 2192 is 502. A refinement of that is the 504 reply for a command 2193 that is implemented, but that requests an unimplemented 2194 parameter. 2195 2196 4.2.1 Reply Codes by Function Groups 2197 2198 200 Command okay. 2199 500 Syntax error, command unrecognized. 2200 This may include errors such as command line too long. 2201 501 Syntax error in parameters or arguments. 2202 202 Command not implemented, superfluous at this site. 2203 502 Command not implemented. 2204 503 Bad sequence of commands. 2205 504 Command not implemented for that parameter. 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222Postel & Reynolds [Page 39] 2223 2224 2225 2226RFC 959 October 1985 2227File Transfer Protocol 2228 2229 2230 110 Restart marker reply. 2231 In this case, the text is exact and not left to the 2232 particular implementation; it must read: 2233 MARK yyyy = mmmm 2234 Where yyyy is User-process data stream marker, and mmmm 2235 server's equivalent marker (note the spaces between markers 2236 and "="). 2237 211 System status, or system help reply. 2238 212 Directory status. 2239 213 File status. 2240 214 Help message. 2241 On how to use the server or the meaning of a particular 2242 non-standard command. This reply is useful only to the 2243 human user. 2244 215 NAME system type. 2245 Where NAME is an official system name from the list in the 2246 Assigned Numbers document. 2247 2248 120 Service ready in nnn minutes. 2249 220 Service ready for new user. 2250 221 Service closing control connection. 2251 Logged out if appropriate. 2252 421 Service not available, closing control connection. 2253 This may be a reply to any command if the service knows it 2254 must shut down. 2255 125 Data connection already open; transfer starting. 2256 225 Data connection open; no transfer in progress. 2257 425 Can't open data connection. 2258 226 Closing data connection. 2259 Requested file action successful (for example, file 2260 transfer or file abort). 2261 426 Connection closed; transfer aborted. 2262 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). 2263 2264 230 User logged in, proceed. 2265 530 Not logged in. 2266 331 User name okay, need password. 2267 332 Need account for login. 2268 532 Need account for storing files. 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279Postel & Reynolds [Page 40] 2280 2281 2282 2283RFC 959 October 1985 2284File Transfer Protocol 2285 2286 2287 150 File status okay; about to open data connection. 2288 250 Requested file action okay, completed. 2289 257 "PATHNAME" created. 2290 350 Requested file action pending further information. 2291 450 Requested file action not taken. 2292 File unavailable (e.g., file busy). 2293 550 Requested action not taken. 2294 File unavailable (e.g., file not found, no access). 2295 451 Requested action aborted. Local error in processing. 2296 551 Requested action aborted. Page type unknown. 2297 452 Requested action not taken. 2298 Insufficient storage space in system. 2299 552 Requested file action aborted. 2300 Exceeded storage allocation (for current directory or 2301 dataset). 2302 553 Requested action not taken. 2303 File name not allowed. 2304 2305 2306 4.2.2 Numeric Order List of Reply Codes 2307 2308 110 Restart marker reply. 2309 In this case, the text is exact and not left to the 2310 particular implementation; it must read: 2311 MARK yyyy = mmmm 2312 Where yyyy is User-process data stream marker, and mmmm 2313 server's equivalent marker (note the spaces between markers 2314 and "="). 2315 120 Service ready in nnn minutes. 2316 125 Data connection already open; transfer starting. 2317 150 File status okay; about to open data connection. 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336Postel & Reynolds [Page 41] 2337 2338 2339 2340RFC 959 October 1985 2341File Transfer Protocol 2342 2343 2344 200 Command okay. 2345 202 Command not implemented, superfluous at this site. 2346 211 System status, or system help reply. 2347 212 Directory status. 2348 213 File status. 2349 214 Help message. 2350 On how to use the server or the meaning of a particular 2351 non-standard command. This reply is useful only to the 2352 human user. 2353 215 NAME system type. 2354 Where NAME is an official system name from the list in the 2355 Assigned Numbers document. 2356 220 Service ready for new user. 2357 221 Service closing control connection. 2358 Logged out if appropriate. 2359 225 Data connection open; no transfer in progress. 2360 226 Closing data connection. 2361 Requested file action successful (for example, file 2362 transfer or file abort). 2363 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). 2364 230 User logged in, proceed. 2365 250 Requested file action okay, completed. 2366 257 "PATHNAME" created. 2367 2368 331 User name okay, need password. 2369 332 Need account for login. 2370 350 Requested file action pending further information. 2371 2372 421 Service not available, closing control connection. 2373 This may be a reply to any command if the service knows it 2374 must shut down. 2375 425 Can't open data connection. 2376 426 Connection closed; transfer aborted. 2377 450 Requested file action not taken. 2378 File unavailable (e.g., file busy). 2379 451 Requested action aborted: local error in processing. 2380 452 Requested action not taken. 2381 Insufficient storage space in system. 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393Postel & Reynolds [Page 42] 2394 2395 2396 2397RFC 959 October 1985 2398File Transfer Protocol 2399 2400 2401 500 Syntax error, command unrecognized. 2402 This may include errors such as command line too long. 2403 501 Syntax error in parameters or arguments. 2404 502 Command not implemented. 2405 503 Bad sequence of commands. 2406 504 Command not implemented for that parameter. 2407 530 Not logged in. 2408 532 Need account for storing files. 2409 550 Requested action not taken. 2410 File unavailable (e.g., file not found, no access). 2411 551 Requested action aborted: page type unknown. 2412 552 Requested file action aborted. 2413 Exceeded storage allocation (for current directory or 2414 dataset). 2415 553 Requested action not taken. 2416 File name not allowed. 2417 2418 24195. DECLARATIVE SPECIFICATIONS 2420 2421 5.1. MINIMUM IMPLEMENTATION 2422 2423 In order to make FTP workable without needless error messages, the 2424 following minimum implementation is required for all servers: 2425 2426 TYPE - ASCII Non-print 2427 MODE - Stream 2428 STRUCTURE - File, Record 2429 COMMANDS - USER, QUIT, PORT, 2430 TYPE, MODE, STRU, 2431 for the default values 2432 RETR, STOR, 2433 NOOP. 2434 2435 The default values for transfer parameters are: 2436 2437 TYPE - ASCII Non-print 2438 MODE - Stream 2439 STRU - File 2440 2441 All hosts must accept the above as the standard defaults. 2442 2443 2444 2445 2446 2447 2448 2449 2450Postel & Reynolds [Page 43] 2451 2452 2453 2454RFC 959 October 1985 2455File Transfer Protocol 2456 2457 2458 5.2. CONNECTIONS 2459 2460 The server protocol interpreter shall "listen" on Port L. The 2461 user or user protocol interpreter shall initiate the full-duplex 2462 control connection. Server- and user- processes should follow the 2463 conventions of the Telnet protocol as specified in the 2464 ARPA-Internet Protocol Handbook [1]. Servers are under no 2465 obligation to provide for editing of command lines and may require 2466 that it be done in the user host. The control connection shall be 2467 closed by the server at the user's request after all transfers and 2468 replies are completed. 2469 2470 The user-DTP must "listen" on the specified data port; this may be 2471 the default user port (U) or a port specified in the PORT command. 2472 The server shall initiate the data connection from his own default 2473 data port (L-1) using the specified user data port. The direction 2474 of the transfer and the port used will be determined by the FTP 2475 service command. 2476 2477 Note that all FTP implementation must support data transfer using 2478 the default port, and that only the USER-PI may initiate the use 2479 of non-default ports. 2480 2481 When data is to be transferred between two servers, A and B (refer 2482 to Figure 2), the user-PI, C, sets up control connections with 2483 both server-PI's. One of the servers, say A, is then sent a PASV 2484 command telling him to "listen" on his data port rather than 2485 initiate a connection when he receives a transfer service command. 2486 When the user-PI receives an acknowledgment to the PASV command, 2487 which includes the identity of the host and port being listened 2488 on, the user-PI then sends A's port, a, to B in a PORT command; a 2489 reply is returned. The user-PI may then send the corresponding 2490 service commands to A and B. Server B initiates the connection 2491 and the transfer proceeds. The command-reply sequence is listed 2492 below where the messages are vertically synchronous but 2493 horizontally asynchronous: 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507Postel & Reynolds [Page 44] 2508 2509 2510 2511RFC 959 October 1985 2512File Transfer Protocol 2513 2514 2515 User-PI - Server A User-PI - Server B 2516 ------------------ ------------------ 2517 2518 C->A : Connect C->B : Connect 2519 C->A : PASV 2520 A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2 2521 C->B : PORT A1,A2,A3,A4,a1,a2 2522 B->C : 200 Okay 2523 C->A : STOR C->B : RETR 2524 B->A : Connect to HOST-A, PORT-a 2525 2526 Figure 3 2527 2528 The data connection shall be closed by the server under the 2529 conditions described in the Section on Establishing Data 2530 Connections. If the data connection is to be closed following a 2531 data transfer where closing the connection is not required to 2532 indicate the end-of-file, the server must do so immediately. 2533 Waiting until after a new transfer command is not permitted 2534 because the user-process will have already tested the data 2535 connection to see if it needs to do a "listen"; (remember that the 2536 user must "listen" on a closed data port BEFORE sending the 2537 transfer request). To prevent a race condition here, the server 2538 sends a reply (226) after closing the data connection (or if the 2539 connection is left open, a "file transfer completed" reply (250) 2540 and the user-PI should wait for one of these replies before 2541 issuing a new transfer command). 2542 2543 Any time either the user or server see that the connection is 2544 being closed by the other side, it should promptly read any 2545 remaining data queued on the connection and issue the close on its 2546 own side. 2547 2548 5.3. COMMANDS 2549 2550 The commands are Telnet character strings transmitted over the 2551 control connections as described in the Section on FTP Commands. 2552 The command functions and semantics are described in the Section 2553 on Access Control Commands, Transfer Parameter Commands, FTP 2554 Service Commands, and Miscellaneous Commands. The command syntax 2555 is specified here. 2556 2557 The commands begin with a command code followed by an argument 2558 field. The command codes are four or fewer alphabetic characters. 2559 Upper and lower case alphabetic characters are to be treated 2560 identically. Thus, any of the following may represent the 2561 retrieve command: 2562 2563 2564Postel & Reynolds [Page 45] 2565 2566 2567 2568RFC 959 October 1985 2569File Transfer Protocol 2570 2571 2572 RETR Retr retr ReTr rETr 2573 2574 This also applies to any symbols representing parameter values, 2575 such as A or a for ASCII TYPE. The command codes and the argument 2576 fields are separated by one or more spaces. 2577 2578 The argument field consists of a variable length character string 2579 ending with the character sequence <CRLF> (Carriage Return, Line 2580 Feed) for NVT-ASCII representation; for other negotiated languages 2581 a different end of line character might be used. It should be 2582 noted that the server is to take no action until the end of line 2583 code is received. 2584 2585 The syntax is specified below in NVT-ASCII. All characters in the 2586 argument field are ASCII characters including any ASCII 2587 represented decimal integers. Square brackets denote an optional 2588 argument field. If the option is not taken, the appropriate 2589 default is implied. 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621Postel & Reynolds [Page 46] 2622 2623 2624 2625RFC 959 October 1985 2626File Transfer Protocol 2627 2628 2629 5.3.1. FTP COMMANDS 2630 2631 The following are the FTP commands: 2632 2633 USER <SP> <username> <CRLF> 2634 PASS <SP> <password> <CRLF> 2635 ACCT <SP> <account-information> <CRLF> 2636 CWD <SP> <pathname> <CRLF> 2637 CDUP <CRLF> 2638 SMNT <SP> <pathname> <CRLF> 2639 QUIT <CRLF> 2640 REIN <CRLF> 2641 PORT <SP> <host-port> <CRLF> 2642 PASV <CRLF> 2643 TYPE <SP> <type-code> <CRLF> 2644 STRU <SP> <structure-code> <CRLF> 2645 MODE <SP> <mode-code> <CRLF> 2646 RETR <SP> <pathname> <CRLF> 2647 STOR <SP> <pathname> <CRLF> 2648 STOU <CRLF> 2649 APPE <SP> <pathname> <CRLF> 2650 ALLO <SP> <decimal-integer> 2651 [<SP> R <SP> <decimal-integer>] <CRLF> 2652 REST <SP> <marker> <CRLF> 2653 RNFR <SP> <pathname> <CRLF> 2654 RNTO <SP> <pathname> <CRLF> 2655 ABOR <CRLF> 2656 DELE <SP> <pathname> <CRLF> 2657 RMD <SP> <pathname> <CRLF> 2658 MKD <SP> <pathname> <CRLF> 2659 PWD <CRLF> 2660 LIST [<SP> <pathname>] <CRLF> 2661 NLST [<SP> <pathname>] <CRLF> 2662 SITE <SP> <string> <CRLF> 2663 SYST <CRLF> 2664 STAT [<SP> <pathname>] <CRLF> 2665 HELP [<SP> <string>] <CRLF> 2666 NOOP <CRLF> 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678Postel & Reynolds [Page 47] 2679 2680 2681 2682RFC 959 October 1985 2683File Transfer Protocol 2684 2685 2686 5.3.2. FTP COMMAND ARGUMENTS 2687 2688 The syntax of the above argument fields (using BNF notation 2689 where applicable) is: 2690 2691 <username> ::= <string> 2692 <password> ::= <string> 2693 <account-information> ::= <string> 2694 <string> ::= <char> | <char><string> 2695 <char> ::= any of the 128 ASCII characters except <CR> and 2696 <LF> 2697 <marker> ::= <pr-string> 2698 <pr-string> ::= <pr-char> | <pr-char><pr-string> 2699 <pr-char> ::= printable characters, any 2700 ASCII code 33 through 126 2701 <byte-size> ::= <number> 2702 <host-port> ::= <host-number>,<port-number> 2703 <host-number> ::= <number>,<number>,<number>,<number> 2704 <port-number> ::= <number>,<number> 2705 <number> ::= any decimal integer 1 through 255 2706 <form-code> ::= N | T | C 2707 <type-code> ::= A [<sp> <form-code>] 2708 | E [<sp> <form-code>] 2709 | I 2710 | L <sp> <byte-size> 2711 <structure-code> ::= F | R | P 2712 <mode-code> ::= S | B | C 2713 <pathname> ::= <string> 2714 <decimal-integer> ::= any decimal integer 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735Postel & Reynolds [Page 48] 2736 2737 2738 2739RFC 959 October 1985 2740File Transfer Protocol 2741 2742 2743 5.4. SEQUENCING OF COMMANDS AND REPLIES 2744 2745 The communication between the user and server is intended to be an 2746 alternating dialogue. As such, the user issues an FTP command and 2747 the server responds with a prompt primary reply. The user should 2748 wait for this initial primary success or failure response before 2749 sending further commands. 2750 2751 Certain commands require a second reply for which the user should 2752 also wait. These replies may, for example, report on the progress 2753 or completion of file transfer or the closing of the data 2754 connection. They are secondary replies to file transfer commands. 2755 2756 One important group of informational replies is the connection 2757 greetings. Under normal circumstances, a server will send a 220 2758 reply, "awaiting input", when the connection is completed. The 2759 user should wait for this greeting message before sending any 2760 commands. If the server is unable to accept input right away, a 2761 120 "expected delay" reply should be sent immediately and a 220 2762 reply when ready. The user will then know not to hang up if there 2763 is a delay. 2764 2765 Spontaneous Replies 2766 2767 Sometimes "the system" spontaneously has a message to be sent 2768 to a user (usually all users). For example, "System going down 2769 in 15 minutes". There is no provision in FTP for such 2770 spontaneous information to be sent from the server to the user. 2771 It is recommended that such information be queued in the 2772 server-PI and delivered to the user-PI in the next reply 2773 (possibly making it a multi-line reply). 2774 2775 The table below lists alternative success and failure replies for 2776 each command. These must be strictly adhered to; a server may 2777 substitute text in the replies, but the meaning and action implied 2778 by the code numbers and by the specific command reply sequence 2779 cannot be altered. 2780 2781 Command-Reply Sequences 2782 2783 In this section, the command-reply sequence is presented. Each 2784 command is listed with its possible replies; command groups are 2785 listed together. Preliminary replies are listed first (with 2786 their succeeding replies indented and under them), then 2787 positive and negative completion, and finally intermediary 2788 2789 2790 2791 2792Postel & Reynolds [Page 49] 2793 2794 2795 2796RFC 959 October 1985 2797File Transfer Protocol 2798 2799 2800 replies with the remaining commands from the sequence 2801 following. This listing forms the basis for the state 2802 diagrams, which will be presented separately. 2803 2804 Connection Establishment 2805 120 2806 220 2807 220 2808 421 2809 Login 2810 USER 2811 230 2812 530 2813 500, 501, 421 2814 331, 332 2815 PASS 2816 230 2817 202 2818 530 2819 500, 501, 503, 421 2820 332 2821 ACCT 2822 230 2823 202 2824 530 2825 500, 501, 503, 421 2826 CWD 2827 250 2828 500, 501, 502, 421, 530, 550 2829 CDUP 2830 200 2831 500, 501, 502, 421, 530, 550 2832 SMNT 2833 202, 250 2834 500, 501, 502, 421, 530, 550 2835 Logout 2836 REIN 2837 120 2838 220 2839 220 2840 421 2841 500, 502 2842 QUIT 2843 221 2844 500 2845 2846 2847 2848 2849Postel & Reynolds [Page 50] 2850 2851 2852 2853RFC 959 October 1985 2854File Transfer Protocol 2855 2856 2857 Transfer parameters 2858 PORT 2859 200 2860 500, 501, 421, 530 2861 PASV 2862 227 2863 500, 501, 502, 421, 530 2864 MODE 2865 200 2866 500, 501, 504, 421, 530 2867 TYPE 2868 200 2869 500, 501, 504, 421, 530 2870 STRU 2871 200 2872 500, 501, 504, 421, 530 2873 File action commands 2874 ALLO 2875 200 2876 202 2877 500, 501, 504, 421, 530 2878 REST 2879 500, 501, 502, 421, 530 2880 350 2881 STOR 2882 125, 150 2883 (110) 2884 226, 250 2885 425, 426, 451, 551, 552 2886 532, 450, 452, 553 2887 500, 501, 421, 530 2888 STOU 2889 125, 150 2890 (110) 2891 226, 250 2892 425, 426, 451, 551, 552 2893 532, 450, 452, 553 2894 500, 501, 421, 530 2895 RETR 2896 125, 150 2897 (110) 2898 226, 250 2899 425, 426, 451 2900 450, 550 2901 500, 501, 421, 530 2902 2903 2904 2905 2906Postel & Reynolds [Page 51] 2907 2908 2909 2910RFC 959 October 1985 2911File Transfer Protocol 2912 2913 2914 LIST 2915 125, 150 2916 226, 250 2917 425, 426, 451 2918 450 2919 500, 501, 502, 421, 530 2920 NLST 2921 125, 150 2922 226, 250 2923 425, 426, 451 2924 450 2925 500, 501, 502, 421, 530 2926 APPE 2927 125, 150 2928 (110) 2929 226, 250 2930 425, 426, 451, 551, 552 2931 532, 450, 550, 452, 553 2932 500, 501, 502, 421, 530 2933 RNFR 2934 450, 550 2935 500, 501, 502, 421, 530 2936 350 2937 RNTO 2938 250 2939 532, 553 2940 500, 501, 502, 503, 421, 530 2941 DELE 2942 250 2943 450, 550 2944 500, 501, 502, 421, 530 2945 RMD 2946 250 2947 500, 501, 502, 421, 530, 550 2948 MKD 2949 257 2950 500, 501, 502, 421, 530, 550 2951 PWD 2952 257 2953 500, 501, 502, 421, 550 2954 ABOR 2955 225, 226 2956 500, 501, 502, 421 2957 2958 2959 2960 2961 2962 2963Postel & Reynolds [Page 52] 2964 2965 2966 2967RFC 959 October 1985 2968File Transfer Protocol 2969 2970 2971 Informational commands 2972 SYST 2973 215 2974 500, 501, 502, 421 2975 STAT 2976 211, 212, 213 2977 450 2978 500, 501, 502, 421, 530 2979 HELP 2980 211, 214 2981 500, 501, 502, 421 2982 Miscellaneous commands 2983 SITE 2984 200 2985 202 2986 500, 501, 530 2987 NOOP 2988 200 2989 500 421 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020Postel & Reynolds [Page 53] 3021 3022 3023 3024RFC 959 October 1985 3025File Transfer Protocol 3026 3027 30286. STATE DIAGRAMS 3029 3030 Here we present state diagrams for a very simple minded FTP 3031 implementation. Only the first digit of the reply codes is used. 3032 There is one state diagram for each group of FTP commands or command 3033 sequences. 3034 3035 The command groupings were determined by constructing a model for 3036 each command then collecting together the commands with structurally 3037 identical models. 3038 3039 For each command or command sequence there are three possible 3040 outcomes: success (S), failure (F), and error (E). In the state 3041 diagrams below we use the symbol B for "begin", and the symbol W for 3042 "wait for reply". 3043 3044 We first present the diagram that represents the largest group of FTP 3045 commands: 3046 3047 3048 1,3 +---+ 3049 ----------->| E | 3050 | +---+ 3051 | 3052 +---+ cmd +---+ 2 +---+ 3053 | B |---------->| W |---------->| S | 3054 +---+ +---+ +---+ 3055 | 3056 | 4,5 +---+ 3057 ----------->| F | 3058 +---+ 3059 3060 3061 This diagram models the commands: 3062 3063 ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, 3064 QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE. 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077Postel & Reynolds [Page 54] 3078 3079 3080 3081RFC 959 October 1985 3082File Transfer Protocol 3083 3084 3085 The other large group of commands is represented by a very similar 3086 diagram: 3087 3088 3089 3 +---+ 3090 ----------->| E | 3091 | +---+ 3092 | 3093 +---+ cmd +---+ 2 +---+ 3094 | B |---------->| W |---------->| S | 3095 +---+ --->+---+ +---+ 3096 | | | 3097 | | | 4,5 +---+ 3098 | 1 | ----------->| F | 3099 ----- +---+ 3100 3101 3102 This diagram models the commands: 3103 3104 APPE, LIST, NLST, REIN, RETR, STOR, and STOU. 3105 3106 Note that this second model could also be used to represent the first 3107 group of commands, the only difference being that in the first group 3108 the 100 series replies are unexpected and therefore treated as error, 3109 while the second group expects (some may require) 100 series replies. 3110 Remember that at most, one 100 series reply is allowed per command. 3111 3112 The remaining diagrams model command sequences, perhaps the simplest 3113 of these is the rename sequence: 3114 3115 3116 +---+ RNFR +---+ 1,2 +---+ 3117 | B |---------->| W |---------->| E | 3118 +---+ +---+ -->+---+ 3119 | | | 3120 3 | | 4,5 | 3121 -------------- ------ | 3122 | | | +---+ 3123 | ------------->| S | 3124 | | 1,3 | | +---+ 3125 | 2| -------- 3126 | | | | 3127 V | | | 3128 +---+ RNTO +---+ 4,5 ----->+---+ 3129 | |---------->| W |---------->| F | 3130 +---+ +---+ +---+ 3131 3132 3133 3134Postel & Reynolds [Page 55] 3135 3136 3137 3138RFC 959 October 1985 3139File Transfer Protocol 3140 3141 3142 The next diagram is a simple model of the Restart command: 3143 3144 3145 +---+ REST +---+ 1,2 +---+ 3146 | B |---------->| W |---------->| E | 3147 +---+ +---+ -->+---+ 3148 | | | 3149 3 | | 4,5 | 3150 -------------- ------ | 3151 | | | +---+ 3152 | ------------->| S | 3153 | | 3 | | +---+ 3154 | 2| -------- 3155 | | | | 3156 V | | | 3157 +---+ cmd +---+ 4,5 ----->+---+ 3158 | |---------->| W |---------->| F | 3159 +---+ -->+---+ +---+ 3160 | | 3161 | 1 | 3162 ------ 3163 3164 3165 Where "cmd" is APPE, STOR, or RETR. 3166 3167 We note that the above three models are similar. The Restart differs 3168 from the Rename two only in the treatment of 100 series replies at 3169 the second stage, while the second group expects (some may require) 3170 100 series replies. Remember that at most, one 100 series reply is 3171 allowed per command. 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191Postel & Reynolds [Page 56] 3192 3193 3194 3195RFC 959 October 1985 3196File Transfer Protocol 3197 3198 3199 The most complicated diagram is for the Login sequence: 3200 3201 3202 1 3203 +---+ USER +---+------------->+---+ 3204 | B |---------->| W | 2 ---->| E | 3205 +---+ +---+------ | -->+---+ 3206 | | | | | 3207 3 | | 4,5 | | | 3208 -------------- ----- | | | 3209 | | | | | 3210 | | | | | 3211 | --------- | 3212 | 1| | | | 3213 V | | | | 3214 +---+ PASS +---+ 2 | ------>+---+ 3215 | |---------->| W |------------->| S | 3216 +---+ +---+ ---------->+---+ 3217 | | | | | 3218 3 | |4,5| | | 3219 -------------- -------- | 3220 | | | | | 3221 | | | | | 3222 | ----------- 3223 | 1,3| | | | 3224 V | 2| | | 3225 +---+ ACCT +---+-- | ----->+---+ 3226 | |---------->| W | 4,5 -------->| F | 3227 +---+ +---+------------->+---+ 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248Postel & Reynolds [Page 57] 3249 3250 3251 3252RFC 959 October 1985 3253File Transfer Protocol 3254 3255 3256 Finally, we present a generalized diagram that could be used to model 3257 the command and reply interchange: 3258 3259 3260 ------------------------------------ 3261 | | 3262 Begin | | 3263 | V | 3264 | +---+ cmd +---+ 2 +---+ | 3265 -->| |------->| |---------->| | | 3266 | | | W | | S |-----| 3267 -->| | -->| |----- | | | 3268 | +---+ | +---+ 4,5 | +---+ | 3269 | | | | | | | 3270 | | | 1| |3 | +---+ | 3271 | | | | | | | | | 3272 | | ---- | ---->| F |----- 3273 | | | | | 3274 | | | +---+ 3275 ------------------- 3276 | 3277 | 3278 V 3279 End 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305Postel & Reynolds [Page 58] 3306 3307 3308 3309RFC 959 October 1985 3310File Transfer Protocol 3311 3312 33137. TYPICAL FTP SCENARIO 3314 3315 User at host U wanting to transfer files to/from host S: 3316 3317 In general, the user will communicate to the server via a mediating 3318 user-FTP process. The following may be a typical scenario. The 3319 user-FTP prompts are shown in parentheses, '---->' represents 3320 commands from host U to host S, and '<----' represents replies from 3321 host S to host U. 3322 3323 LOCAL COMMANDS BY USER ACTION INVOLVED 3324 3325 ftp (host) multics<CR> Connect to host S, port L, 3326 establishing control connections. 3327 <---- 220 Service ready <CRLF>. 3328 username Doe <CR> USER Doe<CRLF>----> 3329 <---- 331 User name ok, 3330 need password<CRLF>. 3331 password mumble <CR> PASS mumble<CRLF>----> 3332 <---- 230 User logged in<CRLF>. 3333 retrieve (local type) ASCII<CR> 3334 (local pathname) test 1 <CR> User-FTP opens local file in ASCII. 3335 (for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ----> 3336 <---- 150 File status okay; 3337 about to open data 3338 connection<CRLF>. 3339 Server makes data connection 3340 to port U. 3341 3342 <---- 226 Closing data connection, 3343 file transfer successful<CRLF>. 3344 type Image<CR> TYPE I<CRLF> ----> 3345 <---- 200 Command OK<CRLF> 3346 store (local type) image<CR> 3347 (local pathname) file dump<CR> User-FTP opens local file in Image. 3348 (for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ----> 3349 <---- 550 Access denied<CRLF> 3350 terminate QUIT <CRLF> ----> 3351 Server closes all 3352 connections. 3353 33548. CONNECTION ESTABLISHMENT 3355 3356 The FTP control connection is established via TCP between the user 3357 process port U and the server process port L. This protocol is 3358 assigned the service port 21 (25 octal), that is L=21. 3359 3360 3361 3362Postel & Reynolds [Page 59] 3363 3364 3365 3366RFC 959 October 1985 3367File Transfer Protocol 3368 3369 3370APPENDIX I - PAGE STRUCTURE 3371 3372 The need for FTP to support page structure derives principally from 3373 the need to support efficient transmission of files between TOPS-20 3374 systems, particularly the files used by NLS. 3375 3376 The file system of TOPS-20 is based on the concept of pages. The 3377 operating system is most efficient at manipulating files as pages. 3378 The operating system provides an interface to the file system so that 3379 many applications view files as sequential streams of characters. 3380 However, a few applications use the underlying page structures 3381 directly, and some of these create holey files. 3382 3383 A TOPS-20 disk file consists of four things: a pathname, a page 3384 table, a (possibly empty) set of pages, and a set of attributes. 3385 3386 The pathname is specified in the RETR or STOR command. It includes 3387 the directory name, file name, file name extension, and generation 3388 number. 3389 3390 The page table contains up to 2**18 entries. Each entry may be 3391 EMPTY, or may point to a page. If it is not empty, there are also 3392 some page-specific access bits; not all pages of a file need have the 3393 same access protection. 3394 3395 A page is a contiguous set of 512 words of 36 bits each. 3396 3397 The attributes of the file, in the File Descriptor Block (FDB), 3398 contain such things as creation time, write time, read time, writer's 3399 byte-size, end-of-file pointer, count of reads and writes, backup 3400 system tape numbers, etc. 3401 3402 Note that there is NO requirement that entries in the page table be 3403 contiguous. There may be empty page table slots between occupied 3404 ones. Also, the end of file pointer is simply a number. There is no 3405 requirement that it in fact point at the "last" datum in the file. 3406 Ordinary sequential I/O calls in TOPS-20 will cause the end of file 3407 pointer to be left after the last datum written, but other operations 3408 may cause it not to be so, if a particular programming system so 3409 requires. 3410 3411 In fact, in both of these special cases, "holey" files and 3412 end-of-file pointers NOT at the end of the file, occur with NLS data 3413 files. 3414 3415 3416 3417 3418 3419Postel & Reynolds [Page 60] 3420 3421 3422 3423RFC 959 October 1985 3424File Transfer Protocol 3425 3426 3427 The TOPS-20 paged files can be sent with the FTP transfer parameters: 3428 TYPE L 36, STRU P, and MODE S (in fact, any mode could be used). 3429 3430 Each page of information has a header. Each header field, which is a 3431 logical byte, is a TOPS-20 word, since the TYPE is L 36. 3432 3433 The header fields are: 3434 3435 Word 0: Header Length. 3436 3437 The header length is 5. 3438 3439 Word 1: Page Index. 3440 3441 If the data is a disk file page, this is the number of that 3442 page in the file's page map. Empty pages (holes) in the file 3443 are simply not sent. Note that a hole is NOT the same as a 3444 page of zeros. 3445 3446 Word 2: Data Length. 3447 3448 The number of data words in this page, following the header. 3449 Thus, the total length of the transmission unit is the Header 3450 Length plus the Data Length. 3451 3452 Word 3: Page Type. 3453 3454 A code for what type of chunk this is. A data page is type 3, 3455 the FDB page is type 2. 3456 3457 Word 4: Page Access Control. 3458 3459 The access bits associated with the page in the file's page 3460 map. (This full word quantity is put into AC2 of an SPACS by 3461 the program reading from net to disk.) 3462 3463 After the header are Data Length data words. Data Length is 3464 currently either 512 for a data page or 31 for an FDB. Trailing 3465 zeros in a disk file page may be discarded, making Data Length less 3466 than 512 in that case. 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476Postel & Reynolds [Page 61] 3477 3478 3479 3480RFC 959 October 1985 3481File Transfer Protocol 3482 3483 3484APPENDIX II - DIRECTORY COMMANDS 3485 3486 Since UNIX has a tree-like directory structure in which directories 3487 are as easy to manipulate as ordinary files, it is useful to expand 3488 the FTP servers on these machines to include commands which deal with 3489 the creation of directories. Since there are other hosts on the 3490 ARPA-Internet which have tree-like directories (including TOPS-20 and 3491 Multics), these commands are as general as possible. 3492 3493 Four directory commands have been added to FTP: 3494 3495 MKD pathname 3496 3497 Make a directory with the name "pathname". 3498 3499 RMD pathname 3500 3501 Remove the directory with the name "pathname". 3502 3503 PWD 3504 3505 Print the current working directory name. 3506 3507 CDUP 3508 3509 Change to the parent of the current working directory. 3510 3511 The "pathname" argument should be created (removed) as a 3512 subdirectory of the current working directory, unless the "pathname" 3513 string contains sufficient information to specify otherwise to the 3514 server, e.g., "pathname" is an absolute pathname (in UNIX and 3515 Multics), or pathname is something like "<abso.lute.path>" to 3516 TOPS-20. 3517 3518 REPLY CODES 3519 3520 The CDUP command is a special case of CWD, and is included to 3521 simplify the implementation of programs for transferring directory 3522 trees between operating systems having different syntaxes for 3523 naming the parent directory. The reply codes for CDUP be 3524 identical to the reply codes of CWD. 3525 3526 The reply codes for RMD be identical to the reply codes for its 3527 file analogue, DELE. 3528 3529 The reply codes for MKD, however, are a bit more complicated. A 3530 freshly created directory will probably be the object of a future 3531 3532 3533Postel & Reynolds [Page 62] 3534 3535 3536 3537RFC 959 October 1985 3538File Transfer Protocol 3539 3540 3541 CWD command. Unfortunately, the argument to MKD may not always be 3542 a suitable argument for CWD. This is the case, for example, when 3543 a TOPS-20 subdirectory is created by giving just the subdirectory 3544 name. That is, with a TOPS-20 server FTP, the command sequence 3545 3546 MKD MYDIR 3547 CWD MYDIR 3548 3549 will fail. The new directory may only be referred to by its 3550 "absolute" name; e.g., if the MKD command above were issued while 3551 connected to the directory <DFRANKLIN>, the new subdirectory 3552 could only be referred to by the name <DFRANKLIN.MYDIR>. 3553 3554 Even on UNIX and Multics, however, the argument given to MKD may 3555 not be suitable. If it is a "relative" pathname (i.e., a pathname 3556 which is interpreted relative to the current directory), the user 3557 would need to be in the same current directory in order to reach 3558 the subdirectory. Depending on the application, this may be 3559 inconvenient. It is not very robust in any case. 3560 3561 To solve these problems, upon successful completion of an MKD 3562 command, the server should return a line of the form: 3563 3564 257<space>"<directory-name>"<space><commentary> 3565 3566 That is, the server will tell the user what string to use when 3567 referring to the created directory. The directory name can 3568 contain any character; embedded double-quotes should be escaped by 3569 double-quotes (the "quote-doubling" convention). 3570 3571 For example, a user connects to the directory /usr/dm, and creates 3572 a subdirectory, named pathname: 3573 3574 CWD /usr/dm 3575 200 directory changed to /usr/dm 3576 MKD pathname 3577 257 "/usr/dm/pathname" directory created 3578 3579 An example with an embedded double quote: 3580 3581 MKD foo"bar 3582 257 "/usr/dm/foo""bar" directory created 3583 CWD /usr/dm/foo"bar 3584 200 directory changed to /usr/dm/foo"bar 3585 3586 3587 3588 3589 3590Postel & Reynolds [Page 63] 3591 3592 3593 3594RFC 959 October 1985 3595File Transfer Protocol 3596 3597 3598 The prior existence of a subdirectory with the same name is an 3599 error, and the server must return an "access denied" error reply 3600 in that case. 3601 3602 CWD /usr/dm 3603 200 directory changed to /usr/dm 3604 MKD pathname 3605 521-"/usr/dm/pathname" directory already exists; 3606 521 taking no action. 3607 3608 The failure replies for MKD are analogous to its file creating 3609 cousin, STOR. Also, an "access denied" return is given if a file 3610 name with the same name as the subdirectory will conflict with the 3611 creation of the subdirectory (this is a problem on UNIX, but 3612 shouldn't be one on TOPS-20). 3613 3614 Essentially because the PWD command returns the same type of 3615 information as the successful MKD command, the successful PWD 3616 command uses the 257 reply code as well. 3617 3618 SUBTLETIES 3619 3620 Because these commands will be most useful in transferring 3621 subtrees from one machine to another, carefully observe that the 3622 argument to MKD is to be interpreted as a sub-directory of the 3623 current working directory, unless it contains enough information 3624 for the destination host to tell otherwise. A hypothetical 3625 example of its use in the TOPS-20 world: 3626 3627 CWD <some.where> 3628 200 Working directory changed 3629 MKD overrainbow 3630 257 "<some.where.overrainbow>" directory created 3631 CWD overrainbow 3632 431 No such directory 3633 CWD <some.where.overrainbow> 3634 200 Working directory changed 3635 3636 CWD <some.where> 3637 200 Working directory changed to <some.where> 3638 MKD <unambiguous> 3639 257 "<unambiguous>" directory created 3640 CWD <unambiguous> 3641 3642 Note that the first example results in a subdirectory of the 3643 connected directory. In contrast, the argument in the second 3644 example contains enough information for TOPS-20 to tell that the 3645 3646 3647Postel & Reynolds [Page 64] 3648 3649 3650 3651RFC 959 October 1985 3652File Transfer Protocol 3653 3654 3655 <unambiguous> directory is a top-level directory. Note also that 3656 in the first example the user "violated" the protocol by 3657 attempting to access the freshly created directory with a name 3658 other than the one returned by TOPS-20. Problems could have 3659 resulted in this case had there been an <overrainbow> directory; 3660 this is an ambiguity inherent in some TOPS-20 implementations. 3661 Similar considerations apply to the RMD command. The point is 3662 this: except where to do so would violate a host's conventions for 3663 denoting relative versus absolute pathnames, the host should treat 3664 the operands of the MKD and RMD commands as subdirectories. The 3665 257 reply to the MKD command must always contain the absolute 3666 pathname of the created directory. 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704Postel & Reynolds [Page 65] 3705 3706 3707 3708RFC 959 October 1985 3709File Transfer Protocol 3710 3711 3712APPENDIX III - RFCs on FTP 3713 3714 Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823), 3715 MIT-Project MAC, 16 April 1971. 3716 3717 Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File 3718 Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971. 3719 3720 Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172 3721 (NIC 6794), MIT-Project MAC, 23 June 1971. 3722 3723 Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663), 3724 UCLA/CCN, 29 September 1971. 3725 3726 Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265 3727 (NIC 7813), MIT-Project MAC, 17 November 1971. 3728 3729 McKenzie, Alex, "A Suggested Addition to File Transfer Protocol", 3730 RFC 281 (NIC 8163), BBN, 8 December 1971. 3731 3732 Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File 3733 Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC, 3734 25 January 1972. 3735 3736 Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596), 3737 MIT-Project MAC, 8 July 1972. 3738 3739 Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)", 3740 RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972. 3741 3742 Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah, 3743 27 November 1972. 3744 3745 Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further 3746 Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972. 3747 3748 Braden, Bob, "Comments on File Transfer Protocol", RFC 430 3749 (NIC 13299), UCLA/CCN, 7 February 1973. 3750 3751 Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction", 3752 RFC 438 (NIC 13770), BBN, 15 January 1973. 3753 3754 Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN, 3755 27 February 1973. 3756 3757 McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN, 3758 16 February 1973. 3759 3760 3761Postel & Reynolds [Page 66] 3762 3763 3764 3765RFC 959 October 1985 3766File Transfer Protocol 3767 3768 3769 Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458 3770 (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973. 3771 3772 Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN, 3773 12 July 1973. 3774 3775 Krilanovich, Mark, and George Gregg, "Comments on the File Transfer 3776 Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974. 3777 3778 Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the 3779 File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974. 3780 3781 Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White, 3782 "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB, 3783 Ames Research Center, SRI-ARC, 28 February 1974. 3784 3785 Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463 3786 (NIC 14573), MIT-DMCG, 21 February 1973. 3787 3788 Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN, 3789 8 March 1973. 3790 3791 Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919), 3792 MIT-DMCG, 6 March 1973. 3793 3794 Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II", 3795 RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973. 3796 3797 White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948), 3798 SRI-ARC, 8 March 1973. 3799 3800 White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949), 3801 SRI-ARC, 8 March 1973. 3802 3803 Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506 3804 (NIC 16157), MIT-Multics, 26 June 1973. 3805 3806 Day, John, "Memo to FTP Group (Proposal for File Access Protocol)", 3807 RFC 520 (NIC 16819), Illinois, 25 June 1973. 3808 3809 Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532 3810 (NIC 17451), UCSD-CC, 22 June 1973. 3811 3812 Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN, 3813 15 November 1973. 3814 3815 3816 3817 3818Postel & Reynolds [Page 67] 3819 3820 3821 3822RFC 959 October 1985 3823File Transfer Protocol 3824 3825 3826 McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation - 3827 Schedule Change", RFC 593 (NIC 20615), BBN and MITRE, 3828 29 November 1973. 3829 3830 Sussman, Julie, "FTP Error Code Usage for More Reliable Mail 3831 Service", RFC 630 (NIC 30237), BBN, 10 April 1974. 3832 3833 Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843), 3834 UCLA/NMC, 5 June 1974. 3835 3836 Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481), 3837 SU-AI, 10 May 1975. 3838 3839 Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI, 3840 28 May 1975. 3841 3842 Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975. 3843 3844 Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL, 3845 31 October 1977. 3846 3847 Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758), 3848 SRI-KL, 30 December 1977. 3849 3850 Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT, 3851 10 December 1978. 3852 3853 Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI, 3854 June 1980. 3855 3856 Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP 3857 Commands", RFC 776, BBN, December 1980. 3858 3859 Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE, 3860 July 1985. 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875Postel & Reynolds [Page 68] 3876 3877 3878 3879RFC 959 October 1985 3880File Transfer Protocol 3881 3882 3883REFERENCES 3884 3885 [1] Feinler, Elizabeth, "Internet Protocol Transition Workbook", 3886 Network Information Center, SRI International, March 1982. 3887 3888 [2] Postel, Jon, "Transmission Control Protocol - DARPA Internet 3889 Program Protocol Specification", RFC 793, DARPA, September 1981. 3890 3891 [3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol 3892 Specification", RFC 854, ISI, May 1983. 3893 3894 [4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943, 3895 ISI, April 1985. 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932Postel & Reynolds [Page 69] 3933 3934