incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ran...@apache.org
Subject svn commit: r280789 [2/4] - in /incubator/public/trunk/site-publish/projects/ftpserver: rfc2389.pdf rfc2428.html rfc2428.pdf rfc959.html rfc959.pdf site_commands.html site_commands.pdf ssl.html ssl.pdf who_we_are.html who_we_are.pdf
Date Wed, 14 Sep 2005 07:05:35 GMT
Added: incubator/public/trunk/site-publish/projects/ftpserver/rfc959.html
URL: http://svn.apache.org/viewcvs/incubator/public/trunk/site-publish/projects/ftpserver/rfc959.html?rev=280789&view=auto
==============================================================================
--- incubator/public/trunk/site-publish/projects/ftpserver/rfc959.html (added)
+++ incubator/public/trunk/site-publish/projects/ftpserver/rfc959.html Wed Sep 14 00:05:09 2005
@@ -0,0 +1,4144 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<head>
+<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<link rel="stylesheet" href="skin/tigris.css" type="text/css">
+<link rel="stylesheet" href="skin/mysite.css" type="text/css">
+<link rel="stylesheet" href="skin/site.css" type="text/css">
+<link media="print" rel="stylesheet" href="skin/print.css" type="text/css">
+<title>Apache FTP Server</title>
+</head>
+<body bgcolor="white" class="composite">
+<div id="banner">
+<table width="100%" cellpadding="8" cellspacing="0" summary="banner" border="0">
+<tbody>
+<tr>
+<td align="left">
+<div class="groupLogo">
+<a href="http://www.apache.org"><img border="0" class="logoImage" alt="Apache" src="resources/images/group-logo.gif"></a>
+</div>
+</td><td align="right">
+<div class="projectLogo">
+<a href="http://incubator.apache.org/projects/ftpserver/"><img border="0" class="logoImage" alt="Ftpserver" src="resources/images/project-logo.gif"></a>
+</div>
+</td>
+</tr>
+</tbody>
+</table>
+</div>
+<table width="100%" cellpadding="0" cellspacing="0" border="0" summary="nav" id="breadcrumbs">
+<tbody>
+<tr class="status">
+<td><a href="http://www.apache.org/">Apache</a> | <a href="http://incubator.apache.org/">Incubator</a> | <a href="http://incubator.apache.org/projects/ftpserver/">FTP Server</a></td><td id="tabs">
+<div class="tab">
+<span class="selectedTab"><a class="base-selected" href="index.html">Home</a></span> | <script language="Javascript" type="text/javascript">
+function printit() {  
+if (window.print) {
+    window.print() ;  
+} else {
+    var WebBrowser = '<OBJECT ID="WebBrowser1" WIDTH="0" HEIGHT="0" CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"></OBJECT>';
+document.body.insertAdjacentHTML('beforeEnd', WebBrowser);
+    WebBrowser1.ExecWB(6, 2);//Use a 1 vs. a 2 for a prompting dialog box    WebBrowser1.outerHTML = "";  
+}
+}
+</script><script language="Javascript" type="text/javascript">
+var NS = (navigator.appName == "Netscape");
+var VERSION = parseInt(navigator.appVersion);
+if (VERSION > 3) {
+    document.write('  <a title="PRINT this page OUT" href="javascript:printit()">PRINT</a>');
+}
+</script> | <a title="PDF file of this page" href="rfc959.pdf">PDF</a>
+</div>
+</td>
+</tr>
+</tbody>
+</table>
+<table id="main" width="100%" cellpadding="8" cellspacing="0" summary="" border="0">
+<tbody>
+<tr valign="top">
+<td id="leftcol">
+<div id="navcolumn">
+<div class="menuBar">
+<div class="menu">
+<span class="menuLabel">Apache FTP Server</span>
+        
+<div class="menuItem">
+<a href="index.html">Welcome</a>
+</div>
+        
+<div class="menuItem">
+<a href="license.html">License</a>
+</div>
+        
+<div class="menuItem">
+<a href="mailing_list.html">Mailing List</a>
+</div>
+        
+<div class="menuItem">
+<a href="who_we_are.html">Who We Are</a>
+</div>
+        
+<div class="menuItem">
+<a href="download.html">Download</a>
+</div>
+    
+</div>
+<div class="menu">
+<span class="menuLabel">Setup</span>
+        
+<div class="menuItem">
+<a href="installation.html">Installation</a>
+</div>
+        
+<div class="menuItem">
+<a href="configuration.html">Configuration</a>
+</div>
+        
+<div class="menuItem">
+<a href="ssl.html">TLS/SSL Support</a>
+</div>
+        
+<div class="menuItem">
+<a href="user_manager.html">User Manager</a>
+</div>
+        
+<div class="menuItem">
+<a href="ip_restrictor.html">IP Restrictor</a>
+</div>
+        
+<div class="menuItem">
+<a href="logger.html">Logger</a>
+</div>
+        
+<div class="menuItem">
+<a href="messages.html">Messages</a>
+</div>
+    
+</div>
+<div class="menu">
+<span class="menuLabel">Advanced</span>
+        
+<div class="menuItem">
+<a href="ftp_commands.html">FTP Commands</a>
+</div>
+        
+<div class="menuItem">
+<a href="site_commands.html">SITE Commands</a>
+</div>
+        
+<div class="menuItem">
+<a href="ftplet.html">Ftplet</a>
+</div>
+        
+<div class="menuItem">
+<a href="javadoc/index.html">Javadoc</a>
+</div>
+    
+</div>
+<div class="menu">
+<span class="menuLabel">RFCs</span>
+        
+<div class="menuItem">
+<span class="menuSelected">RFC959</span>
+</div>
+        
+<div class="menuItem">
+<a href="rfc2228.html">RFC2228</a>
+</div>
+        
+<div class="menuItem">
+<a href="rfc2389.html">RFC2389</a>
+</div>
+        
+<div class="menuItem">
+<a href="rfc2428.html">RFC2428</a>
+</div>
+    
+</div>
+</div>
+</div>
+</td><td>
+<div id="bodycol">
+<div class="app">
+<div align="center">
+<h1>Apache FTP Server</h1>
+</div>
+<div class="h3"> 
+     
+   
+      
+<div class="h3">
+<h3>RFC 959</h3>
+</div>
+          
+          
+<pre class="code">
+                                                                        
+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 &amp; 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 &amp; 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 &amp; 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 &amp; 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 &amp; 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 &amp; 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 &amp; 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|&lt;---&gt;| User |
+                                            |\----^----/|    --------
+                  ----------                |     |     |
+                  |/------\|  FTP Commands  |/----V----\|
+                  ||Server|&lt;----------------&gt;|   User  ||
+                  ||  PI  ||   FTP Replies  ||    PI   ||
+                  |\--^---/|                |\----^----/|
+                  |   |    |                |     |     |
+      --------    |/--V---\|      Data      |/----V----\|    --------
+      | File |&lt;---&gt;|Server|&lt;----------------&gt;|  User   |&lt;---&gt;| 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 &amp; 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
+                    ----------&gt;| User-FTP |&lt;-----------
+                    |          | User-PI  |           |
+                    |          |   "C"    |           |
+                    V          ------------           V
+            --------------                        --------------
+            | Server-FTP |   Data Connection      | Server-FTP |
+            |    "A"     |&lt;----------------------&gt;|    "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 &amp; 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 &amp; 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 &lt;CRLF&gt; 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 &amp; 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 &lt;NL&gt; 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 &amp; 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 &amp; 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., &lt;CR&gt;, &lt;LF&gt;, &lt;NL&gt;, &lt;VT&gt;, &lt;FF&gt;) which the printer
+               process will interpret appropriately.  &lt;CRLF&gt;, 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 &lt;CRLF&gt;
+               end-of-line sequence is used to separate printing lines,
+               but these format effectors are overridden by the ASA
+               controls.
+
+
+
+
+
+
+Postel &amp; 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 &lt;CRLF&gt;.  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 &amp; Reynolds                                              [Page 15]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         &lt;CRLF&gt; for ASCII, or &lt;NL&gt; 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 &amp; 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 &amp; 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 &amp; 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 &amp; 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 &lt;CRLF&gt; or &lt;NL&gt;,
+      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 &amp; 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 &amp; 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).  &lt;SP&gt; (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 &amp; 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&gt;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 &lt;SP&gt;
+         (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 &amp; 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 &amp; 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 &amp; 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 &amp; 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 &amp; 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 &lt;SP&gt; (Space, ASCII code
+            32).
+
+            The following codes are assigned for type:
+
+                         \    /
+               A - ASCII |    | N - Non-print
+                         |-&gt;&lt;-| T - Telnet format effectors
+               E - EBCDIC|    | C - Carriage Control (ASA)
+                         /    \
+               I - Image
+               
+               L &lt;byte size&gt; - Local byte Byte size
+
+
+Postel &amp; 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 &amp; 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 &amp; 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 &lt;SP&gt; R &lt;SP&gt;.  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 &amp; 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 &amp; 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 &lt;CRLF&gt; or &lt;NL&gt;.  (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 &amp; 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 &lt;CRLF&gt;.  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 &lt;SP&gt; (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 &amp; 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

[... 2021 lines stripped ...]


---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message