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.

1. Error.

	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)

1. BBS Out to Lunch

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.

1. <machine name> invalid user-id, try again

	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.

1. <machine-name> wrong password, try again.

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>

1. <machine-name> directory does not exist.

KILL <file-spec>

	This will delete the file from the remote system.
	+<machine-name> <file-spec> deleted.

1. <machine-name> not deleted because <reason>

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

1. <machine-name> cannot find <old-file-spec>

	If you receive a ‘+’ response, you then send:

	TOBE <new-file-spec>

	+<machine-name> <old-file-spec> renamed <new-file-spec>

1. <machine-name> file was not renamed because <reason>

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>

1. <machine-name> invalid filename specified.

	or

1. <machine-name> file does not exist.

	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.

1. <machine-name> system running low on free space

1. <machine-name> invalid filename specified

	If appending:

	+<machine-name> will append to <file-spec>

1. <machine-name> file does not exist

	If you receive a ‘+’ response, you then send:

	SIZE <number-of-bytes-that-will-be-sent>

	Valid replies are:

	+<machine-name> OK

1. <machine-name> CANCEL

	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.