dialogue, the server should return a 331 or 433 reply depending
on whether he stores (pending receipt of the ACCounT command)
or discards the command, respectively.
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 TELNET connection is left open. This is identical to
the state in which a user finds himself immediately after the
ICP is completed and the TELNET connections are opened. A USER
command may be expected to follow.
LOGOUT (BYE)
This command terminates a USER and if file transfer is not in
progress, the server closes the TELNET 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 BYE.
An unexpected close on the TELNET connection will cause the
server to take the effective action of an abort (ABOR) and a
logout (BYE).
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 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.
BYTE SIZE (BYTE)
The argument is a decimal integer (1 through 255) specifying
the byte size for the data connection. The default byte size
is 8 bits. A server may reject certain byte sizes that he has
not implemented.
23
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
DATA SOCKET (SOCK)
The argument is a HOST-SOCKET specification for the data socket
to be used in data connection. There may be two data sockets,
one for transfer from the "active" DTP to the "passive" DTP and
one for "passive" to "active". An odd socket number defines a
send socket and an even socket number defines a receive socket.
The default HOST is the user Host to which TELNET connections
are made. The default data sockets are (U+4) and (U+5) where U
is the socket number used in the TELNET ICP and the TELNET
connections are on sockets (U+2) and (U+3). The server has
fixed data sockets (S+2) and (S+3) as well, and under normal
circimstances this command and its reply are not needed.
PASSIVE (PASV)
This command requests the server-DTP to "listen" on both of his
data sockets and to wait for an RFCto arrive for one socket
rather than initiate one upon receipt of a transfer command.
It is assumed the server has already received a SOCK command to
indicate the foreign socket from which the RFCwill arrive to
ensure the security of the transfer.
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 # - Local byte Bytesize
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.
24
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
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
The default structure is File (i.e., no records).
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.
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 TELNET 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. The
data, when transferred in response to FTP service 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.
25
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
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.
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 structure a maximum record size (in logical bytes) might
also be necessary; this is indicated by a decimal integer in a
second argument field of 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 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 "spaces" 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.
26
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
RENAME FROM (RNFR)
This command specifies 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 indicates to 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 TELNET connections
are not to be closed by the server, but the data connection
must be closed. An appropriate reply should be sent by the
server in all cases.
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.
LIST (LIST)
This command causes a list to be sent from the server to the
passive DTP. If the pathname specifies a directory, 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 ensure that the TYPE is appropriately ASCII or
EBCDIC).
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
27
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
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.)
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.
STATUS (STAT)
This command shall cause a status response to be sent over the
TELNET 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 trasferred over the TELNET
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 TELNET 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 Oxx, general system status. 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 a 200 reply.
28
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
MISCELLANEOUS COMMANDS
There are several functions that utilize the services of file
transfer but go beyond it in scope. These are the Mail and Remote
Job Entry functions. It is suggested that these become auxiliary
protocols that can assume recognition of file transfer commands on
the part of the server, i.e., they may depend on the core of FTP
commands. The command sets specific to Mail and RJE will be given in
separate documents.
Commands that are closely related to file transfer but not proven
essential to the protocol may be implemented by servers on an
experimental basis. The command name should begin with an X and may
be listed in the HELP command. The official command set is
expandable from these experiments; all experimental commands or
proposals for expanding the official command set should be announced
via RFC. An example of a current experimental command is:
Change Working Directory (XCWD)
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.
FTP REPLIES
The server sends FTP replies over the TELNET connection in response
to user FTP commands. The FTP replies constitute the acknowledgment
or completion code (including errors). The FTP-server replies are
formatted for human or program interpretation. Single line replies
consist of a leading three-digit numeric code followed by a space,
followed by a one-line text explanation of the code. For replies
that contain several lines of text, the first line will have a
leading three-digit numeric code followed immediately by the
character "-" (Hyphen, ASCII code 45), and possibly some text. All
succeeding continuation lines except the last are constrained NOT to
begin with three digits; the last line must repeat the numeric code
of the first line and be followed immediately by a space. For
example:
100-First Line
Continuation Line
Another Line
100 Last Line
It is possible to nest (but not overlap) a reply withiin a multi-line
29
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
reply. The same format for matched number-coded first and last lines
holds.
The numeric codes are assigned by groups and for ease of
interpretation by programs in a manner consistent with other
protocols such as the RJE protocol. The three digits of the code are
to be interpreted as follows:
1. The first digit specifies type of response as indicated below:
0xx These replies are purely informative and constitute
neither a positive nor a negative acknowledgment.
1xx Informative replies to status inquiries. These constitute
a positive acknowledgment to the status command.
2xx Positive acknowledgment of previous command or other
successful action.
3xx Incomplete information. Activity cannot proceed without
further specification and input.
4xx Unsuccessful reply. The request is correctly specified
but the server is unsuccessful in correctly fulfilling it.
5xx Incorrect or illegal command. The command or its
parameters were invalid or incomplete from a syntactic
viewpoint, or the command is inconsistent with a previous
command. The command in question has been completely
ignored.
6xx-9xx Reserved for future expansion.
2. The second digit specifies the general category to which the
response refers:
x00-x29 General purpose replies, not assignable to other
categories.
x3x Primary access. Informative replies to the "log-on"
attempt.
x4x Secondary access. The primary server is commenting on its
ability to access a secondary service.
x5x FTP results.
x6x RJE results.
30
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
x7x Mail Portocol results.
x8x-x9x Reserved for future expansion.
3. The final digit specifies a particular message type. Since the
code is designed for an automaton process to interpret, it is
not necessary for every variation of a reply to have a unique
number. Only the basic meaning of replies need have unique
numbers. The text of a reply can explain the specific reason
for that reply to a human user.
Each TELNET line delimited by a numeric code and the TELNET EOL (or
group of text lines bounded by coded lines) that is sent by the
server is intended to be a complete reply message. It should be noted
that the text of replies is intended for a human user. Only the reply
codes and in some instances the first line of text are intended for
programs.
The assigned reply codes relating to FTP are:
000 Announcing FTP.
010 Message from system operator.
020 Exected delay.
030 Server availability information.
050 FTP commentary or user information.
100 System status reply.
110 System busy doing...
150 File status reply.
151 Directory listing reply.
200 Last command received correctly.
201 An ABORT has terminated activity, as requested.
202 Abort request ignored, no activity in progress.
230 User is "logged in". May proceed.
231 User is "logged out". Service terminated.
232 Logout command noted, will complete when transfer done.
233 User is "logged out". Parameters reinitialized.
250 FTP file transfer started correctly.
251 FTP Restart-marker reply.
Text is: MARK yyyy = mmmm
where 'yyyy' is user's data stream marker (yours)
and mmmm is server's equivalent marker (mine)
(Note the spaces between the markers and '=').
252 FTP transfer completed correctly.
253 Rename completed.
254 Delete completed.
257 Closing the data connection, transfer completed.
300 Connection greeting message, awaiting input.
301 Current command incomplete (no <CRLF> for long time).
330 Enter password.
31
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
331 Enter account (if account required as part of login sequence).
332 Login first, please.
400 This service not implemented.
401 This service not accepting users now, goodbye.
402 Command not implemented for requested value or action.
430 Log-on time or tries exceeded, goodbye.
431 Log-on unsuccessful. User and/or password invalid.
432 User not valid for this service.
433 Cannot transfer files without valid account. Enter account and
resend command.
434 Log-out forced by operator action. Phone site.
435 Log-out forced by system problem.
436 Service shutting down, goodbye.
450 FTP: File not found.
451 FTP: File access denied to you.
452 FTP: File transfer incomplete, data connection closed.
453 FTP: File transfer incomplete, insufficient storage space.
454 FTP: Cannot connect to your data socket.
455 FTP: File system error not covered by other reply codes.
456 FTP: Name duplication; rename failed.
457 FTP: Transfer parameters in error.
500 Last command line completely unrecognized.
501 Syntax of last command is incorrect.
502 Last command incomplete, parameters missing.
503 Last command invalid (ignored), illegal parameter combination.
504 Last command invalid, action not possible at this time.
505 Last command conflicts illegally with previous command(s).
506 Last command not implemented by the server.
507 Catchall error reply.
550 Bad pathname specification (e.g., syntax error).
32
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
DECLARATIVE SPECIFICATIONS
MINIMUM IMPLEMENTATION
In order to make FTP workable without needless error messages, the
following minimum implementation is required for servers:
TYPE - ASCII Non-print
MODE - Stream
STRUCTURE - File
Record
BYTE - 8
COMMANDS - USER, BYE, SOCK,
TYPE, BYTE, MODE, STRU,
for the default values
RETR, STOR,
NOOP.
The initial default values for transfer parameters are:
TYPE - ASCII Non-print
BYTE - 8
MODE - Stream
STRU - File
All Hosts must accept the above as the standard defaults.
CONNECTIONS
The server protocol interpreter shall "listen" on Socket 3. The user
or user protocol interpreter shall initiate the full-duplex TELNET
connections performing the ARPANET standard initial connection
protocol (ICP) to server Socket 3. Server- and user- processes
should follow the conventions of the TELNET protocol as specified in
NIC #7104. Servers are under no obligation to provide for editing of
command lines and may specify that it be done in the user Host. The
TELNET connections 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 sockets (send and/or
receive); these may be the default user sockets (U+4) and (U+5) or a
socket specified in the SOCK command. The server shall initiate the
data connection from his own fixed sockets (S+2) and (S+3) using the
specified user data socket and byte size (default - 8 bits). The
33
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
direction of the transfer and the sockets used will be determined by
the FTP service command.
When data is to be transferred between two servers, A and B (refer to
Figure 2), the user-PI, C, sets up TELNET connections with both
server-PI's. He then sends A's fixed sockets, S(A), to B in a SOCK
command and B's to A; replies are returned. One of the servers, say
A, is then sent a PASV command telling him to "listen" on his data
sockets rather than initiate an RFCwhen he receives a transfer
service command. When the user-PI receives an acknowledgment to the
PASV command, he may send (in either order) the corresponding service
commands to A and B. Server B initiates the RFCand the transfer
proceeds. The command-reply sequence is listed below where the
messages are vertically synchronous but horizontally asynchronous:
User-PI - Server A User-PI - Server B
------------------ ------------------
C->A : ICP C->B : ICP
C->A : SOCK HOST-B, SKT-S(B) C->B : SOCK HOST-A, SKT-S(A)
A->C : 200 Okay B->C : 200 Okay
C->A : PASV
A->C : 200 Okay
C->A : STOR C->B : RETR
The data connection shall be closed by the server under the
conditions described in the Section on Establishing Data Connections.
If the server wishes to close the connection after a transfer where
it is not required, he should do so immediately after the file
transfer is completed. He should not wait until after a new transfer
command is received because the user-process will have already tested
the data connection to see if it needs to do a "listen"; (recall that
the user must "listen" on a closed data socket BEFORE sending the
transfer request). To prevent a race condition here, the server
sends a secondary reply (257) after closing the data connection (or
if the connection is left open, a "file transfer completed" reply
(252) and the user-PI should wait for one of these replies before
issuing a new transfer command.
COMMANDS
The commands are TELNET character string transmitted over the TELNET
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.
34
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
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:
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, Linefeed)
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.
The following are all the currently defined FTP commmands:
USER <SP> <username> <CRLF>
PASS <SP> <password> <CRLF>
ACCT <SP> <acctno> <CRLF>
REIN <CRLF>
BYE <CRLF>
BYTE <SP> <byte size> <CRLF>
SOCK <SP> <Host-socket> <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>
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>
LIST [<SP> <pathname>] <CRLF>
NLST [<SP> <pathname>] <CRLF>
SITE <SP> <string> <CRLF>
STAT [<SP> <pathname>] <CRLF>
HELP [<SP> <string>] <CRLF>
35
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
NOOP <CRLF>
The syntax of the above argument fields (using BNF notation where
applicable ) is:
<username> ::= <string>
<password> ::= <string>
<acctno> ::= <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> ::= any ASCII code 33. through 126., printable
characters
<byte size> ::= any decimal integer 1 through 255
<Host-socket> ::= <socket>|<Host number>, <socket>
<Host-number> ::= a decimal integer specifying an ARPANET Host.
<socket> ::= decimal integer between 0 and (2**32)-1
<form code> ::= N|T|C
<type code> ::= A[<SP> <form code>]|E [SP> <form code>]|I|
L <SP> <byte size>
<structure code> ::= F|R
<mode code> ::= S|B|C
<pathname> ::= <string>
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.
The third class of replies are informational and spontaneous replies
which may arrive at any time. The user-PI should be prepared to
receive them. These replies are listed below as sponteneous.
One important group of spontaneous replies is the connection
greetings. Under normal circumstances, a server will send a 300
reply, "awaiting input", when the ICP is completed. The user should
wait for this greeting message before sending any commands. If the
server is unable to accept input right away, he should send a 000
"announcing FTP" or a 020 "expected delay" reply immediately and a
36
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
300 reply when ready. The user will then know not to hang up if
there is a delay.
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 CORRESPONDENCE TABLE
COMMAND SUCCESS FAILURE
USER 230,330 430-432,500-505,507
PASS 230,330 430-432,500-507
ACCT 230 430-432,500-507
REIN 232,233 401,436,500-507
Secondary Reply 300
BYE 231,232 500-505,507
BYTE 200,331 402,500-505,507
SOCK 200,331 500-505,507
PASV 200,331 500-507
TYPE 200,331 402,500-505,507
STRU 200,331 500-505,507
MODE 200,331 402,500-505,507
RETR 250 402,433,450,451,454,455,457,
500-505,507,550
Secondary Reply 252,257 452
STOR 250 402,433,451,454,455,457,
500-505,507,550
Secondary Reply 252,257 452,453
APPE 250 402,433,451,454,455,457,500-507,
550
Secondary Reply 252,257 452,453
ALLO 200,331 402,500-507
REST 200,331 500-507
RNFR 200 402,433,450,451,455,500-507,550
RNTO 253 402,433,450,451,455,456,500-507,
550
ABOR 201,202,331 500-507
DELE 254 402,433,450,451,455,500-507,550
LIST 250 402,433,450,451,454,455,457,
500-507,550
Secondary Reply 252,257 452
NLST 250 402,433,450,451,454,455,457,
500-507,550
Secondary Reply 252,257 452
SITE 200,331 402,500-507
37
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
STAT 100,110, 450,451,455,500-507,550
150,151,331
HELP 030,050 500-507
NOOP 200 500-505,507
Spontaneous Replies 000,010,020, 400,401,434-436
300,301,251,255
TYPICAL FTP SCENARIOS
TIP User wanting to transfer file from Host X to local printer:
1. TIP user opens TELNET connections by ICP to Host X socket 3.
2. The following commands and replies are exchanged:
TIP HOST X
<---------- 300 Awaiting input <CRLF>
USER username <CRLF> ---------->
<---------- 330 Enter Password <CRLF>
PASS password <CRLF> ---------->
<---------- 230 User logged in <CRLF>
SOCK 65538 <CRLF> ---------->
<---------- 200 Commmand received OK<CRLF>
RETR this.file <CRLF> ---------->
(Host X initiates data connection to TIP socket 65538,
i.e., PORT 1 receive)
<---------- 250 File transfer started <CRLF>
<---------- 252 File transfer completed <CRLF>
BYE<CRLF> ---------->
<---------- 231 User logged out <CRLF>
3. Host X closes the TELNET and data connections.
Note: The TIP user should be in line mode.
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.
38
File Transfer Protocol
(Aug. 12, 1973)
RFC542 NIC 17759
LOCAL COMMANDS BY USER ACTION INVOLVED
ftp (host) multics<CR> ICP to Host S, socket 3,
establishing TELNET connections
<---- 330 Awaiting input <CRLF>
username Doe <CR> USER Doe<CRLF>---->
<---- 330 password<CRLF>
password mumble <CR> PASS mumble<CRLF>---->
<---- 230 Doe logged in.<CRLF>
retrieve (local type) ASCII<CR>
(local pathname) test 1 <CR> User-FTP opens local file in ASCII.
(for.pathname) testp11<CR> RETR test.p11<CRLF> ---->
Server makes data connection to
(U+4)
<---- 250 File transfer starts
<CRLF>
<---- 252 File transfer
complete<CRLF>
type Image<CR> TYPE I<CRLF> ---->
<---- 200 Command OK<CRLF>
byte 36<CR> BYTE 36<CR>LF ---->
<---- 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> ---->
<---- 451 Access denied<CRLF>
terminate BYE <CRLF> ---->
Server closes all connections.