Remote MT Protocol

		Peter Eriksson <pen@lysator.liu.se>

			   16 Aug 1993


Status of this Memo
   
   This document attempts to define a protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited. 

1. INTRODUCTION

   The Remote MT Protocol (a.k.a., "rmt", a.k.a., the "RMT Protocol")
   provides a means for users to access remote tape devices without
   requiring them to login on the remote machine.

   The protocol described in this document is the same as used by the
   "rmt" Unix program, with the addition of a well known port to which
   remote users can connect to get RMT service. Authentication of
   remote users is NOT handled by this protocol in this version.

2. OVERVIEW

   This is a connection based application on TCP. A server listens for
   TCP connections on TCP port 411 (decimal). Once a connection is
   established, the servers reads lines of data which specifies the
   commands for manipulation of the magnetic tapes, performs the
   commands and then responds with a status indication. All command
   and reply codes are in ASCII.

3. NOTATIONAL CONVENTIONS

   In the protocol description that follows below the following
   notational conventions are used:

   	<....>		Denotes a field of information.

   	[....]		Denotes that what is contained within the
   			brackets is optional and may or may not be
   			present.

   	\n		Denotes an ASCII LineFeed (LF, code 10 (decimal))
   			character.
   
4. QUERY/RESPONSE FORMAT
   
   The server accepts simple one-letter ASCII commands (with
   optional arguments) of the form:

   	<command-letter>[<opt-arg1>\n[<opt-arg2>\n][<opt-data]]

   where <opt-arg1> and <opt-arg2> are ASCII decimal number, and
   <opt-data> is a sequence of bytes. If an unknown <command-letter>
   is received the server will drop the connection without returning
   an error reply. Some examples:

   	O/dev/rmt8\n0\n
   	L100\n1\n
   	R5\n

   All responses are in ASCII and in one of two forms. Successful
   commands have responses of:

   	A<retval>\n[<opt-data>]

   where <retval> is the ASCII representation of a decimal number,
   and [<opt-data>] may or may not be present, depending on the
   command this is a reply to. For example:

   	A5\nHELLO
   	A3\n
   
   Unsuccessful commands are responded to with:

   	E<error-number>\n<error-message>\n

   where <error-number> is a system dependant error number, 
   and <error-message> is a corresponding ASCII error message
   string. For example:

   	E2\nNo such file or directory\n
   	E6\nNo such device or address\n


   The protocol consists of the following commands:

   	O<pathname>\n<mode>\n
   			Open the specified <pathname>. The <mode>
   			is an ASCII decimal value specifying the 
			mode for opening it. It can be one of:

   				0	Read-Only
   				1	Write-Only
   				2	Read-and-Write

   
   	C<pathname>\n
   			Close the currently open device. The
   			<pathname> argument is required, but
   			currently ignored. Client implementations
			should use the same pathname as they
   			used in the "O" command.
   	

   	L<offset>\n<whence>\n
   			Perform a seek on the currently open
   			device, if the device supports random
   			access. The <offset> argument is a
   			ASCII decimal number, whose meaning depends
   			on the <whence> argument. <whence> can be
   			one of the following:

   				0	Seek <offset> bytes from
   				    	the beginning of the file open
   				    	on the device.

   				1 	Seek <offset> bytes relative
   				    	the current position.

   				2	Seek <offset> bytes relative
   				    	the end of the current file
   				    	open.

   			On a successful operation, the <retval> returned
   			is the new position.

   
   	W<count>\n<data>
   			Write <count> bytes to the currently open
   			device. The bytes of <data> to be written
   			are sent immediately after the newline (\n)
   			of this command. On a successful write,
   			the <retval> returned is the actual number
   			of bytes written.


   	R<count>\n
   			Read up to <count> bytes of data from the
   			currently open device. If the read is successful,
   			the <retval> is the number of bytes read and
   			[<opt-data>] is the actual data read.


  	I<operation>\n<count>\n
   			Perform a device control operation on the
   			currently open device. <operation> can be
   			one of:

   				0	Write <count> EOF marks.

   				1	Forward space over <count>
   					EOF marks.

   				2	Space backwards over <count>
   					EOF marks.

   				3	Forward space over <count>
   					records.

   				4	Space backwards over <count>
   					records.

   				5	Rewind. <count> is ignored.

   				6	Rewind and place device offline.
   					<count> is ignored.

   
   	S\n		Return the status of the currently open device
			On a successful operation, <retval> will contain
   			the size of the system dependant binary structure
   			returned in [<opt-data>].
   
5. SECURITY CONSIDERATIONS

   This protocol contains no provisions what so ever with regard to
   authenticating users using it. Currently all authentication will
   have to be done outside this protocol.

6. ACKNOWLEDGEMENTS

   Acknowledgement is given to Mike St. Johns, who's IDENT RFC I've
   used as a sort-of basis for this document.

   Acknowledgement is also given to W. Richard Stevens whose invaluable
   book 'Unix Network Programming' gave insight into the RMT protocol.

   Other sources for the information in this document is the 4.3BSD "rmt"
   program sources and manual pages.

Author's Address

	Peter Eriksson
	Lysator ACS, c/o ISY
	Universitetet
	S-581 83 Linköping
	Sweden

	EMail:	pen@lysator.liu.se