As per Relevance of the word september, we have this rfc below:
Network Working Group Mark K.
Request for Comments: 913
September 1984
Simple File Transfer
STATUS OF THIS
This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
SFTP is a simple file transfer protocol. It fills the need of
wanting a protocol that is more useful than TFTP but easier
implement (and less powerful) than FTP. SFTP supports user
control, file transfers, directory listing, directory changing,
renaming and deleting
SFTP can be implemented with any reliable 8-bit byte stream
protocol, this document describes its TCP specification. SFTP
only one TCP connection; whereas TFTP implements a connection
UDP, and FTP uses two TCP connections (one using the
protocol).
THE
SFTP is used by opening a TCP connection to the remote hosts'
port (115 decimal). You then send SFTP commands and wait
replies. SFTP commands sent to the remote server are always 4
letters (of any case) followed by a space, the argument(s), and
. The argument can sometimes be null in which case the
is just 4 characters followed by . Replies from the server
always a response character followed immediately by an ASCII
string terminated by a . A reply can also be just a
character and a .
: = [ ]
: = USER ! ACCT ! PASS ! TYPE ! LIST !
KILL ! NAME ! DONE ! RETR !
<response> : = <response-code> []
<response-code> : = + | - | | !
can contain
Commands that can be sent to the server are listed below. The
Lottor [Page 1]
RFC 913 September 1984
Simple File Transfer
replies to each command with one of the possible response
listed under each message. Along with the response, the
should optionally return a message explaining the error in
detail. Example message texts are listed but do not have to
followed. All characters used in messages are ASCII 7-bit with
high-order bit zero, in an 8 bit field
The response codes and their meanings
+ Success
- Error
An error occurred while processing your command
Number
The number-sign is followed immediately by ASCII
representing a decimal number
! Logged in
You have sent enough information to be able to log yourself in
This is also used to mean you have sent enough information
connect to a directory
To use SFTP you first open a connection to the remote SFTP server
The server replies by sending either a positive or negative greeting
such as
+MIT-XX SFTP
(the first word should be the host name
-MIT-XX Out to
Lottor [Page 2]
RFC 913 September 1984
Simple File Transfer
If the server send back a '-' response it will also close
connection, otherwise you must now send a USER command
USER user-
Your userid on the remote system
The reply to this command will be one of
! logged
Meaning you don't need an account or password or
specified a user-id not needing them
+User-id valid, send account and
-Invalid user-id, try
If the remote system does not have user-id's then you
send an identification such as your personal name or host
as the argument, and the remote system would reply with '+'.
ACCT
The account you want to use (usually used for billing) on
remote system
Valid replies are
! Account valid, logged-
Account was ok or not needed. Skip the password
+Account valid, send
Account ok or not needed. Send your password next
-Invalid account, try
Lottor [Page 3]
RFC 913 September 1984
Simple File Transfer
PASS
Your password on the remote system
Valid replies are
! Logged
Password is ok and you can begin file transfers
+Send
Password ok but you haven't specified the account
-Wrong password, try
Lottor [Page 4]
RFC 913 September 1984
Simple File Transfer
You cannot specify any of the following commands until you receive
'!' response from the remote system
TYPE { A | B | C }
The mapping of the stored file to the transmission byte
is controlled by the type. The default is binary if the
is not specified
A -
The ASCII bytes are taken from the file in the
system, transmitted over the connection, and stored in
file in the destination system
The data is the 7-bit ASCII codes, transmitted in
low-order 7 bits of 8-bit bytes. The high-order bit of
transmission byte must be zero, and need not be stored
the file
The data is "NETASCII" and is to follow the same rules
data sent on Telnet connections. The key requirement
is that the local end of line is to be converted to the
of ASCII characters CR and LF when transmitted on
connection
For example, TOPS-20 machines have 36-bit words. On TOPS-20
machines, The standard way of labeling the bits is 0
35 from high-order to low-order. On TOPS-20 the normal
of storing ASCII data is to use 5 7-bit bytes per word.
ASCII mode, the bytes transmitted would be [0-6], [7-13],
[14-20], [21-27], [28-34], (bit 35 would not
transmitted), each of these 7-bit quantities would
transmitted as the low-order 7 bits of an 8-bit byte (
the high-order bit zero).
For example, one disk page of a TOPS-20 file is 512 36-
words. But using only 35 bits per word for 7-bit bytes,
page is 17920 bits or 2560 bytes
Lottor [Page 5]
RFC 913 September 1984
Simple File Transfer
B -
The 8-bit bytes are taken from the file in the
system, transmitted over the connection, and stored in
file in the destination system
The data is in 8-bit units. In systems with word
which are not a multiple of 8, some bits of the word
not be transmitted
For example, TOPS-20 machines have 36-bit words. In
mode, the bytes transmitted would be [0-7], [8-15], [16-23],
[24-31], (bits 32-35 would not be transmitted).
For example, one disk page of a TOPS-20 file is 512 36-
words. But using only 32 bits per word for 8-bit bytes,
page is 16384 bits or 2048 bytes
C -
The bits are taken from the file in the source
continuously, ignoring word boundaries, and sent over
connection packed into 8-bit bytes. The destination
stores the bits received into the file continuously
ignoring word boundaries
For systems on machines with a word size that is a
of 8 bits, the implementation of binary and continuous
should be identical
For example, TOPS-20 machines have 36-bit words.
continuous mode, the bytes transmitted would be [first word
bits 0-7], [first word, bits 8-15], [first word,
16-23], [first word, bits 24-31], [first word, bits 32-35 +
second word, bits 0-3], [second word, bits 4-11], [
word, bits 12-19], [second word, bits 20-27], [second word
bits 28-35], then the pattern repeats
For example, one disk page of a TOPS-20 file is 512 36-
words. This is 18432 bits or 2304 8-bit bytes
Replies are
+Using { Ascii | Binary | Continuous }
-Type not
Lottor [Page 6]
RFC 913 September 1984
Simple File Transfer
LIST { F | V } directory-
A null directory-path will return the current
directory listing
F specifies a standard formatted directory listing
An error reply should be a '-' followed by the error
from the remote systems directory command. A
listing is a '+' followed immediately by the
directory path specification and a . Following
directory path is a single line for each file in
directory. Each line is just the file name followed
. The listing is terminated with a after
last .
V specifies a verbose directory listing
An error returns '-' as above. A verbose directory
is a '+' followed immediately by the current directory
specification and a . It is then followed by one
per file in the directory (a line ending in ).
line returned for each file can be of any format.
information to return would be the file name, size
protection, last write date, and name of last writer
Lottor [Page 7]
RFC 913 September 1984
Simple File Transfer
CDIR new-
This will change the current working directory on the
host to the argument passed
Replies are
!Changed working dir to directory
-Can't connect to directory because: (reason
+directory ok, send account/
If the server replies with '+' you should then send an ACCT
PASS command. The server will wait for ACCT or PASS
until it returns a '-' or '!' response
Replies to ACCT could be
!Changed working dir to directory
+account ok, send
-invalid
Replies to PASS could be
!Changed working dir to directory
+password ok, send
-invalid
KILL file-
This will delete the file from the remote system
Replies are
+
-Not deleted because (reason
Lottor [Page 8]
RFC 913 September 1984
Simple File Transfer
NAME old-file-
Renames the old-file-spec to be new-file-spec on the
system
Replies
+File
-Can't find
NAME command is aborted, don't send TOBE
If you receive a '+' you then send
TOBE new-file-
The server replies with
+ renamed to
-File wasn't renamed because (reason
Tells the remote system you are done
The remote system replies
+(the message may be charge/accounting info
and then both systems close the connection
Lottor [Page 9]
RFC 913 September 1984
Simple File Transfer
RETR file-
Requests that the remote system send the specified file
Receiving a '-' from the server should abort the RETR
and the server will wait for another command
The reply from the remote system is
(as ascii digits
-File doesn't
You then reply to the remote system with
SEND (ok, waiting for file
The file is then sent as a stream of exactly the
of 8-bit bytes specified. When all bytes are
control passes back to you (the remote system is
for the next command). If you don't receive a
within a reasonable amount of time you should abort
file transfer by closing the connection
STOP (You don't have enough space to store file
Replies could be
+ok, RETR
You are then ready to send another command to the remote host
Lottor [Page 10]
RFC 913 September 1984
Simple File Transfer
STOR { NEW | OLD | APP } file-
Tells the remote system to receive the following file and
it under that name
Receiving a '-' should abort the STOR command sequence and
server should wait for the next command
NEW specifies it should create a new generation of the file
not delete the existing one
Replies could be
+File exists, will create new generation of
+File does not exist, will create new
-File exists, but system doesn't support
OLD specifies it should write over the existing file, if any
or else create a new file with the specified name
Replies could be
+Will write over old
+Will create new
(OLD should always return a '+')
APP specifies that what you send should be appended to the
on the remote site. If the file doesn't exist it will
created
Replies could be
+Will append to
+Will create
(APP should always return a '+')
Lottor [Page 11]
RFC 913 September 1984
Simple File Transfer
You then send
SIZE (as ASCII digits
where number-of-bytes-in-
is the exact number of 8-bit bytes you will
sending
The remote system replies
+ok, waiting for
You then send the file as exactly the number of
specified above
When you are done the remote system should reply
+Saved
-Couldn't save because (reason
-Not enough room, don't send
This aborts the STOR sequence, the server is waiting
your next command
You are then ready to send another command to the remote host
Lottor [Page 12]
RFC 913 September 1984
Simple File Transfer
AN
An example file transfer. 'S' is the sender, the user process. 'R
is the reply from the remote server. Remember all server replies
terminated with . If the reply is more than one line each
ends with a .
R: (listening for connection
S: (opens connection to R
R: +MIT-XX SFTP
S: USER
R: +MKL ok, send
S: PASS
R: ! MKL logged
S: LIST F PS:
R: +PS:
Small.
Large.
S: LIST
R: +PS:
Small.File 1 69(7) P775240 2-Aug-84 20:08
Large.File 100 255999(8) P770000 9-Dec-84 06:04
S: RETR SMALL.
R: 69
S:
R: This is a small file, the file is sent
a terminating null
S:
R: +MIT-XX closing
Lottor [Page 13]
RFC 913 September 1984
Simple File Transfer
EDITORS
Mark Lotter receives full credit for all the good ideas in this memo
As RFC editor, i have made an number of format changes, a few
changes, and one or two technical changes (mostly in the TYPEs).
accept full responsibility for any flaws i may have introduced
A draft form of this memo was circulated for comments. I
attempt to list the issues raised and summarize the pros and cons
and resolution for each
ASCII Commands vs Binary Operation
The ASCII command style is easier to debug, the
programming cost in minimal, the extra transmission cost
trivial
Binary operation codes are more efficient, and a few days
debugging should not out weigh years of use
Resolution: I have kept the ASCII Commands
Additional
Pro: For some machines you can't send all the bits in a
using this protocol. There should be some additional mode
allow it
Con: Forget it, this is supposed to be SIMPLE file transfer
If you need those complex modes use real FTP
Resolution: I have added the Continuous mode
Lottor [Page 14]
RFC 913 September 1984
Simple File Transfer
CRLF
Pro: In ASCII type, convert the local end of line indicator
CRLF on the way out of the host and onto the network
Con: If you require that you have to look at the bytes as
send them, otherwise you can just send them. Most of the
both sides will have the same end of line convention anyway
If someone needs a conversion it can be done with a TECO
separately
Resolution: I have required CRLF conversion in ASCII type.
you have the same kind of machines and the same end of
convention you can avoid the extra cost of conversion by
the binary or continuous type
TCP
Pro: Use TCP Urgent to abort a transfer, instead of
the connection. Then one could retry the file, or try
different file without having to login again
Con: That would couple SFTP to TCP too much. SFTP is
to be able to be work over any reliable 8-bit data stream
Resolution: I have not made use of TCP Urgent
Random
Pro: Wouldn't it be nice if (WIBNIF) SFTP had a way
accessing parts of a file
Con: Forget it, this is supposed to be SIMPLE file transfer
If you need random access use real FTP (oops, real FTP doesn'
have random access either -- invent another protocol?).
Resolution: I have not made any provision for Random Access
-- jon postel
Lottor [Page 15]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
