Last Updated: January 1st 2020
This document is loosely based upon Simple File Transport Protocol, RFC913
Author: G.E. Ozz Nixon Jr.
This is the initial draft suggesting a proposed protocol for the ARPA-Internet community, and requests discussion of suggestions for improvements. Distribution of this memo is unlimited.
LEGACY/X TRANSPORT is a modified simple file transfer protocol. It fills the new of people wants a protocol that is more useful than SFTP but easier to implement than BinkP. LEGACY/X TRANSPORT uses only one TCP connection; consisting of null terminated communications; whereas BinkP requires a little more complex syntax and a state oriented workflow.
LEGACY/X TRANSPORT is basically backward compatible with SFTP; so we use the same port (115 decimal). You then send commands and wait for replies. LEGACY/X TRANSPORT commands sent to the remote server are always 4 ASCII letters (of any case) followed by a space, the argument(s), and a <NULL>. The argument can sometimes be null in which case the command is just 4 characters followed by <NULL>. Replies from the server are always a response character followed immediately by an ASCII message string terminated by a <NULL>. The message string consists of the server machine name and optional text.
<command> : = <cmd> [<SPACE> <args>] <NULL>
<cmd> : = USER | ACCT | PASS | TYPE | LIST | CDIR | KILL | NAME | DONE | RETR | STOR | HELP
<response> : = <response-code> <message> <NULL>
<response-code> : = + | - | !
<message> may contain <CRLF>
Commands that can be sent to the server are listed below. The server replied to each command with one of the possible response codes list under each message. Along with the response, the server should optionally return a message explaining the error in more detail. Example message texts are listed but do not have to be followed. All characters used in messages are ASCII 7-bit with the high-order bit zero, in an 8 bit field.
The response codes and their meanings:
+ Success.
An error occurred while processing your command.
! Logged in.
You have sent enough information to be able to authenticate yourself.
To use LEGACY/X TRANSPORT you first open a connection to the remote LEGACY/X TRANSPORT server. The server replies by sending either a positive or negative greeting, such as:
+BBS SFTP Service
(the first word should always be the machine name)
Is the server sends back a ‘-‘ negative response it will also close the connection, otherwise you must now send a USER command.
USER user-id
Your user-id on the remote system.
The reply to this command will be one of:
!<user-id> logged in
Meaning you do not need to transmit a password. This is valid for FREQ sessions.
+<machine-name> <session-hash-string>
The session-hash-string is unique per connection to the remote server. For security purpose the string is changed for each connection to avoid replay session hacking. This string is used to encode your password, see PASS.
If the remote system does not have user-id’s then you should send an identification such as your personal name as the argument, and the remote system would reply with ‘+’.
PASS sha1-hash
Your password on the remote system encoded.
To produce your sha1-hash, you use the <session-hash-string> from the USER command combined with the sha1 of your password, as follows:
sha1-hash := sha1(<session-hash-string>+sha1(<your password>));
example:
If sha1() of your password is: (sample is sha1(‘password’))
5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
and the remote server sent:
13D78885831EAAFBF0C4F1243A1E0686D04EC989 sha1-hash should be:
BD8E1775EF8DFCDEFD494EE686C4C90063283ED8
that is the sha1() of the remote server <session-hash-string>+sha1(‘password’).
Valid replies are:
!<machine-name> logged in.
You cannot specify any of the following commands until you receive a ‘!’ response from the remote system.
TYPE { A | B | C | U | X }
The default is binary if the type is not specified.
A - ASCII
B - BINARY (raw 8bit stream)
C - MIME/BASE64 Encoding
U - UUENCODE
X - XOR Encoding (new parameter is the decimal character number to use)
Valid replies are:
+<machine-name> Transfer Type <type-specified>
LIST <filename>
A null directory-path will return the current connect directory listing.
The directory listing uses the 2000+ directory standard for Windows.
If the listing is a directory:
mm/dd/yyyy
2 spaces
hh:mm
4 spaces
either <DIR> or 5 spaces
10 spaces
directory name + <CRLF> If the listing is a file:
mm/dd/yyyy
2 spaces
hh:mm
left padding, file size, 18 characters
1 space
file name + <CRLF>
Followed by a 2 line summary:
16 left padding, number of files displayed
1 space
‘File(s)’
15 left padding, total bytes of files displayed
1 space
‘bytes’ + <bytes>
16 left padding, number of files displayed
1 space
‘Dir(s)’
1 space
15 left padding, total bytes of files displayed
1 space
‘bytes free’ + <bytes>
CDIR <new-directory>
This will change the current working directory on the remote server to the argument passed.
+<machine-name> change to <new-directory>
KILL <file-spec>
This will delete the file from the remote system. +<machine-name> <file-spec> deleted.
NAME <old-file-spec>
Renames the <old-file-spec> to the <new-file-spec> on the remote server.
Valid replies are:
+<machine-name> File Exists
If you receive a ‘+’ response, you then send:
TOBE <new-file-spec>
+<machine-name> <old-file-spec> renamed <new-file-spec>
DONE
Tells the remote server you are finished.
Valid replies are:
+<machine-name> <second> seconds used.
The the remote server closes the connection.
RETR <file-spec>
Request that the remote server queue the specified file for transfer.
Valid replies are:
+<machine-name>+CRLF
<number-of-bytes-that-will-be-sent>
or
If you receive a ‘+’ response, you then send:
SEND
The file is then send as a stream of exact the number of bytes specified. When all bytes are civet control passes back to you (the remote server is waiting for the next command). If you do not receive a byte within reasonable amount of time you should abort the file transfer by closing the connection.
STOP
You would send this instead of SEND if you do not have enough space available.
Valid replies are:
+<machine-name> aborted
STOR { APP } { <file-spec> }
Tells the remote server to receive the file. If the <file-spec> is not specified, the remote server will automatically generate a unique file name. In the case of no <file-spec> the new file will be stored in the default INBOUND folder; this is applicable to MAIL solutions.
If the APP parameter is specified, the system will attempt to append to the existing filename if permissions allow.
Valid replies are:
+<machine-name> will create new file named <file-spec>
+<machine-name> will create new generation of file.
If appending:
+<machine-name> will append to <file-spec>
If you receive a ‘+’ response, you then send:
SIZE <number-of-bytes-that-will-be-sent>
Valid replies are:
+<machine-name> OK
If you receive a ‘+’ response, you send the stream.
EDITOR NOTES
Mark Lotter receives full create for the original protocol specification RFC-913. Legacy/X Transport is a deviation, providing a more secure technique for authentication over public Internet connections. Legacy/X Transport also introduces multiple encoding formats. As the author of this document and Legacy/X Transport, I have made a number of roman changes, a few wording changes, and a couple of technical changes.