From e57c35f00e5eba0ee5199997238cf3179a89c4d2 Mon Sep 17 00:00:00 2001
From: Pixel <Pixel>
Date: Mon, 12 Nov 2001 19:49:16 +0000
Subject: Plop

---
 doc/Makefile.am   |    2 +-
 doc/rfc959.txt    | 3933 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/Task.h    |    2 -
 lib/Exceptions.cc |   30 +-
 lib/Handle.cc     |    4 +-
 lib/ReadJob.cc    |    8 +-
 lib/Task.cc       |    7 +-
 7 files changed, 3972 insertions(+), 14 deletions(-)
 create mode 100644 doc/rfc959.txt

diff --git a/doc/Makefile.am b/doc/Makefile.am
index c2fbeff..52b3f66 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1 +1 @@
-EXTRA_DIST = rfc1866.txt rfc2616.txt rfc2812.txt messages
+EXTRA_DIST = rfc959.txt rfc1866.txt rfc2616.txt rfc2812.txt messages
diff --git a/doc/rfc959.txt b/doc/rfc959.txt
new file mode 100644
index 0000000..1d7ce14
--- /dev/null
+++ b/doc/rfc959.txt
@@ -0,0 +1,3933 @@
+
+                                                                        
+Network Working Group                                          J. Postel
+Request for Comments: 959                                    J. Reynolds
+                                                                     ISI
+Obsoletes RFC: 765 (IEN 149)                                October 1985
+
+                      FILE TRANSFER PROTOCOL (FTP)
+
+
+Status of this Memo
+
+   This memo is the official specification of the File Transfer
+   Protocol (FTP).  Distribution of this memo is unlimited.
+
+   The following new optional commands are included in this edition of
+   the specification:
+
+      CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU
+      (Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD
+      (Print Directory), and SYST (System).
+
+   Note that this specification is compatible with the previous edition.
+
+1.  INTRODUCTION
+
+   The objectives of FTP are 1) to promote sharing of files (computer
+   programs and/or data), 2) to encourage indirect or implicit (via
+   programs) use of remote computers, 3) to shield a user from
+   variations in file storage systems among hosts, and 4) to transfer
+   data reliably and efficiently.  FTP, though usable directly by a user
+   at a terminal, is designed mainly for use by programs.
+
+   The attempt in this specification is to satisfy the diverse needs of
+   users of maxi-hosts, mini-hosts, personal workstations, and TACs,
+   with a simple, and easily implemented protocol design.
+
+   This paper assumes knowledge of the Transmission Control Protocol
+   (TCP) [2] and the Telnet Protocol [3].  These documents are contained
+   in the ARPA-Internet protocol handbook [1].
+
+2.  OVERVIEW
+
+   In this section, the history, the terminology, and the FTP model are
+   discussed.  The terms defined in this section are only those that
+   have special significance in FTP.  Some of the terminology is very
+   specific to the FTP model; some readers may wish to turn to the
+   section on the FTP model while reviewing the terminology.
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 1]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   2.1.  HISTORY
+
+      FTP has had a long evolution over the years.  Appendix III is a
+      chronological compilation of Request for Comments documents
+      relating to FTP.  These include the first proposed file transfer
+      mechanisms in 1971 that were developed for implementation on hosts
+      at M.I.T. (RFC 114), plus comments and discussion in RFC 141.
+
+      RFC 172 provided a user-level oriented protocol for file transfer
+      between host computers (including terminal IMPs).  A revision of
+      this as RFC 265, restated FTP for additional review, while RFC 281
+      suggested further changes.  The use of a "Set Data Type"
+      transaction was proposed in RFC 294 in January 1982.
+
+      RFC 354 obsoleted RFCs 264 and 265.  The File Transfer Protocol
+      was now defined as a protocol for file transfer between HOSTs on
+      the ARPANET, with the primary function of FTP defined as
+      transfering files efficiently and reliably among hosts and
+      allowing the convenient use of remote file storage capabilities.
+      RFC 385 further commented on errors, emphasis points, and
+      additions to the protocol, while RFC 414 provided a status report
+      on the working server and user FTPs.  RFC 430, issued in 1973,
+      (among other RFCs too numerous to mention) presented further
+      comments on FTP.  Finally, an "official" FTP document was
+      published as RFC 454.
+
+      By July 1973, considerable changes from the last versions of FTP
+      were made, but the general structure remained the same.  RFC 542
+      was published as a new "official" specification to reflect these
+      changes.  However, many implementations based on the older
+      specification were not updated.
+
+      In 1974, RFCs 607 and 614 continued comments on FTP.  RFC 624
+      proposed further design changes and minor modifications.  In 1975,
+      RFC 686 entitled, "Leaving Well Enough Alone", discussed the
+      differences between all of the early and later versions of FTP.
+      RFC 691 presented a minor revision of RFC 686, regarding the
+      subject of print files.
+
+      Motivated by the transition from the NCP to the TCP as the
+      underlying protocol, a phoenix was born out of all of the above
+      efforts in RFC 765 as the specification of FTP for use on TCP.
+
+      This current edition of the FTP specification is intended to
+      correct some minor documentation errors, to improve the
+      explanation of some protocol features, and to add some new
+      optional commands.
+
+
+Postel & Reynolds                                               [Page 2]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      In particular, the following new optional commands are included in
+      this edition of the specification:
+
+         CDUP - Change to Parent Directory
+
+         SMNT - Structure Mount
+
+         STOU - Store Unique
+
+         RMD - Remove Directory
+
+         MKD - Make Directory
+
+         PWD - Print Directory
+
+         SYST - System
+
+      This specification is compatible with the previous edition.  A
+      program implemented in conformance to the previous specification
+      should automatically be in conformance to this specification.
+
+   2.2.  TERMINOLOGY
+
+      ASCII
+
+         The ASCII character set is as defined in the ARPA-Internet
+         Protocol Handbook.  In FTP, ASCII characters are defined to be
+         the lower half of an eight-bit code set (i.e., the most
+         significant bit is zero).
+
+      access controls
+
+         Access controls define users' access privileges to the use of a
+         system, and to the files in that system.  Access controls are
+         necessary to prevent unauthorized or accidental use of files.
+         It is the prerogative of a server-FTP process to invoke access
+         controls.
+
+      byte size
+
+         There are two byte sizes of interest in FTP:  the logical byte
+         size of the file, and the transfer byte size used for the
+         transmission of the data.  The transfer byte size is always 8
+         bits.  The transfer byte size is not necessarily the byte size
+         in which data is to be stored in a system, nor the logical byte
+         size for interpretation of the structure of the data.
+
+
+
+Postel & Reynolds                                               [Page 3]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      control connection
+
+         The communication path between the USER-PI and SERVER-PI for
+         the exchange of commands and replies.  This connection follows
+         the Telnet Protocol.
+
+      data connection
+
+         A full duplex connection over which data is transferred, in a
+         specified mode and type. The data transferred may be a part of
+         a file, an entire file or a number of files.  The path may be
+         between a server-DTP and a user-DTP, or between two
+         server-DTPs.
+
+      data port
+
+         The passive data transfer process "listens" on the data port
+         for a connection from the active transfer process in order to
+         open the data connection.
+
+      DTP
+
+         The data transfer process establishes and manages the data
+         connection.  The DTP can be passive or active.
+
+      End-of-Line
+
+         The end-of-line sequence defines the separation of printing
+         lines.  The sequence is Carriage Return, followed by Line Feed.
+
+      EOF
+
+         The end-of-file condition that defines the end of a file being
+         transferred.
+
+      EOR
+
+         The end-of-record condition that defines the end of a record
+         being transferred.
+
+      error recovery
+
+         A procedure that allows a user to recover from certain errors
+         such as failure of either host system or transfer process.  In
+         FTP, error recovery may involve restarting a file transfer at a
+         given checkpoint.
+
+
+
+Postel & Reynolds                                               [Page 4]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      FTP commands
+
+         A set of commands that comprise the control information flowing
+         from the user-FTP to the server-FTP process.
+
+      file
+
+         An ordered set of computer data (including programs), of
+         arbitrary length, uniquely identified by a pathname.
+
+      mode
+
+         The mode in which data is to be transferred via the data
+         connection.  The mode defines the data format during transfer
+         including EOR and EOF.  The transfer modes defined in FTP are
+         described in the Section on Transmission Modes.
+
+      NVT
+
+         The Network Virtual Terminal as defined in the Telnet Protocol.
+
+      NVFS
+
+         The Network Virtual File System.  A concept which defines a
+         standard network file system with standard commands and
+         pathname conventions.
+
+      page
+
+         A file may be structured as a set of independent parts called
+         pages.  FTP supports the transmission of discontinuous files as
+         independent indexed pages.
+
+      pathname
+
+         Pathname is defined to be the character string which must be
+         input to a file system by a user in order to identify a file.
+         Pathname normally contains device and/or directory names, and
+         file name specification.  FTP does not yet specify a standard
+         pathname convention.  Each user must follow the file naming
+         conventions of the file systems involved in the transfer.
+
+      PI
+
+         The protocol interpreter.  The user and server sides of the
+         protocol have distinct roles implemented in a user-PI and a
+         server-PI.
+
+
+Postel & Reynolds                                               [Page 5]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      record
+
+         A sequential file may be structured as a number of contiguous
+         parts called records.  Record structures are supported by FTP
+         but a file need not have record structure.
+
+      reply
+
+         A reply is an acknowledgment (positive or negative) sent from
+         server to user via the control connection in response to FTP
+         commands.  The general form of a reply is a completion code
+         (including error codes) followed by a text string.  The codes
+         are for use by programs and the text is usually intended for
+         human users.
+
+      server-DTP
+
+         The data transfer process, in its normal "active" state,
+         establishes the data connection with the "listening" data port.
+         It sets up parameters for transfer and storage, and transfers
+         data on command from its PI.  The DTP can be placed in a
+         "passive" state to listen for, rather than initiate a
+         connection on the data port.
+
+      server-FTP process
+
+         A process or set of processes which perform the function of
+         file transfer in cooperation with a user-FTP process and,
+         possibly, another server.  The functions consist of a protocol
+         interpreter (PI) and a data transfer process (DTP).
+
+      server-PI
+
+         The server protocol interpreter "listens" on Port L for a
+         connection from a user-PI and establishes a control
+         communication connection.  It receives standard FTP commands
+         from the user-PI, sends replies, and governs the server-DTP.
+
+      type
+
+         The data representation type used for data transfer and
+         storage.  Type implies certain transformations between the time
+         of data storage and data transfer.  The representation types
+         defined in FTP are described in the Section on Establishing
+         Data Connections.
+
+
+
+
+Postel & Reynolds                                               [Page 6]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      user
+
+         A person or a process on behalf of a person wishing to obtain
+         file transfer service.  The human user may interact directly
+         with a server-FTP process, but use of a user-FTP process is
+         preferred since the protocol design is weighted towards
+         automata.
+
+      user-DTP
+
+         The data transfer process "listens" on the data port for a
+         connection from a server-FTP process.  If two servers are
+         transferring data between them, the user-DTP is inactive.
+
+      user-FTP process
+
+         A set of functions including a protocol interpreter, a data
+         transfer process and a user interface which together perform
+         the function of file transfer in cooperation with one or more
+         server-FTP processes.  The user interface allows a local
+         language to be used in the command-reply dialogue with the
+         user.
+
+      user-PI
+
+         The user protocol interpreter initiates the control connection
+         from its port U to the server-FTP process, initiates FTP
+         commands, and governs the user-DTP if that process is part of
+         the file transfer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 7]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   2.3.  THE FTP MODEL
+
+      With the above definitions in mind, the following model (shown in
+      Figure 1) may be diagrammed for an FTP service.
+
+                                            -------------
+                                            |/---------\|
+                                            ||   User  ||    --------
+                                            ||Interface|<--->| User |
+                                            |\----^----/|    --------
+                  ----------                |     |     |
+                  |/------\|  FTP Commands  |/----V----\|
+                  ||Server|<---------------->|   User  ||
+                  ||  PI  ||   FTP Replies  ||    PI   ||
+                  |\--^---/|                |\----^----/|
+                  |   |    |                |     |     |
+      --------    |/--V---\|      Data      |/----V----\|    --------
+      | File |<--->|Server|<---------------->|  User   |<--->| File |
+      |System|    || DTP  ||   Connection   ||   DTP   ||    |System|
+      --------    |\------/|                |\---------/|    --------
+                  ----------                -------------
+
+                  Server-FTP                   USER-FTP
+
+      NOTES: 1. The data connection may be used in either direction.
+             2. The data connection need not exist all of the time.
+
+                      Figure 1  Model for FTP Use
+
+      In the model described in Figure 1, the user-protocol interpreter
+      initiates the control connection.  The control connection follows
+      the Telnet protocol.  At the initiation of the user, standard FTP
+      commands are generated by the user-PI and transmitted to the
+      server process via the control connection.  (The user may
+      establish a direct control connection to the server-FTP, from a
+      TAC terminal for example, and generate standard FTP commands
+      independently, bypassing the user-FTP process.) Standard replies
+      are sent from the server-PI to the user-PI over the control
+      connection in response to the commands.
+
+      The FTP commands specify the parameters for the data connection
+      (data port, transfer mode, representation type, and structure) and
+      the nature of file system operation (store, retrieve, append,
+      delete, etc.).  The user-DTP or its designate should "listen" on
+      the specified data port, and the server initiate the data
+      connection and data transfer in accordance with the specified
+      parameters.  It should be noted that the data port need not be in
+
+
+Postel & Reynolds                                               [Page 8]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      the same host that initiates the FTP commands via the control
+      connection, but the user or the user-FTP process must ensure a
+      "listen" on the specified data port.  It ought to also be noted
+      that the data connection may be used for simultaneous sending and
+      receiving.
+
+      In another situation a user might wish to transfer files between
+      two hosts, neither of which is a local host. The user sets up
+      control connections to the two servers and then arranges for a
+      data connection between them.  In this manner, control information
+      is passed to the user-PI but data is transferred between the
+      server data transfer processes.  Following is a model of this
+      server-server interaction.
+
+      
+                    Control     ------------   Control
+                    ---------->| User-FTP |<-----------
+                    |          | User-PI  |           |
+                    |          |   "C"    |           |
+                    V          ------------           V
+            --------------                        --------------
+            | Server-FTP |   Data Connection      | Server-FTP |
+            |    "A"     |<---------------------->|    "B"     |
+            -------------- Port (A)      Port (B) --------------
+      
+
+                                 Figure 2
+
+      The protocol requires that the control connections be open while
+      data transfer is in progress.  It is the responsibility of the
+      user to request the closing of the control connections when
+      finished using the FTP service, while it is the server who takes
+      the action.  The server may abort data transfer if the control
+      connections are closed without command.
+
+      The Relationship between FTP and Telnet:
+
+         The FTP uses the Telnet protocol on the control connection.
+         This can be achieved in two ways: first, the user-PI or the
+         server-PI may implement the rules of the Telnet Protocol
+         directly in their own procedures; or, second, the user-PI or
+         the server-PI may make use of the existing Telnet module in the
+         system.
+
+         Ease of implementaion, sharing code, and modular programming
+         argue for the second approach.  Efficiency and independence
+
+
+
+Postel & Reynolds                                               [Page 9]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         argue for the first approach.  In practice, FTP relies on very
+         little of the Telnet Protocol, so the first approach does not
+         necessarily involve a large amount of code.
+
+3.  DATA TRANSFER FUNCTIONS
+
+   Files are transferred only via the data connection.  The control
+   connection is used for the transfer of commands, which describe the
+   functions to be performed, and the replies to these commands (see the
+   Section on FTP Replies).  Several commands are concerned with the
+   transfer of data between hosts.  These data transfer commands include
+   the MODE command which specify how the bits of the data are to be
+   transmitted, and the STRUcture and TYPE commands, which are used to
+   define the way in which the data are to be represented.  The
+   transmission and representation are basically independent but the
+   "Stream" transmission mode is dependent on the file structure
+   attribute and if "Compressed" transmission mode is used, the nature
+   of the filler byte depends on the representation type.
+
+   3.1.  DATA REPRESENTATION AND STORAGE
+
+      Data is transferred from a storage device in the sending host to a
+      storage device in the receiving host.  Often it is necessary to
+      perform certain transformations on the data because data storage
+      representations in the two systems are different.  For example,
+      NVT-ASCII has different data storage representations in different
+      systems.  DEC TOPS-20s's generally store NVT-ASCII as five 7-bit
+      ASCII characters, left-justified in a 36-bit word. IBM Mainframe's
+      store NVT-ASCII as 8-bit EBCDIC codes.  Multics stores NVT-ASCII
+      as four 9-bit characters in a 36-bit word.  It is desirable to
+      convert characters into the standard NVT-ASCII representation when
+      transmitting text between dissimilar systems.  The sending and
+      receiving sites would have to perform the necessary
+      transformations between the standard representation and their
+      internal representations.
+
+      A different problem in representation arises when transmitting
+      binary data (not character codes) between host systems with
+      different word lengths.  It is not always clear how the sender
+      should send data, and the receiver store it.  For example, when
+      transmitting 32-bit bytes from a 32-bit word-length system to a
+      36-bit word-length system, it may be desirable (for reasons of
+      efficiency and usefulness) to store the 32-bit bytes
+      right-justified in a 36-bit word in the latter system.  In any
+      case, the user should have the option of specifying data
+      representation and transformation functions.  It should be noted
+
+
+
+Postel & Reynolds                                              [Page 10]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      that FTP provides for very limited data type representations.
+      Transformations desired beyond this limited capability should be
+      performed by the user directly.
+
+      3.1.1.  DATA TYPES
+
+         Data representations are handled in FTP by a user specifying a
+         representation type.  This type may implicitly (as in ASCII or
+         EBCDIC) or explicitly (as in Local byte) define a byte size for
+         interpretation which is referred to as the "logical byte size."
+         Note that this has nothing to do with the byte size used for
+         transmission over the data connection, called the "transfer
+         byte size", and the two should not be confused.  For example,
+         NVT-ASCII has a logical byte size of 8 bits.  If the type is
+         Local byte, then the TYPE command has an obligatory second
+         parameter specifying the logical byte size.  The transfer byte
+         size is always 8 bits.
+
+         3.1.1.1.  ASCII TYPE
+
+            This is the default type and must be accepted by all FTP
+            implementations.  It is intended primarily for the transfer
+            of text files, except when both hosts would find the EBCDIC
+            type more convenient.
+
+            The sender converts the data from an internal character
+            representation to the standard 8-bit NVT-ASCII
+            representation (see the Telnet specification).  The receiver
+            will convert the data from the standard form to his own
+            internal form.
+
+            In accordance with the NVT standard, the <CRLF> sequence
+            should be used where necessary to denote the end of a line
+            of text.  (See the discussion of file structure at the end
+            of the Section on Data Representation and Storage.)
+
+            Using the standard NVT-ASCII representation means that data
+            must be interpreted as 8-bit bytes.
+
+            The Format parameter for ASCII and EBCDIC types is discussed
+            below.
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 11]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         3.1.1.2.  EBCDIC TYPE
+
+            This type is intended for efficient transfer between hosts
+            which use EBCDIC for their internal character
+            representation.
+
+            For transmission, the data are represented as 8-bit EBCDIC
+            characters.  The character code is the only difference
+            between the functional specifications of EBCDIC and ASCII
+            types.
+
+            End-of-line (as opposed to end-of-record--see the discussion
+            of structure) will probably be rarely used with EBCDIC type
+            for purposes of denoting structure, but where it is
+            necessary the <NL> character should be used.
+
+         3.1.1.3.  IMAGE TYPE
+
+            The data are sent as contiguous bits which, for transfer,
+            are packed into the 8-bit transfer bytes.  The receiving
+            site must store the data as contiguous bits.  The structure
+            of the storage system might necessitate the padding of the
+            file (or of each record, for a record-structured file) to
+            some convenient boundary (byte, word or block).  This
+            padding, which must be all zeros, may occur only at the end
+            of the file (or at the end of each record) and there must be
+            a way of identifying the padding bits so that they may be
+            stripped off if the file is retrieved.  The padding
+            transformation should be well publicized to enable a user to
+            process a file at the storage site.
+
+            Image type is intended for the efficient storage and
+            retrieval of files and for the transfer of binary data.  It
+            is recommended that this type be accepted by all FTP
+            implementations.
+
+         3.1.1.4.  LOCAL TYPE
+
+            The data is transferred in logical bytes of the size
+            specified by the obligatory second parameter, Byte size.
+            The value of Byte size must be a decimal integer; there is
+            no default value.  The logical byte size is not necessarily
+            the same as the transfer byte size.  If there is a
+            difference in byte sizes, then the logical bytes should be
+            packed contiguously, disregarding transfer byte boundaries
+            and with any necessary padding at the end.
+
+
+
+Postel & Reynolds                                              [Page 12]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            When the data reaches the receiving host, it will be
+            transformed in a manner dependent on the logical byte size
+            and the particular host.  This transformation must be
+            invertible (i.e., an identical file can be retrieved if the
+            same parameters are used) and should be well publicized by
+            the FTP implementors.
+
+            For example, a user sending 36-bit floating-point numbers to
+            a host with a 32-bit word could send that data as Local byte
+            with a logical byte size of 36.  The receiving host would
+            then be expected to store the logical bytes so that they
+            could be easily manipulated; in this example putting the
+            36-bit logical bytes into 64-bit double words should
+            suffice.
+
+            In another example, a pair of hosts with a 36-bit word size
+            may send data to one another in words by using TYPE L 36.
+            The data would be sent in the 8-bit transmission bytes
+            packed so that 9 transmission bytes carried two host words.
+
+         3.1.1.5.  FORMAT CONTROL
+
+            The types ASCII and EBCDIC also take a second (optional)
+            parameter; this is to indicate what kind of vertical format
+            control, if any, is associated with a file.  The following
+            data representation types are defined in FTP:
+
+            A character file may be transferred to a host for one of
+            three purposes: for printing, for storage and later
+            retrieval, or for processing.  If a file is sent for
+            printing, the receiving host must know how the vertical
+            format control is represented.  In the second case, it must
+            be possible to store a file at a host and then retrieve it
+            later in exactly the same form.  Finally, it should be
+            possible to move a file from one host to another and process
+            the file at the second host without undue trouble.  A single
+            ASCII or EBCDIC format does not satisfy all these
+            conditions.  Therefore, these types have a second parameter
+            specifying one of the following three formats:
+
+            3.1.1.5.1.  NON PRINT
+
+               This is the default format to be used if the second
+               (format) parameter is omitted.  Non-print format must be
+               accepted by all FTP implementations.
+
+
+
+
+Postel & Reynolds                                              [Page 13]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               The file need contain no vertical format information.  If
+               it is passed to a printer process, this process may
+               assume standard values for spacing and margins.
+
+               Normally, this format will be used with files destined
+               for processing or just storage.
+
+            3.1.1.5.2.  TELNET FORMAT CONTROLS
+
+               The file contains ASCII/EBCDIC vertical format controls
+               (i.e., <CR>, <LF>, <NL>, <VT>, <FF>) which the printer
+               process will interpret appropriately.  <CRLF>, in exactly
+               this sequence, also denotes end-of-line.
+
+            3.1.1.5.2.  CARRIAGE CONTROL (ASA)
+
+               The file contains ASA (FORTRAN) vertical format control
+               characters.  (See RFC 740 Appendix C; and Communications
+               of the ACM, Vol. 7, No. 10, p. 606, October 1964.)  In a
+               line or a record formatted according to the ASA Standard,
+               the first character is not to be printed.  Instead, it
+               should be used to determine the vertical movement of the
+               paper which should take place before the rest of the
+               record is printed.
+
+               The ASA Standard specifies the following control
+               characters:
+
+                  Character     Vertical Spacing
+
+                  blank         Move paper up one line
+                  0             Move paper up two lines
+                  1             Move paper to top of next page
+                  +             No movement, i.e., overprint
+
+               Clearly there must be some way for a printer process to
+               distinguish the end of the structural entity.  If a file
+               has record structure (see below) this is no problem;
+               records will be explicitly marked during transfer and
+               storage.  If the file has no record structure, the <CRLF>
+               end-of-line sequence is used to separate printing lines,
+               but these format effectors are overridden by the ASA
+               controls.
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 14]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      3.1.2.  DATA STRUCTURES
+
+         In addition to different representation types, FTP allows the
+         structure of a file to be specified.  Three file structures are
+         defined in FTP:
+
+            file-structure,     where there is no internal structure and
+                                the file is considered to be a
+                                continuous sequence of data bytes,
+
+            record-structure,   where the file is made up of sequential
+                                records,
+
+            and page-structure, where the file is made up of independent
+                                indexed pages.
+
+         File-structure is the default to be assumed if the STRUcture
+         command has not been used but both file and record structures
+         must be accepted for "text" files (i.e., files with TYPE ASCII
+         or EBCDIC) by all FTP implementations.  The structure of a file
+         will affect both the transfer mode of a file (see the Section
+         on Transmission Modes) and the interpretation and storage of
+         the file.
+
+         The "natural" structure of a file will depend on which host
+         stores the file.  A source-code file will usually be stored on
+         an IBM Mainframe in fixed length records but on a DEC TOPS-20
+         as a stream of characters partitioned into lines, for example
+         by <CRLF>.  If the transfer of files between such disparate
+         sites is to be useful, there must be some way for one site to
+         recognize the other's assumptions about the file.
+
+         With some sites being naturally file-oriented and others
+         naturally record-oriented there may be problems if a file with
+         one structure is sent to a host oriented to the other.  If a
+         text file is sent with record-structure to a host which is file
+         oriented, then that host should apply an internal
+         transformation to the file based on the record structure.
+         Obviously, this transformation should be useful, but it must
+         also be invertible so that an identical file may be retrieved
+         using record structure.
+
+         In the case of a file being sent with file-structure to a
+         record-oriented host, there exists the question of what
+         criteria the host should use to divide the file into records
+         which can be processed locally.  If this division is necessary,
+         the FTP implementation should use the end-of-line sequence,
+
+
+Postel & Reynolds                                              [Page 15]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         <CRLF> for ASCII, or <NL> for EBCDIC text files, as the
+         delimiter.  If an FTP implementation adopts this technique, it
+         must be prepared to reverse the transformation if the file is
+         retrieved with file-structure.
+
+         3.1.2.1.  FILE STRUCTURE
+
+            File structure is the default to be assumed if the STRUcture
+            command has not been used.
+
+            In file-structure there is no internal structure and the
+            file is considered to be a continuous sequence of data
+            bytes.
+
+         3.1.2.2.  RECORD STRUCTURE
+
+            Record structures must be accepted for "text" files (i.e.,
+            files with TYPE ASCII or EBCDIC) by all FTP implementations.
+
+            In record-structure the file is made up of sequential
+            records.
+
+         3.1.2.3.  PAGE STRUCTURE
+
+            To transmit files that are discontinuous, FTP defines a page
+            structure.  Files of this type are sometimes known as
+            "random access files" or even as "holey files".  In these
+            files there is sometimes other information associated with
+            the file as a whole (e.g., a file descriptor), or with a
+            section of the file (e.g., page access controls), or both.
+            In FTP, the sections of the file are called pages.
+
+            To provide for various page sizes and associated
+            information, each page is sent with a page header.  The page
+            header has the following defined fields:
+
+               Header Length
+
+                  The number of logical bytes in the page header
+                  including this byte.  The minimum header length is 4.
+
+               Page Index
+
+                  The logical page number of this section of the file.
+                  This is not the transmission sequence number of this
+                  page, but the index used to identify this page of the
+                  file.
+
+
+Postel & Reynolds                                              [Page 16]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               Data Length
+
+                  The number of logical bytes in the page data.  The
+                  minimum data length is 0.
+
+               Page Type
+
+                  The type of page this is.  The following page types
+                  are defined:
+
+                     0 = Last Page
+
+                        This is used to indicate the end of a paged
+                        structured transmission.  The header length must
+                        be 4, and the data length must be 0.
+
+                     1 = Simple Page
+
+                        This is the normal type for simple paged files
+                        with no page level associated control
+                        information.  The header length must be 4.
+
+                     2 = Descriptor Page
+
+                        This type is used to transmit the descriptive
+                        information for the file as a whole.
+
+                     3 = Access Controlled Page
+
+                        This type includes an additional header field
+                        for paged files with page level access control
+                        information.  The header length must be 5.
+
+               Optional Fields
+
+                  Further header fields may be used to supply per page
+                  control information, for example, per page access
+                  control.
+
+            All fields are one logical byte in length.  The logical byte
+            size is specified by the TYPE command.  See Appendix I for
+            further details and a specific case at the page structure.
+
+      A note of caution about parameters:  a file must be stored and
+      retrieved with the same parameters if the retrieved version is to
+
+
+
+
+Postel & Reynolds                                              [Page 17]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      be identical to the version originally transmitted.  Conversely,
+      FTP implementations must return a file identical to the original
+      if the parameters used to store and retrieve a file are the same.
+
+   3.2.  ESTABLISHING DATA CONNECTIONS
+
+      The mechanics of transferring data consists of setting up the data
+      connection to the appropriate ports and choosing the parameters
+      for transfer.  Both the user and the server-DTPs have a default
+      data port.  The user-process default data port is the same as the
+      control connection port (i.e., U).  The server-process default
+      data port is the port adjacent to the control connection port
+      (i.e., L-1).
+
+      The transfer byte size is 8-bit bytes.  This byte size is relevant
+      only for the actual transfer of the data; it has no bearing on
+      representation of the data within a host's file system.
+
+      The passive data transfer process (this may be a user-DTP or a
+      second server-DTP) shall "listen" on the data port prior to
+      sending a transfer request command.  The FTP request command
+      determines the direction of the data transfer.  The server, upon
+      receiving the transfer request, will initiate the data connection
+      to the port.  When the connection is established, the data
+      transfer begins between DTP's, and the server-PI sends a
+      confirming reply to the user-PI.
+
+      Every FTP implementation must support the use of the default data
+      ports, and only the USER-PI can initiate a change to non-default
+      ports.
+
+      It is possible for the user to specify an alternate data port by
+      use of the PORT command.  The user may want a file dumped on a TAC
+      line printer or retrieved from a third party host.  In the latter
+      case, the user-PI sets up control connections with both
+      server-PI's.  One server is then told (by an FTP command) to
+      "listen" for a connection which the other will initiate.  The
+      user-PI sends one server-PI a PORT command indicating the data
+      port of the other.  Finally, both are sent the appropriate
+      transfer commands.  The exact sequence of commands and replies
+      sent between the user-controller and the servers is defined in the
+      Section on FTP Replies.
+
+      In general, it is the server's responsibility to maintain the data
+      connection--to initiate it and to close it.  The exception to this
+
+
+
+
+Postel & Reynolds                                              [Page 18]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      is when the user-DTP is sending the data in a transfer mode that
+      requires the connection to be closed to indicate EOF.  The server
+      MUST close the data connection under the following conditions:
+
+         1. The server has completed sending data in a transfer mode
+            that requires a close to indicate EOF.
+
+         2. The server receives an ABORT command from the user.
+
+         3. The port specification is changed by a command from the
+            user.
+
+         4. The control connection is closed legally or otherwise.
+
+         5. An irrecoverable error condition occurs.
+
+      Otherwise the close is a server option, the exercise of which the
+      server must indicate to the user-process by either a 250 or 226
+      reply only.
+
+   3.3.  DATA CONNECTION MANAGEMENT
+
+      Default Data Connection Ports:  All FTP implementations must
+      support use of the default data connection ports, and only the
+      User-PI may initiate the use of non-default ports.
+
+      Negotiating Non-Default Data Ports:   The User-PI may specify a
+      non-default user side data port with the PORT command.  The
+      User-PI may request the server side to identify a non-default
+      server side data port with the PASV command.  Since a connection
+      is defined by the pair of addresses, either of these actions is
+      enough to get a different data connection, still it is permitted
+      to do both commands to use new ports on both ends of the data
+      connection.
+
+      Reuse of the Data Connection:  When using the stream mode of data
+      transfer the end of the file must be indicated by closing the
+      connection.  This causes a problem if multiple files are to be
+      transfered in the session, due to need for TCP to hold the
+      connection record for a time out period to guarantee the reliable
+      communication.  Thus the connection can not be reopened at once.
+
+         There are two solutions to this problem.  The first is to
+         negotiate a non-default port.  The second is to use another
+         transfer mode.
+
+         A comment on transfer modes.  The stream transfer mode is
+
+
+Postel & Reynolds                                              [Page 19]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         inherently unreliable, since one can not determine if the
+         connection closed prematurely or not.  The other transfer modes
+         (Block, Compressed) do not close the connection to indicate the
+         end of file.  They have enough FTP encoding that the data
+         connection can be parsed to determine the end of the file.
+         Thus using these modes one can leave the data connection open
+         for multiple file transfers.
+
+   3.4.  TRANSMISSION MODES
+
+      The next consideration in transferring data is choosing the
+      appropriate transmission mode.  There are three modes: one which
+      formats the data and allows for restart procedures; one which also
+      compresses the data for efficient transfer; and one which passes
+      the data with little or no processing.  In this last case the mode
+      interacts with the structure attribute to determine the type of
+      processing.  In the compressed mode, the representation type
+      determines the filler byte.
+
+      All data transfers must be completed with an end-of-file (EOF)
+      which may be explicitly stated or implied by the closing of the
+      data connection.  For files with record structure, all the
+      end-of-record markers (EOR) are explicit, including the final one.
+      For files transmitted in page structure a "last-page" page type is
+      used.
+
+      NOTE:  In the rest of this section, byte means "transfer byte"
+      except where explicitly stated otherwise.
+
+      For the purpose of standardized transfer, the sending host will
+      translate its internal end of line or end of record denotation
+      into the representation prescribed by the transfer mode and file
+      structure, and the receiving host will perform the inverse
+      translation to its internal denotation.  An IBM Mainframe record
+      count field may not be recognized at another host, so the
+      end-of-record information may be transferred as a two byte control
+      code in Stream mode or as a flagged bit in a Block or Compressed
+      mode descriptor.  End-of-line in an ASCII or EBCDIC file with no
+      record structure should be indicated by <CRLF> or <NL>,
+      respectively.  Since these transformations imply extra work for
+      some systems, identical systems transferring non-record structured
+      text files might wish to use a binary representation and stream
+      mode for the transfer.
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 20]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      The following transmission modes are defined in FTP:
+
+      3.4.1.  STREAM MODE
+
+         The data is transmitted as a stream of bytes.  There is no
+         restriction on the representation type used; record structures
+         are allowed.
+
+         In a record structured file EOR and EOF will each be indicated
+         by a two-byte control code.  The first byte of the control code
+         will be all ones, the escape character.  The second byte will
+         have the low order bit on and zeros elsewhere for EOR and the
+         second low order bit on for EOF; that is, the byte will have
+         value 1 for EOR and value 2 for EOF.  EOR and EOF may be
+         indicated together on the last byte transmitted by turning both
+         low order bits on (i.e., the value 3).  If a byte of all ones
+         was intended to be sent as data, it should be repeated in the
+         second byte of the control code.
+
+         If the structure is a file structure, the EOF is indicated by
+         the sending host closing the data connection and all bytes are
+         data bytes.
+
+      3.4.2.  BLOCK MODE
+
+         The file is transmitted as a series of data blocks preceded by
+         one or more header bytes.  The header bytes contain a count
+         field, and descriptor code.  The count field indicates the
+         total length of the data block in bytes, thus marking the
+         beginning of the next data block (there are no filler bits).
+         The descriptor code defines:  last block in the file (EOF) last
+         block in the record (EOR), restart marker (see the Section on
+         Error Recovery and Restart) or suspect data (i.e., the data
+         being transferred is suspected of errors and is not reliable).
+         This last code is NOT intended for error control within FTP.
+         It is motivated by the desire of sites exchanging certain types
+         of data (e.g., seismic or weather data) to send and receive all
+         the data despite local errors (such as "magnetic tape read
+         errors"), but to indicate in the transmission that certain
+         portions are suspect).  Record structures are allowed in this
+         mode, and any representation type may be used.
+
+         The header consists of the three bytes.  Of the 24 bits of
+         header information, the 16 low order bits shall represent byte
+         count, and the 8 high order bits shall represent descriptor
+         codes as shown below.
+
+
+
+Postel & Reynolds                                              [Page 21]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         Block Header
+
+            +----------------+----------------+----------------+
+            | Descriptor     |    Byte Count                   |
+            |         8 bits |                      16 bits    |
+            +----------------+----------------+----------------+
+            
+
+         The descriptor codes are indicated by bit flags in the
+         descriptor byte.  Four codes have been assigned, where each
+         code number is the decimal value of the corresponding bit in
+         the byte.
+
+            Code     Meaning
+            
+             128     End of data block is EOR
+              64     End of data block is EOF
+              32     Suspected errors in data block
+              16     Data block is a restart marker
+
+         With this encoding, more than one descriptor coded condition
+         may exist for a particular block.  As many bits as necessary
+         may be flagged.
+
+         The restart marker is embedded in the data stream as an
+         integral number of 8-bit bytes representing printable
+         characters in the language being used over the control
+         connection (e.g., default--NVT-ASCII).  <SP> (Space, in the
+         appropriate language) must not be used WITHIN a restart marker.
+
+         For example, to transmit a six-character marker, the following
+         would be sent:
+
+            +--------+--------+--------+
+            |Descrptr|  Byte count     |
+            |code= 16|             = 6 |
+            +--------+--------+--------+
+
+            +--------+--------+--------+
+            | Marker | Marker | Marker |
+            | 8 bits | 8 bits | 8 bits |
+            +--------+--------+--------+
+
+            +--------+--------+--------+
+            | Marker | Marker | Marker |
+            | 8 bits | 8 bits | 8 bits |
+            +--------+--------+--------+
+
+
+Postel & Reynolds                                              [Page 22]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      3.4.3.  COMPRESSED MODE
+
+         There are three kinds of information to be sent:  regular data,
+         sent in a byte string; compressed data, consisting of
+         replications or filler; and control information, sent in a
+         two-byte escape sequence.  If n>0 bytes (up to 127) of regular
+         data are sent, these n bytes are preceded by a byte with the
+         left-most bit set to 0 and the right-most 7 bits containing the
+         number n.
+
+         Byte string:
+
+             1       7                8                     8
+            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
+            |0|       n     | |    d(1)       | ... |      d(n)     |
+            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
+                                          ^             ^
+                                          |---n bytes---|
+                                              of data
+
+            String of n data bytes d(1),..., d(n)
+            Count n must be positive.
+
+         To compress a string of n replications of the data byte d, the
+         following 2 bytes are sent:
+
+         Replicated Byte:
+
+              2       6               8
+            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
+            |1 0|     n     | |       d       |
+            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
+
+         A string of n filler bytes can be compressed into a single
+         byte, where the filler byte varies with the representation
+         type.  If the type is ASCII or EBCDIC the filler byte is <SP>
+         (Space, ASCII code 32, EBCDIC code 64).  If the type is Image
+         or Local byte the filler is a zero byte.
+
+         Filler String:
+
+              2       6
+            +-+-+-+-+-+-+-+-+
+            |1 1|     n     |
+            +-+-+-+-+-+-+-+-+
+
+         The escape sequence is a double byte, the first of which is the
+
+
+Postel & Reynolds                                              [Page 23]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         escape byte (all zeros) and the second of which contains
+         descriptor codes as defined in Block mode.  The descriptor
+         codes have the same meaning as in Block mode and apply to the
+         succeeding string of bytes.
+
+         Compressed mode is useful for obtaining increased bandwidth on
+         very large network transmissions at a little extra CPU cost.
+         It can be most effectively used to reduce the size of printer
+         files such as those generated by RJE hosts.
+
+   3.5.  ERROR RECOVERY AND RESTART
+
+      There is no provision for detecting bits lost or scrambled in data
+      transfer; this level of error control is handled by the TCP.
+      However, a restart procedure is provided to protect users from
+      gross system failures (including failures of a host, an
+      FTP-process, or the underlying network).
+
+      The restart procedure is defined only for the block and compressed
+      modes of data transfer.  It requires the sender of data to insert
+      a special marker code in the data stream with some marker
+      information.  The marker information has meaning only to the
+      sender, but must consist of printable characters in the default or
+      negotiated language of the control connection (ASCII or EBCDIC).
+      The marker could represent a bit-count, a record-count, or any
+      other information by which a system may identify a data
+      checkpoint.  The receiver of data, if it implements the restart
+      procedure, would then mark the corresponding position of this
+      marker in the receiving system, and return this information to the
+      user.
+
+      In the event of a system failure, the user can restart the data
+      transfer by identifying the marker point with the FTP restart
+      procedure.  The following example illustrates the use of the
+      restart procedure.
+
+      The sender of the data inserts an appropriate marker block in the
+      data stream at a convenient point.  The receiving host marks the
+      corresponding data point in its file system and conveys the last
+      known sender and receiver marker information to the user, either
+      directly or over the control connection in a 110 reply (depending
+      on who is the sender).  In the event of a system failure, the user
+      or controller process restarts the server at the last server
+      marker by sending a restart command with server's marker code as
+      its argument.  The restart command is transmitted over the control
+
+
+
+
+Postel & Reynolds                                              [Page 24]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      connection and is immediately followed by the command (such as
+      RETR, STOR or LIST) which was being executed when the system
+      failure occurred.
+
+4.  FILE TRANSFER FUNCTIONS
+
+   The communication channel from the user-PI to the server-PI is
+   established as a TCP connection from the user to the standard server
+   port.  The user protocol interpreter is responsible for sending FTP
+   commands and interpreting the replies received; the server-PI
+   interprets commands, sends replies and directs its DTP to set up the
+   data connection and transfer the data.  If the second party to the
+   data transfer (the passive transfer process) is the user-DTP, then it
+   is governed through the internal protocol of the user-FTP host; if it
+   is a second server-DTP, then it is governed by its PI on command from
+   the user-PI.  The FTP replies are discussed in the next section.  In
+   the description of a few of the commands in this section, it is
+   helpful to be explicit about the possible replies.
+
+   4.1.  FTP COMMANDS
+
+      4.1.1.  ACCESS CONTROL COMMANDS
+
+         The following commands specify access control identifiers
+         (command codes are shown in parentheses).
+
+         USER NAME (USER)
+
+            The argument field is a Telnet string identifying the user.
+            The user identification is that which is required by the
+            server for access to its file system.  This command will
+            normally be the first command transmitted by the user after
+            the control connections are made (some servers may require
+            this).  Additional identification information in the form of
+            a password and/or an account command may also be required by
+            some servers.  Servers may allow a new USER command to be
+            entered at any point in order to change the access control
+            and/or accounting information.  This has the effect of
+            flushing any user, password, and account information already
+            supplied and beginning the login sequence again.  All
+            transfer parameters are unchanged and any file transfer in
+            progress is completed under the old access control
+            parameters.
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 25]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         PASSWORD (PASS)
+
+            The argument field is a Telnet string specifying the user's
+            password.  This command must be immediately preceded by the
+            user name command, and, for some sites, completes the user's
+            identification for access control.  Since password
+            information is quite sensitive, it is desirable in general
+            to "mask" it or suppress typeout.  It appears that the
+            server has no foolproof way to achieve this.  It is
+            therefore the responsibility of the user-FTP process to hide
+            the sensitive password information.
+
+         ACCOUNT (ACCT)
+
+            The argument field is a Telnet string identifying the user's
+            account.  The command is not necessarily related to the USER
+            command, as some sites may require an account for login and
+            others only for specific access, such as storing files.  In
+            the latter case the command may arrive at any time.
+
+            There are reply codes to differentiate these cases for the
+            automation: when account information is required for login,
+            the response to a successful PASSword command is reply code
+            332.  On the other hand, if account information is NOT
+            required for login, the reply to a successful PASSword
+            command is 230; and if the account information is needed for
+            a command issued later in the dialogue, the server should
+            return a 332 or 532 reply depending on whether it stores
+            (pending receipt of the ACCounT command) or discards the
+            command, respectively.
+
+         CHANGE WORKING DIRECTORY (CWD)
+
+            This command allows the user to work with a different
+            directory or dataset for file storage or retrieval without
+            altering his login or accounting information.  Transfer
+            parameters are similarly unchanged.  The argument is a
+            pathname specifying a directory or other system dependent
+            file group designator.
+
+         CHANGE TO PARENT DIRECTORY (CDUP)
+
+            This command is a special case of CWD, and is included to
+            simplify the implementation of programs for transferring
+            directory trees between operating systems having different
+
+
+
+
+Postel & Reynolds                                              [Page 26]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            syntaxes for naming the parent directory.  The reply codes
+            shall be identical to the reply codes of CWD.  See
+            Appendix II for further details.
+
+         STRUCTURE MOUNT (SMNT)
+
+            This command allows the user to mount a different file
+            system data structure without altering his login or
+            accounting information.  Transfer parameters are similarly
+            unchanged.  The argument is a pathname specifying a
+            directory or other system dependent file group designator.
+
+         REINITIALIZE (REIN)
+
+            This command terminates a USER, flushing all I/O and account
+            information, except to allow any transfer in progress to be
+            completed.  All parameters are reset to the default settings
+            and the control connection is left open.  This is identical
+            to the state in which a user finds himself immediately after
+            the control connection is opened.  A USER command may be
+            expected to follow.
+
+         LOGOUT (QUIT)
+
+            This command terminates a USER and if file transfer is not
+            in progress, the server closes the control connection.  If
+            file transfer is in progress, the connection will remain
+            open for result response and the server will then close it.
+            If the user-process is transferring files for several USERs
+            but does not wish to close and then reopen connections for
+            each, then the REIN command should be used instead of QUIT.
+
+            An unexpected close on the control connection will cause the
+            server to take the effective action of an abort (ABOR) and a
+            logout (QUIT).
+
+      4.1.2.  TRANSFER PARAMETER COMMANDS
+
+         All data transfer parameters have default values, and the
+         commands specifying data transfer parameters are required only
+         if the default parameter values are to be changed.  The default
+         value is the last specified value, or if no value has been
+         specified, the standard default value is as stated here.  This
+         implies that the server must "remember" the applicable default
+         values.  The commands may be in any order except that they must
+         precede the FTP service request.  The following commands
+         specify data transfer parameters:
+
+
+Postel & Reynolds                                              [Page 27]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         DATA PORT (PORT)
+
+            The argument is a HOST-PORT specification for the data port
+            to be used in data connection.  There are defaults for both
+            the user and server data ports, and under normal
+            circumstances this command and its reply are not needed.  If
+            this command is used, the argument is the concatenation of a
+            32-bit internet host address and a 16-bit TCP port address.
+            This address information is broken into 8-bit fields and the
+            value of each field is transmitted as a decimal number (in
+            character string representation).  The fields are separated
+            by commas.  A port command would be:
+
+               PORT h1,h2,h3,h4,p1,p2
+
+            where h1 is the high order 8 bits of the internet host
+            address.
+
+         PASSIVE (PASV)
+
+            This command requests the server-DTP to "listen" on a data
+            port (which is not its default data port) and to wait for a
+            connection rather than initiate one upon receipt of a
+            transfer command.  The response to this command includes the
+            host and port address this server is listening on.
+
+         REPRESENTATION TYPE (TYPE)
+
+            The argument specifies the representation type as described
+            in the Section on Data Representation and Storage.  Several
+            types take a second parameter.  The first parameter is
+            denoted by a single Telnet character, as is the second
+            Format parameter for ASCII and EBCDIC; the second parameter
+            for local byte is a decimal integer to indicate Bytesize.
+            The parameters are separated by a <SP> (Space, ASCII code
+            32).
+
+            The following codes are assigned for type:
+
+                         \    /
+               A - ASCII |    | N - Non-print
+                         |-><-| T - Telnet format effectors
+               E - EBCDIC|    | C - Carriage Control (ASA)
+                         /    \
+               I - Image
+               
+               L <byte size> - Local byte Byte size
+
+
+Postel & Reynolds                                              [Page 28]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            The default representation type is ASCII Non-print.  If the
+            Format parameter is changed, and later just the first
+            argument is changed, Format then returns to the Non-print
+            default.
+
+         FILE STRUCTURE (STRU)
+
+            The argument is a single Telnet character code specifying
+            file structure described in the Section on Data
+            Representation and Storage.
+
+            The following codes are assigned for structure:
+
+               F - File (no record structure)
+               R - Record structure
+               P - Page structure
+
+            The default structure is File.
+
+         TRANSFER MODE (MODE)
+
+            The argument is a single Telnet character code specifying
+            the data transfer modes described in the Section on
+            Transmission Modes.
+
+            The following codes are assigned for transfer modes:
+
+               S - Stream
+               B - Block
+               C - Compressed
+
+            The default transfer mode is Stream.
+
+      4.1.3.  FTP SERVICE COMMANDS
+
+         The FTP service commands define the file transfer or the file
+         system function requested by the user.  The argument of an FTP
+         service command will normally be a pathname.  The syntax of
+         pathnames must conform to server site conventions (with
+         standard defaults applicable), and the language conventions of
+         the control connection.  The suggested default handling is to
+         use the last specified device, directory or file name, or the
+         standard default defined for local users.  The commands may be
+         in any order except that a "rename from" command must be
+         followed by a "rename to" command and the restart command must
+         be followed by the interrupted service command (e.g., STOR or
+         RETR).  The data, when transferred in response to FTP service
+
+
+Postel & Reynolds                                              [Page 29]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         commands, shall always be sent over the data connection, except
+         for certain informative replies.  The following commands
+         specify FTP service requests:
+
+         RETRIEVE (RETR)
+
+            This command causes the server-DTP to transfer a copy of the
+            file, specified in the pathname, to the server- or user-DTP
+            at the other end of the data connection.  The status and
+            contents of the file at the server site shall be unaffected.
+
+         STORE (STOR)
+
+            This command causes the server-DTP to accept the data
+            transferred via the data connection and to store the data as
+            a file at the server site.  If the file specified in the
+            pathname exists at the server site, then its contents shall
+            be replaced by the data being transferred.  A new file is
+            created at the server site if the file specified in the
+            pathname does not already exist.
+
+         STORE UNIQUE (STOU)
+
+            This command behaves like STOR except that the resultant
+            file is to be created in the current directory under a name
+            unique to that directory.  The 250 Transfer Started response
+            must include the name generated.
+
+         APPEND (with create) (APPE)
+
+            This command causes the server-DTP to accept the data
+            transferred via the data connection and to store the data in
+            a file at the server site.  If the file specified in the
+            pathname exists at the server site, then the data shall be
+            appended to that file; otherwise the file specified in the
+            pathname shall be created at the server site.
+
+         ALLOCATE (ALLO)
+
+            This command may be required by some servers to reserve
+            sufficient storage to accommodate the new file to be
+            transferred.  The argument shall be a decimal integer
+            representing the number of bytes (using the logical byte
+            size) of storage to be reserved for the file.  For files
+            sent with record or page structure a maximum record or page
+            size (in logical bytes) might also be necessary; this is
+            indicated by a decimal integer in a second argument field of
+
+
+Postel & Reynolds                                              [Page 30]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            the command.  This second argument is optional, but when
+            present should be separated from the first by the three
+            Telnet characters <SP> R <SP>.  This command shall be
+            followed by a STORe or APPEnd command.  The ALLO command
+            should be treated as a NOOP (no operation) by those servers
+            which do not require that the maximum size of the file be
+            declared beforehand, and those servers interested in only
+            the maximum record or page size should accept a dummy value
+            in the first argument and ignore it.
+
+         RESTART (REST)
+
+            The argument field represents the server marker at which
+            file transfer is to be restarted.  This command does not
+            cause file transfer but skips over the file to the specified
+            data checkpoint.  This command shall be immediately followed
+            by the appropriate FTP service command which shall cause
+            file transfer to resume.
+
+         RENAME FROM (RNFR)
+
+            This command specifies the old pathname of the file which is
+            to be renamed.  This command must be immediately followed by
+            a "rename to" command specifying the new file pathname.
+
+         RENAME TO (RNTO)
+
+            This command specifies the new pathname of the file
+            specified in the immediately preceding "rename from"
+            command.  Together the two commands cause a file to be
+            renamed.
+
+         ABORT (ABOR)
+
+            This command tells the server to abort the previous FTP
+            service command and any associated transfer of data.  The
+            abort command may require "special action", as discussed in
+            the Section on FTP Commands, to force recognition by the
+            server.  No action is to be taken if the previous command
+            has been completed (including data transfer).  The control
+            connection is not to be closed by the server, but the data
+            connection must be closed.
+
+            There are two cases for the server upon receipt of this
+            command: (1) the FTP service command was already completed,
+            or (2) the FTP service command is still in progress.
+
+
+
+Postel & Reynolds                                              [Page 31]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               In the first case, the server closes the data connection
+               (if it is open) and responds with a 226 reply, indicating
+               that the abort command was successfully processed.
+
+               In the second case, the server aborts the FTP service in
+               progress and closes the data connection, returning a 426
+               reply to indicate that the service request terminated
+               abnormally.  The server then sends a 226 reply,
+               indicating that the abort command was successfully
+               processed.
+
+         DELETE (DELE)
+
+            This command causes the file specified in the pathname to be
+            deleted at the server site.  If an extra level of protection
+            is desired (such as the query, "Do you really wish to
+            delete?"), it should be provided by the user-FTP process.
+
+         REMOVE DIRECTORY (RMD)
+
+            This command causes the directory specified in the pathname
+            to be removed as a directory (if the pathname is absolute)
+            or as a subdirectory of the current working directory (if
+            the pathname is relative).  See Appendix II.
+
+         MAKE DIRECTORY (MKD)
+
+            This command causes the directory specified in the pathname
+            to be created as a directory (if the pathname is absolute)
+            or as a subdirectory of the current working directory (if
+            the pathname is relative).  See Appendix II.
+
+         PRINT WORKING DIRECTORY (PWD)
+
+            This command causes the name of the current working
+            directory to be returned in the reply.  See Appendix II.
+
+         LIST (LIST)
+
+            This command causes a list to be sent from the server to the
+            passive DTP.  If the pathname specifies a directory or other
+            group of files, the server should transfer a list of files
+            in the specified directory.  If the pathname specifies a
+            file then the server should send current information on the
+            file.  A null argument implies the user's current working or
+            default directory.  The data transfer is over the data
+            connection in type ASCII or type EBCDIC.  (The user must
+
+
+Postel & Reynolds                                              [Page 32]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            ensure that the TYPE is appropriately ASCII or EBCDIC).
+            Since the information on a file may vary widely from system
+            to system, this information may be hard to use automatically
+            in a program, but may be quite useful to a human user.
+
+         NAME LIST (NLST)
+
+            This command causes a directory listing to be sent from
+            server to user site.  The pathname should specify a
+            directory or other system-specific file group descriptor; a
+            null argument implies the current directory.  The server
+            will return a stream of names of files and no other
+            information.  The data will be transferred in ASCII or
+            EBCDIC type over the data connection as valid pathname
+            strings separated by <CRLF> or <NL>.  (Again the user must
+            ensure that the TYPE is correct.)  This command is intended
+            to return information that can be used by a program to
+            further process the files automatically.  For example, in
+            the implementation of a "multiple get" function.
+
+         SITE PARAMETERS (SITE)
+
+            This command is used by the server to provide services
+            specific to his system that are essential to file transfer
+            but not sufficiently universal to be included as commands in
+            the protocol.  The nature of these services and the
+            specification of their syntax can be stated in a reply to
+            the HELP SITE command.
+
+         SYSTEM (SYST)
+
+            This command is used to find out the type of operating
+            system at the server.  The reply shall have as its first
+            word one of the system names listed in the current version
+            of the Assigned Numbers document [4].
+
+         STATUS (STAT)
+
+            This command shall cause a status response to be sent over
+            the control connection in the form of a reply.  The command
+            may be sent during a file transfer (along with the Telnet IP
+            and Synch signals--see the Section on FTP Commands) in which
+            case the server will respond with the status of the
+            operation in progress, or it may be sent between file
+            transfers.  In the latter case, the command may have an
+            argument field.  If the argument is a pathname, the command
+            is analogous to the "list" command except that data shall be
+
+
+Postel & Reynolds                                              [Page 33]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            transferred over the control connection.  If a partial
+            pathname is given, the server may respond with a list of
+            file names or attributes associated with that specification.
+            If no argument is given, the server should return general
+            status information about the server FTP process.  This
+            should include current values of all transfer parameters and
+            the status of connections.
+
+         HELP (HELP)
+
+            This command shall cause the server to send helpful
+            information regarding its implementation status over the
+            control connection to the user.  The command may take an
+            argument (e.g., any command name) and return more specific
+            information as a response.  The reply is type 211 or 214.
+            It is suggested that HELP be allowed before entering a USER
+            command. The server may use this reply to specify
+            site-dependent parameters, e.g., in response to HELP SITE.
+
+         NOOP (NOOP)
+
+            This command does not affect any parameters or previously
+            entered commands. It specifies no action other than that the
+            server send an OK reply.
+
+   The File Transfer Protocol follows the specifications of the Telnet
+   protocol for all communications over the control connection.  Since
+   the language used for Telnet communication may be a negotiated
+   option, all references in the next two sections will be to the
+   "Telnet language" and the corresponding "Telnet end-of-line code".
+   Currently, one may take these to mean NVT-ASCII and <CRLF>.  No other
+   specifications of the Telnet protocol will be cited.
+
+   FTP commands are "Telnet strings" terminated by the "Telnet end of
+   line code".  The command codes themselves are alphabetic characters
+   terminated by the character <SP> (Space) if parameters follow and
+   Telnet-EOL otherwise.  The command codes and the semantics of
+   commands are described in this section; the detailed syntax of
+   commands is specified in the Section on Commands, the reply sequences
+   are discussed in the Section on Sequencing of Commands and Replies,
+   and scenarios illustrating the use of commands are provided in the
+   Section on Typical FTP Scenarios.
+
+   FTP commands may be partitioned as those specifying access-control
+   identifiers, data transfer parameters, or FTP service requests.
+   Certain commands (such as ABOR, STAT, QUIT) may be sent over the
+   control connection while a data transfer is in progress.  Some
+
+
+Postel & Reynolds                                              [Page 34]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   servers may not be able to monitor the control and data connections
+   simultaneously, in which case some special action will be necessary
+   to get the server's attention.  The following ordered format is
+   tentatively recommended:
+
+      1. User system inserts the Telnet "Interrupt Process" (IP) signal
+      in the Telnet stream.
+
+      2. User system sends the Telnet "Synch" signal.
+
+      3. User system inserts the command (e.g., ABOR) in the Telnet
+      stream.
+
+      4. Server PI, after receiving "IP", scans the Telnet stream for
+      EXACTLY ONE FTP command.
+
+   (For other servers this may not be necessary but the actions listed
+   above should have no unusual effect.)
+
+   4.2.  FTP REPLIES
+
+      Replies to File Transfer Protocol commands are devised to ensure
+      the synchronization of requests and actions in the process of file
+      transfer, and to guarantee that the user process always knows the
+      state of the Server.  Every command must generate at least one
+      reply, although there may be more than one; in the latter case,
+      the multiple replies must be easily distinguished.  In addition,
+      some commands occur in sequential groups, such as USER, PASS and
+      ACCT, or RNFR and RNTO.  The replies show the existence of an
+      intermediate state if all preceding commands have been successful.
+      A failure at any point in the sequence necessitates the repetition
+      of the entire sequence from the beginning.
+
+         The details of the command-reply sequence are made explicit in
+         a set of state diagrams below.
+
+      An FTP reply consists of a three digit number (transmitted as
+      three alphanumeric characters) followed by some text.  The number
+      is intended for use by automata to determine what state to enter
+      next; the text is intended for the human user.  It is intended
+      that the three digits contain enough encoded information that the
+      user-process (the User-PI) will not need to examine the text and
+      may either discard it or pass it on to the user, as appropriate.
+      In particular, the text may be server-dependent, so there are
+      likely to be varying texts for each reply code.
+
+      A reply is defined to contain the 3-digit code, followed by Space
+
+
+Postel & Reynolds                                              [Page 35]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      <SP>, followed by one line of text (where some maximum line length
+      has been specified), and terminated by the Telnet end-of-line
+      code.  There will be cases however, where the text is longer than
+      a single line.  In these cases the complete text must be bracketed
+      so the User-process knows when it may stop reading the reply (i.e.
+      stop processing input on the control connection) and go do other
+      things.  This requires a special format on the first line to
+      indicate that more than one line is coming, and another on the
+      last line to designate it as the last.  At least one of these must
+      contain the appropriate reply code to indicate the state of the
+      transaction.  To satisfy all factions, it was decided that both
+      the first and last line codes should be the same.
+
+         Thus the format for multi-line replies is that the first line
+         will begin with the exact required reply code, followed
+         immediately by a Hyphen, "-" (also known as Minus), followed by
+         text.  The last line will begin with the same code, followed
+         immediately by Space <SP>, optionally some text, and the Telnet
+         end-of-line code.
+
+            For example:
+                                123-First line
+                                Second line
+                                  234 A line beginning with numbers
+                                123 The last line
+
+         The user-process then simply needs to search for the second
+         occurrence of the same reply code, followed by <SP> (Space), at
+         the beginning of a line, and ignore all intermediary lines.  If
+         an intermediary line begins with a 3-digit number, the Server
+         must pad the front  to avoid confusion.
+
+            This scheme allows standard system routines to be used for
+            reply information (such as for the STAT reply), with
+            "artificial" first and last lines tacked on.  In rare cases
+            where these routines are able to generate three digits and a
+            Space at the beginning of any line, the beginning of each
+            text line should be offset by some neutral text, like Space.
+
+         This scheme assumes that multi-line replies may not be nested.
+
+      The three digits of the reply each have a special significance.
+      This is intended to allow a range of very simple to very
+      sophisticated responses by the user-process.  The first digit
+      denotes whether the response is good, bad or incomplete.
+      (Referring to the state diagram), an unsophisticated user-process
+      will be able to determine its next action (proceed as planned,
+
+
+Postel & Reynolds                                              [Page 36]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      redo, retrench, etc.) by simply examining this first digit.  A
+      user-process that wants to know approximately what kind of error
+      occurred (e.g. file system error, command syntax error) may
+      examine the second digit, reserving the third digit for the finest
+      gradation of information (e.g., RNTO command without a preceding
+      RNFR).
+
+         There are five values for the first digit of the reply code:
+
+            1yz   Positive Preliminary reply
+
+               The requested action is being initiated; expect another
+               reply before proceeding with a new command.  (The
+               user-process sending another command before the
+               completion reply would be in violation of protocol; but
+               server-FTP processes should queue any commands that
+               arrive while a preceding command is in progress.)  This
+               type of reply can be used to indicate that the command
+               was accepted and the user-process may now pay attention
+               to the data connections, for implementations where
+               simultaneous monitoring is difficult.  The server-FTP
+               process may send at most, one 1yz reply per command.
+
+            2yz   Positive Completion reply
+
+               The requested action has been successfully completed.  A
+               new request may be initiated.
+
+            3yz   Positive Intermediate reply
+
+               The command has been accepted, but the requested action
+               is being held in abeyance, pending receipt of further
+               information.  The user should send another command
+               specifying this information.  This reply is used in
+               command sequence groups.
+
+            4yz   Transient Negative Completion reply
+
+               The command was not accepted and the requested action did
+               not take place, but the error condition is temporary and
+               the action may be requested again.  The user should
+               return to the beginning of the command sequence, if any.
+               It is difficult to assign a meaning to "transient",
+               particularly when two distinct sites (Server- and
+               User-processes) have to agree on the interpretation.
+               Each reply in the 4yz category might have a slightly
+               different time value, but the intent is that the
+
+
+Postel & Reynolds                                              [Page 37]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               user-process is encouraged to try again.  A rule of thumb
+               in determining if a reply fits into the 4yz or the 5yz
+               (Permanent Negative) category is that replies are 4yz if
+               the commands can be repeated without any change in
+               command form or in properties of the User or Server
+               (e.g., the command is spelled the same with the same
+               arguments used; the user does not change his file access
+               or user name; the server does not put up a new
+               implementation.)
+
+            5yz   Permanent Negative Completion reply
+
+               The command was not accepted and the requested action did
+               not take place.  The User-process is discouraged from
+               repeating the exact request (in the same sequence).  Even
+               some "permanent" error conditions can be corrected, so
+               the human user may want to direct his User-process to
+               reinitiate the command sequence by direct action at some
+               point in the future (e.g., after the spelling has been
+               changed, or the user has altered his directory status.)
+
+         The following function groupings are encoded in the second
+         digit:
+
+            x0z   Syntax - These replies refer to syntax errors,
+                  syntactically correct commands that don't fit any
+                  functional category, unimplemented or superfluous
+                  commands.
+
+            x1z   Information -  These are replies to requests for
+                  information, such as status or help.
+
+            x2z   Connections - Replies referring to the control and
+                  data connections.
+
+            x3z   Authentication and accounting - Replies for the login
+                  process and accounting procedures.
+
+            x4z   Unspecified as yet.
+
+            x5z   File system - These replies indicate the status of the
+                  Server file system vis-a-vis the requested transfer or
+                  other file system action.
+
+         The third digit gives a finer gradation of meaning in each of
+         the function categories, specified by the second digit.  The
+         list of replies below will illustrate this.  Note that the text
+
+
+Postel & Reynolds                                              [Page 38]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         associated with each reply is recommended, rather than
+         mandatory, and may even change according to the command with
+         which it is associated.  The reply codes, on the other hand,
+         must strictly follow the specifications in the last section;
+         that is, Server implementations should not invent new codes for
+         situations that are only slightly different from the ones
+         described here, but rather should adapt codes already defined.
+
+            A command such as TYPE or ALLO whose successful execution
+            does not offer the user-process any new information will
+            cause a 200 reply to be returned.  If the command is not
+            implemented by a particular Server-FTP process because it
+            has no relevance to that computer system, for example ALLO
+            at a TOPS20 site, a Positive Completion reply is still
+            desired so that the simple User-process knows it can proceed
+            with its course of action.  A 202 reply is used in this case
+            with, for example, the reply text:  "No storage allocation
+            necessary."  If, on the other hand, the command requests a
+            non-site-specific action and is unimplemented, the response
+            is 502.  A refinement of that is the 504 reply for a command
+            that is implemented, but that requests an unimplemented
+            parameter.
+
+      4.2.1  Reply Codes by Function Groups
+
+         200 Command okay.
+         500 Syntax error, command unrecognized.
+             This may include errors such as command line too long.
+         501 Syntax error in parameters or arguments.
+         202 Command not implemented, superfluous at this site.
+         502 Command not implemented.
+         503 Bad sequence of commands.
+         504 Command not implemented for that parameter.
+          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 39]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         110 Restart marker reply.
+             In this case, the text is exact and not left to the
+             particular implementation; it must read:
+                  MARK yyyy = mmmm
+             Where yyyy is User-process data stream marker, and mmmm
+             server's equivalent marker (note the spaces between markers
+             and "=").
+         211 System status, or system help reply.
+         212 Directory status.
+         213 File status.
+         214 Help message.
+             On how to use the server or the meaning of a particular
+             non-standard command.  This reply is useful only to the
+             human user.
+         215 NAME system type.
+             Where NAME is an official system name from the list in the
+             Assigned Numbers document.
+          
+         120 Service ready in nnn minutes.
+         220 Service ready for new user.
+         221 Service closing control connection.
+             Logged out if appropriate.
+         421 Service not available, closing control connection.
+             This may be a reply to any command if the service knows it
+             must shut down.
+         125 Data connection already open; transfer starting.
+         225 Data connection open; no transfer in progress.
+         425 Can't open data connection.
+         226 Closing data connection.
+             Requested file action successful (for example, file
+             transfer or file abort).
+         426 Connection closed; transfer aborted.
+         227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
+          
+         230 User logged in, proceed.
+         530 Not logged in.
+         331 User name okay, need password.
+         332 Need account for login.
+         532 Need account for storing files.
+          
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 40]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         150 File status okay; about to open data connection.
+         250 Requested file action okay, completed.
+         257 "PATHNAME" created.
+         350 Requested file action pending further information.
+         450 Requested file action not taken.
+             File unavailable (e.g., file busy).
+         550 Requested action not taken.
+             File unavailable (e.g., file not found, no access).
+         451 Requested action aborted. Local error in processing.
+         551 Requested action aborted. Page type unknown.
+         452 Requested action not taken.
+             Insufficient storage space in system.
+         552 Requested file action aborted.
+             Exceeded storage allocation (for current directory or
+             dataset).
+         553 Requested action not taken.
+             File name not allowed.
+         
+
+      4.2.2 Numeric  Order List of Reply Codes
+
+         110 Restart marker reply.
+             In this case, the text is exact and not left to the
+             particular implementation; it must read:
+                  MARK yyyy = mmmm
+             Where yyyy is User-process data stream marker, and mmmm
+             server's equivalent marker (note the spaces between markers
+             and "=").
+         120 Service ready in nnn minutes.
+         125 Data connection already open; transfer starting.
+         150 File status okay; about to open data connection.
+          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 41]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         200 Command okay.
+         202 Command not implemented, superfluous at this site.
+         211 System status, or system help reply.
+         212 Directory status.
+         213 File status.
+         214 Help message.
+             On how to use the server or the meaning of a particular
+             non-standard command.  This reply is useful only to the
+             human user.
+         215 NAME system type.
+             Where NAME is an official system name from the list in the
+             Assigned Numbers document.
+         220 Service ready for new user.
+         221 Service closing control connection.
+             Logged out if appropriate.
+         225 Data connection open; no transfer in progress.
+         226 Closing data connection.
+             Requested file action successful (for example, file
+             transfer or file abort).
+         227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
+         230 User logged in, proceed.
+         250 Requested file action okay, completed.
+         257 "PATHNAME" created.
+          
+         331 User name okay, need password.
+         332 Need account for login.
+         350 Requested file action pending further information.
+          
+         421 Service not available, closing control connection.
+             This may be a reply to any command if the service knows it
+             must shut down.
+         425 Can't open data connection.
+         426 Connection closed; transfer aborted.
+         450 Requested file action not taken.
+             File unavailable (e.g., file busy).
+         451 Requested action aborted: local error in processing.
+         452 Requested action not taken.
+             Insufficient storage space in system.
+          
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 42]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         500 Syntax error, command unrecognized.
+             This may include errors such as command line too long.
+         501 Syntax error in parameters or arguments.
+         502 Command not implemented.
+         503 Bad sequence of commands.
+         504 Command not implemented for that parameter.
+         530 Not logged in.
+         532 Need account for storing files.
+         550 Requested action not taken.
+             File unavailable (e.g., file not found, no access).
+         551 Requested action aborted: page type unknown.
+         552 Requested file action aborted.
+             Exceeded storage allocation (for current directory or
+             dataset).
+         553 Requested action not taken.
+             File name not allowed.
+         
+
+5.  DECLARATIVE SPECIFICATIONS
+
+   5.1.  MINIMUM IMPLEMENTATION
+
+      In order to make FTP workable without needless error messages, the
+      following minimum implementation is required for all servers:
+
+         TYPE - ASCII Non-print
+         MODE - Stream
+         STRUCTURE - File, Record
+         COMMANDS - USER, QUIT, PORT,
+                    TYPE, MODE, STRU,
+                      for the default values
+                    RETR, STOR,
+                    NOOP.
+
+      The default values for transfer parameters are:
+
+         TYPE - ASCII Non-print
+         MODE - Stream
+         STRU - File
+
+      All hosts must accept the above as the standard defaults.
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 43]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   5.2.  CONNECTIONS
+
+      The server protocol interpreter shall "listen" on Port L.  The
+      user or user protocol interpreter shall initiate the full-duplex
+      control connection.  Server- and user- processes should follow the
+      conventions of the Telnet protocol as specified in the
+      ARPA-Internet Protocol Handbook [1].  Servers are under no
+      obligation to provide for editing of command lines and may require
+      that it be done in the user host.  The control connection shall be
+      closed by the server at the user's request after all transfers and
+      replies are completed.
+
+      The user-DTP must "listen" on the specified data port; this may be
+      the default user port (U) or a port specified in the PORT command.
+      The server shall initiate the data connection from his own default
+      data port (L-1) using the specified user data port.  The direction
+      of the transfer and the port used will be determined by the FTP
+      service command.
+
+      Note that all FTP implementation must support data transfer using
+      the default port, and that only the USER-PI may initiate the use
+      of non-default ports.
+
+      When data is to be transferred between two servers, A and B (refer
+      to Figure 2), the user-PI, C, sets up control connections with
+      both server-PI's.  One of the servers, say A, is then sent a PASV
+      command telling him to "listen" on his data port rather than
+      initiate a connection when he receives a transfer service command.
+      When the user-PI receives an acknowledgment to the PASV command,
+      which includes the identity of the host and port being listened
+      on, the user-PI then sends A's port, a, to B in a PORT command; a
+      reply is returned.  The user-PI may then send the corresponding
+      service commands to A and B.  Server B initiates the connection
+      and the transfer proceeds.  The command-reply sequence is listed
+      below where the messages are vertically synchronous but
+      horizontally asynchronous:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 44]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         User-PI - Server A                User-PI - Server B
+         ------------------                ------------------
+         
+         C->A : Connect                    C->B : Connect
+         C->A : PASV
+         A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
+                                           C->B : PORT A1,A2,A3,A4,a1,a2
+                                           B->C : 200 Okay
+         C->A : STOR                       C->B : RETR
+                    B->A : Connect to HOST-A, PORT-a
+
+                                Figure 3
+
+      The data connection shall be closed by the server under the
+      conditions described in the Section on Establishing Data
+      Connections.  If the data connection is to be closed following a
+      data transfer where closing the connection is not required to
+      indicate the end-of-file, the server must do so immediately.
+      Waiting until after a new transfer command is not permitted
+      because the user-process will have already tested the data
+      connection to see if it needs to do a "listen"; (remember that the
+      user must "listen" on a closed data port BEFORE sending the
+      transfer request).  To prevent a race condition here, the server
+      sends a reply (226) after closing the data connection (or if the
+      connection is left open, a "file transfer completed" reply (250)
+      and the user-PI should wait for one of these replies before
+      issuing a new transfer command).
+
+      Any time either the user or server see that the connection is
+      being closed by the other side, it should promptly read any
+      remaining data queued on the connection and issue the close on its
+      own side.
+
+   5.3.  COMMANDS
+
+      The commands are Telnet character strings transmitted over the
+      control connections as described in the Section on FTP Commands.
+      The command functions and semantics are described in the Section
+      on Access Control Commands, Transfer Parameter Commands, FTP
+      Service Commands, and Miscellaneous Commands.  The command syntax
+      is specified here.
+
+      The commands begin with a command code followed by an argument
+      field.  The command codes are four or fewer alphabetic characters.
+      Upper and lower case alphabetic characters are to be treated
+      identically.  Thus, any of the following may represent the
+      retrieve command:
+
+
+Postel & Reynolds                                              [Page 45]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+                  RETR    Retr    retr    ReTr    rETr
+
+      This also applies to any symbols representing parameter values,
+      such as A or a for ASCII TYPE.  The command codes and the argument
+      fields are separated by one or more spaces.
+
+      The argument field consists of a variable length character string
+      ending with the character sequence <CRLF> (Carriage Return, Line
+      Feed) for NVT-ASCII representation; for other negotiated languages
+      a different end of line character might be used.  It should be
+      noted that the server is to take no action until the end of line
+      code is received.
+
+      The syntax is specified below in NVT-ASCII.  All characters in the
+      argument field are ASCII characters including any ASCII
+      represented decimal integers.  Square brackets denote an optional
+      argument field.  If the option is not taken, the appropriate
+      default is implied.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 46]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      5.3.1.  FTP COMMANDS
+
+         The following are the FTP commands:
+
+            USER <SP> <username> <CRLF>
+            PASS <SP> <password> <CRLF>
+            ACCT <SP> <account-information> <CRLF>
+            CWD  <SP> <pathname> <CRLF>
+            CDUP <CRLF>
+            SMNT <SP> <pathname> <CRLF>
+            QUIT <CRLF>
+            REIN <CRLF>
+            PORT <SP> <host-port> <CRLF>
+            PASV <CRLF>
+            TYPE <SP> <type-code> <CRLF>
+            STRU <SP> <structure-code> <CRLF>
+            MODE <SP> <mode-code> <CRLF>
+            RETR <SP> <pathname> <CRLF>
+            STOR <SP> <pathname> <CRLF>
+            STOU <CRLF>
+            APPE <SP> <pathname> <CRLF>
+            ALLO <SP> <decimal-integer>
+                [<SP> R <SP> <decimal-integer>] <CRLF>
+            REST <SP> <marker> <CRLF>
+            RNFR <SP> <pathname> <CRLF>
+            RNTO <SP> <pathname> <CRLF>
+            ABOR <CRLF>
+            DELE <SP> <pathname> <CRLF>
+            RMD  <SP> <pathname> <CRLF>
+            MKD  <SP> <pathname> <CRLF>
+            PWD  <CRLF>
+            LIST [<SP> <pathname>] <CRLF>
+            NLST [<SP> <pathname>] <CRLF>
+            SITE <SP> <string> <CRLF>
+            SYST <CRLF>
+            STAT [<SP> <pathname>] <CRLF>
+            HELP [<SP> <string>] <CRLF>
+            NOOP <CRLF>
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 47]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      5.3.2.  FTP COMMAND ARGUMENTS
+
+         The syntax of the above argument fields (using BNF notation
+         where applicable) is:
+
+            <username> ::= <string>
+            <password> ::= <string>
+            <account-information> ::= <string>
+            <string> ::= <char> | <char><string>
+            <char> ::= any of the 128 ASCII characters except <CR> and
+            <LF>
+            <marker> ::= <pr-string>
+            <pr-string> ::= <pr-char> | <pr-char><pr-string>
+            <pr-char> ::= printable characters, any
+                          ASCII code 33 through 126
+            <byte-size> ::= <number>
+            <host-port> ::= <host-number>,<port-number>
+            <host-number> ::= <number>,<number>,<number>,<number>
+            <port-number> ::= <number>,<number>
+            <number> ::= any decimal integer 1 through 255
+            <form-code> ::= N | T | C
+            <type-code> ::= A [<sp> <form-code>]
+                          | E [<sp> <form-code>]
+                          | I
+                          | L <sp> <byte-size>
+            <structure-code> ::= F | R | P
+            <mode-code> ::= S | B | C
+            <pathname> ::= <string>
+            <decimal-integer> ::= any decimal integer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 48]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   5.4.  SEQUENCING OF COMMANDS AND REPLIES
+
+      The communication between the user and server is intended to be an
+      alternating dialogue.  As such, the user issues an FTP command and
+      the server responds with a prompt primary reply.  The user should
+      wait for this initial primary success or failure response before
+      sending further commands.
+
+      Certain commands require a second reply for which the user should
+      also wait.  These replies may, for example, report on the progress
+      or completion of file transfer or the closing of the data
+      connection.  They are secondary replies to file transfer commands.
+
+      One important group of informational replies is the connection
+      greetings.  Under normal circumstances, a server will send a 220
+      reply, "awaiting input", when the connection is completed.  The
+      user should wait for this greeting message before sending any
+      commands.  If the server is unable to accept input right away, a
+      120 "expected delay" reply should be sent immediately and a 220
+      reply when ready.  The user will then know not to hang up if there
+      is a delay.
+
+      Spontaneous Replies
+
+         Sometimes "the system" spontaneously has a message to be sent
+         to a user (usually all users).  For example, "System going down
+         in 15 minutes".  There is no provision in FTP for such
+         spontaneous information to be sent from the server to the user.
+         It is recommended that such information be queued in the
+         server-PI and delivered to the user-PI in the next reply
+         (possibly making it a multi-line reply).
+
+      The table below lists alternative success and failure replies for
+      each command.  These must be strictly adhered to; a server may
+      substitute text in the replies, but the meaning and action implied
+      by the code numbers and by the specific command reply sequence
+      cannot be altered.
+
+      Command-Reply Sequences
+
+         In this section, the command-reply sequence is presented.  Each
+         command is listed with its possible replies; command groups are
+         listed together.  Preliminary replies are listed first (with
+         their succeeding replies indented and under them), then
+         positive and negative completion, and finally intermediary
+
+
+
+
+Postel & Reynolds                                              [Page 49]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         replies with the remaining commands from the sequence
+         following.  This listing forms the basis for the state
+         diagrams, which will be presented separately.
+
+            Connection Establishment
+               120
+                  220
+               220
+               421
+            Login
+               USER
+                  230
+                  530
+                  500, 501, 421
+                  331, 332
+               PASS
+                  230
+                  202
+                  530
+                  500, 501, 503, 421
+                  332
+               ACCT
+                  230
+                  202
+                  530
+                  500, 501, 503, 421
+               CWD
+                  250
+                  500, 501, 502, 421, 530, 550
+               CDUP
+                  200
+                  500, 501, 502, 421, 530, 550
+               SMNT
+                  202, 250
+                  500, 501, 502, 421, 530, 550
+            Logout
+               REIN
+                  120
+                     220
+                  220
+                  421
+                  500, 502
+               QUIT
+                  221
+                  500
+
+
+
+
+Postel & Reynolds                                              [Page 50]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            Transfer parameters
+               PORT
+                  200
+                  500, 501, 421, 530
+               PASV
+                  227
+                  500, 501, 502, 421, 530
+               MODE
+                  200
+                  500, 501, 504, 421, 530
+               TYPE
+                  200
+                  500, 501, 504, 421, 530
+               STRU
+                  200
+                  500, 501, 504, 421, 530
+            File action commands
+               ALLO
+                  200
+                  202
+                  500, 501, 504, 421, 530
+               REST
+                  500, 501, 502, 421, 530
+                  350
+               STOR
+                  125, 150
+                     (110)
+                     226, 250
+                     425, 426, 451, 551, 552
+                  532, 450, 452, 553
+                  500, 501, 421, 530
+               STOU
+                  125, 150
+                     (110)
+                     226, 250
+                     425, 426, 451, 551, 552
+                  532, 450, 452, 553
+                  500, 501, 421, 530
+               RETR
+                  125, 150
+                     (110)
+                     226, 250
+                     425, 426, 451
+                  450, 550
+                  500, 501, 421, 530
+
+
+
+
+Postel & Reynolds                                              [Page 51]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               LIST
+                  125, 150
+                     226, 250
+                     425, 426, 451
+                  450
+                  500, 501, 502, 421, 530
+               NLST
+                  125, 150
+                     226, 250
+                     425, 426, 451
+                  450
+                  500, 501, 502, 421, 530
+               APPE
+                  125, 150
+                     (110)
+                     226, 250
+                     425, 426, 451, 551, 552
+                  532, 450, 550, 452, 553
+                  500, 501, 502, 421, 530
+               RNFR
+                  450, 550
+                  500, 501, 502, 421, 530
+                  350
+               RNTO
+                  250
+                  532, 553
+                  500, 501, 502, 503, 421, 530
+               DELE
+                  250
+                  450, 550
+                  500, 501, 502, 421, 530
+               RMD
+                  250
+                  500, 501, 502, 421, 530, 550
+               MKD
+                  257
+                  500, 501, 502, 421, 530, 550
+               PWD
+                  257
+                  500, 501, 502, 421, 550
+               ABOR
+                  225, 226
+                  500, 501, 502, 421
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 52]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            Informational commands
+               SYST
+                  215
+                  500, 501, 502, 421
+               STAT
+                  211, 212, 213
+                  450
+                  500, 501, 502, 421, 530
+               HELP
+                  211, 214
+                  500, 501, 502, 421
+            Miscellaneous commands
+               SITE
+                  200
+                  202
+                  500, 501, 530
+               NOOP
+                  200
+                  500 421
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 53]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+6.  STATE DIAGRAMS
+
+   Here we present state diagrams for a very simple minded FTP
+   implementation.  Only the first digit of the reply codes is used.
+   There is one state diagram for each group of FTP commands or command
+   sequences.
+
+   The command groupings were determined by constructing a model for
+   each command then collecting together the commands with structurally
+   identical models.
+
+   For each command or command sequence there are three possible
+   outcomes: success (S), failure (F), and error (E).  In the state
+   diagrams below we use the symbol B for "begin", and the symbol W for
+   "wait for reply".
+
+   We first present the diagram that represents the largest group of FTP
+   commands:
+
+      
+                               1,3    +---+
+                          ----------->| E |
+                         |            +---+
+                         |
+      +---+    cmd    +---+    2      +---+
+      | B |---------->| W |---------->| S |
+      +---+           +---+           +---+
+                         |
+                         |     4,5    +---+
+                          ----------->| F |
+                                      +---+
+      
+
+      This diagram models the commands:
+
+         ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
+         QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE.
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 54]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   The other large group of commands is represented by a very similar
+   diagram:
+
+      
+                               3      +---+
+                          ----------->| E |
+                         |            +---+
+                         |
+      +---+    cmd    +---+    2      +---+
+      | B |---------->| W |---------->| S |
+      +---+       --->+---+           +---+
+                 |     | |
+                 |     | |     4,5    +---+
+                 |  1  |  ----------->| F |
+                  -----               +---+
+      
+
+      This diagram models the commands:
+
+         APPE, LIST, NLST, REIN, RETR, STOR, and STOU.
+
+   Note that this second model could also be used to represent the first
+   group of commands, the only difference being that in the first group
+   the 100 series replies are unexpected and therefore treated as error,
+   while the second group expects (some may require) 100 series replies.
+   Remember that at most, one 100 series reply is allowed per command.
+
+   The remaining diagrams model command sequences, perhaps the simplest
+   of these is the rename sequence:
+
+      
+      +---+   RNFR    +---+    1,2    +---+
+      | B |---------->| W |---------->| E |
+      +---+           +---+        -->+---+
+                       | |        |
+                3      | | 4,5    |
+         --------------  ------   |
+        |                      |  |   +---+
+        |               ------------->| S |
+        |              |   1,3 |  |   +---+
+        |             2|  --------
+        |              | |     |
+        V              | |     |
+      +---+   RNTO    +---+ 4,5 ----->+---+
+      |   |---------->| W |---------->| F |
+      +---+           +---+           +---+
+      
+
+
+Postel & Reynolds                                              [Page 55]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   The next diagram is a simple model of the Restart command:
+
+      
+      +---+   REST    +---+    1,2    +---+
+      | B |---------->| W |---------->| E |
+      +---+           +---+        -->+---+
+                       | |        |
+                3      | | 4,5    |
+         --------------  ------   |
+        |                      |  |   +---+
+        |               ------------->| S |
+        |              |   3   |  |   +---+
+        |             2|  --------
+        |              | |     |
+        V              | |     |
+      +---+   cmd     +---+ 4,5 ----->+---+
+      |   |---------->| W |---------->| F |
+      +---+        -->+---+           +---+
+                  |      |
+                  |  1   |
+                   ------
+      
+
+         Where "cmd" is APPE, STOR, or RETR.
+
+   We note that the above three models are similar.  The Restart differs
+   from the Rename two only in the treatment of 100 series replies at
+   the second stage, while the second group expects (some may require)
+   100 series replies.  Remember that at most, one 100 series reply is
+   allowed per command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 56]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   The most complicated diagram is for the Login sequence:
+
+      
+                            1
+      +---+   USER    +---+------------->+---+
+      | B |---------->| W | 2       ---->| E |
+      +---+           +---+------  |  -->+---+
+                       | |       | | |
+                     3 | | 4,5   | | |
+         --------------   -----  | | |
+        |                      | | | |
+        |                      | | | |
+        |                 ---------  |
+        |               1|     | |   |
+        V                |     | |   |
+      +---+   PASS    +---+ 2  |  ------>+---+
+      |   |---------->| W |------------->| S |
+      +---+           +---+   ---------->+---+
+                       | |   | |     |
+                     3 | |4,5| |     |
+         --------------   --------   |
+        |                    | |  |  |
+        |                    | |  |  |
+        |                 -----------
+        |             1,3|   | |  |
+        V                |  2| |  |
+      +---+   ACCT    +---+--  |   ----->+---+
+      |   |---------->| W | 4,5 -------->| F |
+      +---+           +---+------------->+---+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 57]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   Finally, we present a generalized diagram that could be used to model
+   the command and reply interchange:
+
+      
+               ------------------------------------
+              |                                    |
+      Begin   |                                    |
+        |     V                                    |
+        |   +---+  cmd   +---+ 2         +---+     |
+         -->|   |------->|   |---------->|   |     |
+            |   |        | W |           | S |-----|
+         -->|   |     -->|   |-----      |   |     |
+        |   +---+    |   +---+ 4,5 |     +---+     |
+        |     |      |    | |      |               |
+        |     |      |   1| |3     |     +---+     |
+        |     |      |    | |      |     |   |     |
+        |     |       ----  |       ---->| F |-----
+        |     |             |            |   |
+        |     |             |            +---+
+         -------------------
+              |
+              |
+              V
+             End
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 58]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+7.  TYPICAL FTP SCENARIO
+
+   User at host U wanting to transfer files to/from host S:
+
+   In general, the user will communicate to the server via a mediating
+   user-FTP process.  The following may be a typical scenario.  The
+   user-FTP prompts are shown in parentheses, '---->' represents
+   commands from host U to host S, and '<----' represents replies from
+   host S to host U.
+
+      LOCAL COMMANDS BY USER              ACTION INVOLVED
+
+      ftp (host) multics<CR>         Connect to host S, port L,
+                                     establishing control connections.
+                                     <---- 220 Service ready <CRLF>.
+      username Doe <CR>              USER Doe<CRLF>---->
+                                     <---- 331 User name ok,
+                                               need password<CRLF>.
+      password mumble <CR>           PASS mumble<CRLF>---->
+                                     <---- 230 User logged in<CRLF>.
+      retrieve (local type) ASCII<CR>
+      (local pathname) test 1 <CR>   User-FTP opens local file in ASCII.
+      (for. pathname) test.pl1<CR>   RETR test.pl1<CRLF> ---->
+                                     <---- 150 File status okay;
+                                           about to open data
+                                           connection<CRLF>.
+                                     Server makes data connection
+                                     to port U.
+      
+                                     <---- 226 Closing data connection,
+                                         file transfer successful<CRLF>.
+      type Image<CR>                 TYPE I<CRLF> ---->
+                                     <---- 200 Command OK<CRLF>
+      store (local type) image<CR>
+      (local pathname) file dump<CR> User-FTP opens local file in Image.
+      (for.pathname) >udd>cn>fd<CR>  STOR >udd>cn>fd<CRLF> ---->
+                                     <---- 550 Access denied<CRLF>
+      terminate                      QUIT <CRLF> ---->
+                                     Server closes all
+                                     connections.
+
+8.  CONNECTION ESTABLISHMENT
+
+   The FTP control connection is established via TCP between the user
+   process port U and the server process port L.  This protocol is
+   assigned the service port 21 (25 octal), that is L=21.
+
+
+
+Postel & Reynolds                                              [Page 59]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+APPENDIX I -  PAGE STRUCTURE
+
+   The need for FTP to support page structure derives principally from
+   the  need to support efficient transmission of files between TOPS-20
+   systems, particularly the files used by NLS.
+
+   The file system of TOPS-20 is based on the concept of pages.  The
+   operating system is most efficient at manipulating files as pages.
+   The operating system provides an interface to the file system so that
+   many applications view files as sequential streams of characters.
+   However, a few applications use the underlying page structures
+   directly, and some of these create holey files.
+
+   A TOPS-20 disk file consists of four things: a pathname, a page
+   table, a (possibly empty) set of pages, and a set of attributes.
+
+   The pathname is specified in the RETR or STOR command.  It includes
+   the directory name, file name, file name extension, and generation
+   number.
+
+   The page table contains up to 2**18 entries.  Each entry may be
+   EMPTY, or may point to a page.  If it is not empty, there are also
+   some page-specific access bits; not all pages of a file need have the
+   same access protection.
+
+      A page is a contiguous set of 512 words of 36 bits each.
+
+   The attributes of the file, in the File Descriptor Block (FDB),
+   contain such things as creation time, write time, read time, writer's
+   byte-size, end-of-file pointer, count of reads and writes, backup
+   system tape numbers, etc.
+
+   Note that there is NO requirement that entries in the page table be
+   contiguous.  There may be empty page table slots between occupied
+   ones.  Also, the end of file pointer is simply a number.  There is no
+   requirement that it in fact point at the "last" datum in the file.
+   Ordinary sequential I/O calls in TOPS-20 will cause the end of file
+   pointer to be left after the last datum written, but other operations
+   may cause it not to be so, if a particular programming system so
+   requires.
+
+   In fact, in both of these special cases, "holey" files and
+   end-of-file pointers NOT at the end of the file, occur with NLS data
+   files.
+
+
+
+
+
+Postel & Reynolds                                              [Page 60]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   The TOPS-20 paged files can be sent with the FTP transfer parameters:
+   TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).
+
+   Each page of information has a header.  Each header field, which is a
+   logical byte, is a TOPS-20 word, since the TYPE is L 36.
+
+   The header fields are:
+
+      Word 0: Header Length.
+
+         The header length is 5.
+
+      Word 1: Page Index.
+
+         If the data is a disk file page, this is the number of that
+         page in the file's page map.  Empty pages (holes) in the file
+         are simply not sent.  Note that a hole is NOT the same as a
+         page of zeros.
+
+      Word 2: Data Length.
+
+         The number of data words in this page, following the header.
+         Thus, the total length of the transmission unit is the Header
+         Length plus the Data Length.
+
+      Word 3: Page Type.
+
+         A code for what type of chunk this is.  A data page is type 3,
+         the FDB page is type 2.
+
+      Word 4: Page Access Control.
+
+         The access bits associated with the page in the file's page
+         map.  (This full word quantity is put into AC2 of an SPACS by
+         the program reading from net to disk.)
+
+   After the header are Data Length data words.  Data Length is
+   currently either 512 for a data page or 31 for an FDB.  Trailing
+   zeros in a disk file page may be discarded, making Data Length less
+   than 512 in that case.
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 61]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+APPENDIX II -  DIRECTORY COMMANDS
+
+   Since UNIX has a tree-like directory structure in which directories
+   are as easy to manipulate as ordinary files, it is useful to expand
+   the FTP servers on these machines to include commands which deal with
+   the creation of directories.  Since there are other hosts on the
+   ARPA-Internet which have tree-like directories (including TOPS-20 and
+   Multics), these commands are as general as possible.
+
+      Four directory commands have been added to FTP:
+
+         MKD pathname
+
+            Make a directory with the name "pathname".
+
+         RMD pathname
+
+            Remove the directory with the name "pathname".
+
+         PWD
+
+            Print the current working directory name.
+
+         CDUP
+
+            Change to the parent of the current working directory.
+
+   The  "pathname"  argument should be created (removed) as a
+   subdirectory of the current working directory, unless the "pathname"
+   string contains sufficient information to specify otherwise to the
+   server, e.g., "pathname" is an absolute pathname (in UNIX and
+   Multics), or pathname is something like "<abso.lute.path>" to
+   TOPS-20.
+
+   REPLY CODES
+
+      The CDUP command is a special case of CWD, and is included to
+      simplify the implementation of programs for transferring directory
+      trees between operating systems having different syntaxes for
+      naming the parent directory.  The reply codes for CDUP be
+      identical to the reply codes of CWD.
+
+      The reply codes for RMD be identical to the reply codes for its
+      file analogue, DELE.
+
+      The reply codes for MKD, however, are a bit more complicated.  A
+      freshly created directory will probably be the object of a future
+
+
+Postel & Reynolds                                              [Page 62]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      CWD command.  Unfortunately, the argument to MKD may not always be
+      a suitable argument for CWD.  This is the case, for example, when
+      a TOPS-20 subdirectory is created by giving just the subdirectory
+      name.  That is, with a TOPS-20 server FTP, the command sequence
+
+         MKD MYDIR
+         CWD MYDIR
+
+      will fail.  The new directory may only be referred to by its
+      "absolute" name; e.g., if the MKD command above were issued while
+      connected to the directory <DFRANKLIN>, the new subdirectory
+      could only be referred to by the name <DFRANKLIN.MYDIR>.
+
+      Even on UNIX and Multics, however, the argument given to MKD may
+      not be suitable.  If it is a "relative" pathname (i.e., a pathname
+      which is interpreted relative to the current directory), the user
+      would need to be in the same current directory in order to reach
+      the subdirectory.  Depending on the application, this may be
+      inconvenient.  It is not very robust in any case.
+
+      To solve these problems, upon successful completion of an MKD
+      command, the server should return a line of the form:
+
+         257<space>"<directory-name>"<space><commentary>
+
+      That is, the server will tell the user what string to use when
+      referring to the created  directory.  The directory name can
+      contain any character; embedded double-quotes should be escaped by
+      double-quotes (the "quote-doubling" convention).
+
+      For example, a user connects to the directory /usr/dm, and creates
+      a subdirectory, named pathname:
+
+         CWD /usr/dm
+         200 directory changed to /usr/dm
+         MKD pathname
+         257 "/usr/dm/pathname" directory created
+
+      An example with an embedded double quote:
+
+         MKD foo"bar
+         257 "/usr/dm/foo""bar" directory created
+         CWD /usr/dm/foo"bar
+         200 directory changed to /usr/dm/foo"bar
+
+
+
+
+
+Postel & Reynolds                                              [Page 63]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      The prior existence of a subdirectory with the same name is an
+      error, and the server must return an "access denied" error reply
+      in that case.
+
+         CWD /usr/dm
+         200 directory changed to /usr/dm
+         MKD pathname
+         521-"/usr/dm/pathname" directory already exists;
+         521 taking no action.
+
+      The failure replies for MKD are analogous to its file  creating
+      cousin, STOR.  Also, an "access denied" return is given if a file
+      name with the same name as the subdirectory will conflict with the
+      creation of the subdirectory (this is a problem on UNIX, but
+      shouldn't be one on TOPS-20).
+
+      Essentially because the PWD command returns the same type of
+      information as the successful MKD command, the successful PWD
+      command uses the 257 reply code as well.
+
+   SUBTLETIES
+
+      Because these commands will be most useful in transferring
+      subtrees from one machine to another, carefully observe that the
+      argument to MKD is to be interpreted as a sub-directory of  the
+      current working directory, unless it contains enough information
+      for the destination host to tell otherwise.  A hypothetical
+      example of its use in the TOPS-20 world:
+
+         CWD <some.where>
+         200 Working directory changed
+         MKD overrainbow
+         257 "<some.where.overrainbow>" directory created
+         CWD overrainbow
+         431 No such directory
+         CWD <some.where.overrainbow>
+         200 Working directory changed
+
+         CWD <some.where>
+         200 Working directory changed to <some.where>
+         MKD <unambiguous>
+         257 "<unambiguous>" directory created
+         CWD <unambiguous>
+
+      Note that the first example results in a subdirectory of the
+      connected directory.  In contrast, the argument in the second
+      example contains enough information for TOPS-20 to tell that  the
+
+
+Postel & Reynolds                                              [Page 64]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      <unambiguous> directory is a top-level directory.  Note also that
+      in the first example the user "violated" the protocol by
+      attempting to access the freshly created directory with a name
+      other than the one returned by TOPS-20.  Problems could have
+      resulted in this case had there been an <overrainbow> directory;
+      this is an ambiguity inherent in some TOPS-20 implementations.
+      Similar considerations apply to the RMD command.  The point is
+      this: except where to do so would violate a host's conventions for
+      denoting relative versus absolute pathnames, the host should treat
+      the operands of the MKD and RMD commands as subdirectories.  The
+      257 reply to the MKD command must always contain the absolute
+      pathname of the created directory.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 65]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+APPENDIX III - RFCs on FTP
+
+   Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
+   MIT-Project MAC, 16 April 1971.
+
+   Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
+   Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.
+
+   Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
+   (NIC 6794), MIT-Project MAC, 23 June 1971.
+
+   Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663),
+   UCLA/CCN, 29 September 1971.
+
+   Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
+   (NIC 7813), MIT-Project MAC, 17 November 1971.
+
+   McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
+   RFC 281 (NIC 8163), BBN, 8 December 1971.
+
+   Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
+   Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
+   25 January 1972.
+
+   Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
+   MIT-Project MAC, 8 July 1972.
+
+   Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
+   RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.
+
+   Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
+   27 November 1972.
+
+   Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
+   Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.
+
+   Braden, Bob, "Comments on File Transfer Protocol", RFC 430
+   (NIC 13299), UCLA/CCN, 7 February 1973.
+
+   Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
+   RFC 438 (NIC 13770), BBN, 15 January 1973.
+
+   Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN,
+   27 February 1973.
+
+   McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN,
+   16 February 1973.
+
+
+Postel & Reynolds                                              [Page 66]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458
+   (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.
+
+   Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN,
+   12 July 1973.
+
+   Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
+   Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974.
+
+   Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the
+   File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974.
+
+   Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
+   "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB,
+   Ames Research Center, SRI-ARC, 28 February 1974.
+
+   Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463
+   (NIC 14573), MIT-DMCG, 21 February 1973.
+
+   Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN,
+   8 March 1973.
+
+   Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919),
+   MIT-DMCG, 6 March 1973.
+
+   Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
+   RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.
+
+   White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
+   SRI-ARC, 8 March 1973.
+
+   White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
+   SRI-ARC, 8 March 1973.
+
+   Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506
+   (NIC 16157), MIT-Multics, 26 June 1973.
+
+   Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
+   RFC 520 (NIC 16819), Illinois, 25 June 1973.
+
+   Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532
+   (NIC 17451), UCSD-CC, 22 June 1973.
+
+   Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN,
+   15 November 1973.
+
+
+
+
+Postel & Reynolds                                              [Page 67]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
+   Schedule Change", RFC 593 (NIC 20615), BBN and MITRE,
+   29 November 1973.
+
+   Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
+   Service", RFC 630 (NIC 30237), BBN, 10 April 1974.
+
+   Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843),
+   UCLA/NMC, 5 June 1974.
+
+   Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481),
+   SU-AI, 10 May 1975.
+
+   Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI,
+   28 May 1975.
+
+   Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975.
+
+   Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
+   31 October 1977.
+
+   Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
+   SRI-KL, 30 December 1977.
+
+   Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT,
+   10 December 1978.
+
+   Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI,
+   June 1980.
+
+   Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
+   Commands", RFC 776, BBN, December 1980.
+
+   Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE,
+   July 1985.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 68]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+REFERENCES
+
+   [1]  Feinler, Elizabeth, "Internet Protocol Transition Workbook",
+        Network Information Center, SRI International, March 1982.
+
+   [2]  Postel, Jon, "Transmission Control Protocol - DARPA Internet
+        Program Protocol Specification", RFC 793, DARPA, September 1981.
+
+   [3]  Postel, Jon, and Joyce Reynolds, "Telnet Protocol
+        Specification", RFC 854, ISI, May 1983.
+
+   [4]  Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943,
+        ISI, April 1985.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 69]
+
diff --git a/include/Task.h b/include/Task.h
index 4de3fa5..456f8f3 100644
--- a/include/Task.h
+++ b/include/Task.h
@@ -2,7 +2,6 @@
 #define __TASK_H__
 #ifdef __cplusplus
 
-#include <setjmp.h>
 #include "Exceptions.h"
 
 #define TASK_ON_HOLD 	0
@@ -21,7 +20,6 @@ class Task : public Base {
     virtual int Do();
     
   private:
-    jmp_buf env;
     int state;
     bool suspended;
 };
diff --git a/lib/Exceptions.cc b/lib/Exceptions.cc
index 9d2ba8e..585b946 100644
--- a/lib/Exceptions.cc
+++ b/lib/Exceptions.cc
@@ -9,9 +9,21 @@
 
 char GeneralException::t[BUFSIZ];
 
-GeneralException::GeneralException(String emsg) : msg(emsg.strdup()) { }
-GeneralException::GeneralException() : msg(0) { }
-GeneralException::GeneralException(const GeneralException & e) : msg(strdup(e.msg)) { }
+GeneralException::GeneralException(String emsg) : msg(emsg.strdup()) {
+#ifdef DEBUG
+    cerr << "Generating a General Exception error: '" << msg << "'.\n";
+#endif
+}
+GeneralException::GeneralException() : msg(0) {
+#ifdef DEBUG
+    cerr << "Generating a General Exception error: '" << msg << "'.\n";
+#endif
+}
+GeneralException::GeneralException(const GeneralException & e) : msg(strdup(e.msg)) {
+#ifdef DEBUG
+    cerr << "Generating a General Exception error: '" << msg << "'.\n";
+#endif
+}
 
 GeneralException::~GeneralException() {
     free(msg);
@@ -36,9 +48,17 @@ IOGeneral::IOGeneral(String fn) : GeneralException(fn) { }
 
 IOGeneral::IOGeneral() { }
 
-IOAgain::IOAgain() : IOGeneral(_("No more bytes for reading or writing.")) { }
+IOAgain::IOAgain() : IOGeneral(_("No more bytes for reading or writing.")) {
+#ifdef DEBUG
+    cerr << "Generating an IOAgain exception: '" << GetMsg() << "'.\n";
+#endif
+}
 
-TaskSwitch::TaskSwitch() : GeneralException(_("Switching task in a non-tasked environnement")) { }
+TaskSwitch::TaskSwitch() : GeneralException(_("Switching task in a non-tasked environnement")) {
+#ifdef DEBUG
+    cerr << "Generating a TaskSwitch exception: '" << GetMsg() << "'.\n";
+#endif
+}
 
 char * xstrdup(const char * s) throw (GeneralException) {
     char * r;
diff --git a/lib/Handle.cc b/lib/Handle.cc
index da9870f..7ad7cc6 100644
--- a/lib/Handle.cc
+++ b/lib/Handle.cc
@@ -40,7 +40,7 @@ ssize_t Handle::write(const void *buf, size_t count) throw (GeneralException) {
 		    done = false;
 		    full = true;
 		    if (nonblock) {
-			throw TaskSwitch();
+			throw IOAgain();
 		    } else {
 			sleep(1);
 		    }
@@ -66,7 +66,7 @@ ssize_t Handle::read(void *buf, size_t count) throw (GeneralException) {
 	if ((!errno) || (errno = EAGAIN)) {
 	    // Avant de déclarer une erreur, on vérifie si ce n'est pas un
 	    // problème lié au fait qu'il n'y a plus d'octets.
-	    throw TaskSwitch();
+	    throw IOAgain();
 	} else {
 	    throw IOException(GetName(), IO_READ, count);
 	}
diff --git a/lib/ReadJob.cc b/lib/ReadJob.cc
index 3bab150..a63eeca 100644
--- a/lib/ReadJob.cc
+++ b/lib/ReadJob.cc
@@ -13,23 +13,27 @@ int ReadJob::Do() {
     
     while (!s->IsClosed()) {
 	if (!current) {
+	    r = 0;
 	    try {
 		cerr << "Trying to read...\n";
 		*s >> buff;
 	    }
 	    catch (IOAgain e) {
 		cerr << "Suspending ReadJob to wait for reading...\n";
-		Suspend();
+		r = 1;
 	    }
+	    if (r) Suspend();
 	    cerr << "Read some bytes...\n";
 	}
+	r = 0;
 	try {
 	    *d << buff << endnl;
 	}
 	catch (IOAgain e) {
 	    cerr << "Suspending ReadJob to wait for writing...\n";
-	    Suspend();
+	    r = 1;
 	}
+	if (r) Suspend();
 	cerr << "Wrote some bytes...\n";
 	if (buff == "") return TASK_DONE;
     }
diff --git a/lib/Task.cc b/lib/Task.cc
index 42147d3..c34d0e3 100644
--- a/lib/Task.cc
+++ b/lib/Task.cc
@@ -12,16 +12,19 @@ int Task::Do() {
 int Task::Run() {
     cerr << "Running task '" << GetName() << "'...\n";
     try {
+	cerr << "Launching method Do()...\n";
 	state = Do();
     }
     catch (TaskSwitch) {
-	Resume(1);
+	cerr << "Catch a task switching.\n";
 	throw;
     }
     catch (GeneralException e) {
 	cerr << "Task " << GetName() << " caused an unexpected exception: '" << e.GetMsg() << "', closing it.\n";
 	return TASK_DONE;
     }
+    
+    cerr << "Task exitted normally.\n";
         
     return state;
 }
@@ -49,8 +52,8 @@ int Task::Suspend() throw (GeneralException) {
 }
 
 void Task::Resume(int val) throw (GeneralException) {
+    cerr << "Resuming task " << GetName() << "...\n";
     if (suspended) {
-	cerr << "Resuming task " << GetName() << "...\n";
 	suspended = false;
 	longjmp(env, val);
     } else {
-- 
cgit v1.2.3