Network Working Group J. Day
Request for Comments: 520 Center for Advanced Computation
NIC: 16819 25 June 1973
A Proposed File Access Protocol Specification
Attached is a proposal for the File Access Protocol. FAP is an
extension to FTP. I believe the specification is fairly general and
should provide a good jumping-off place. I hope the protocol is
specified in such a way as to fit with idiosyncrasies of most
systems. If the protocol would cause an inordinate amount of burden
on your system for one reason or another I would like to hear about
it.
At some later date when the difficulties of implementation are better
known, I would like to see several levels of implementation specified
and implementation be done in terms of those levels.
From rumors I have heard I believe this will also allow creation and
transfer of what TENEX calls "holey" files. But, I am not sure of
all of the implications of that, or what would happen (or should
happen) when a "holey" file is moved to a site that doesn't really
have such a thing, per se. Comments from the TENEX crowd would be
appreciated.
I think some further work could be done to make FAP easier for record
oriented systems. This would probably require an extra command or
parameter to specify all operations are in terms of records.
Comments are invited.
In the long run though, I would like to see FAP thrown away. The
commands as they are described merely add a finer structure to the
present RETR, STOR, and APPE without much additional overhead. The
sequence:
OPEN R FOO.BAR CRLF
READ ALL CRLF
CLOS CRLF
is equivalent to RETR FOO.BAR CRLF. FAP could be merged with FTP to
give a much richer, coherent whole.
In writing this document, I ran into the deficiency of reply codes
for protocols. Three digits is no where near enough. I would like
to suggest that as another interim solution we go to a five digit
Day [Page 1]
RFC 520 A Proposed File Access Protocol Specification 25 June 1973 reply with two for specific categories (such as Primary access, FTP results, etc.) and two for specific results. In the meantime, the NWG should begin considering a general scheme for reply codes -- one that doesn't need revising every two years. Comments, complaints, etc. are welcomed. I may be reached through network mail at ISI (DAY) or Multics (DAY Cnet) or by phone at the University of Illinois (217) 333-6544. A Proposed File Access Protocol Specification John Day 6/7/73 I. INTRODUCTION The purpose of the File Access Protocol is to provide a method for processes to access non-local files in either a sequential or non- sequential manner. Unlike the proposed Mail Protocol, FAP is an extension of FTP and not a subsystem. In general FAP is compatible with the rest of FTP. Those modifications which are necessary are specified below. The intent of this protocol is to allow processes to specify to the remote file system where in the file they wish the next operation to start and how much data to move. Thus only the part of a file necessary for a process' computation need be transferred, rather than the entire file. Thus transmission times and storage requirements may be held down. In short, the rationale for a File Access Protocol on the network is the same as the rationale for "random-accessed" files in a standard operating system. The file Access Protocol uses the connection model, data representations, and transmission methods of the File transfer Protocol. All data transmissions in FAP are handled according to the description in FTP Section III.C with the following modifications. In Stream mode, the minimum byte size is increased to 4 bits. Another control code (value 4) is used to indicate "end of transmission". An combination of EOT, EOR, or EOF may be indicated by the proper control code. With this method it is not necessary to close the connection after each access; a practice not highly recommended. In Block mode, bit 5 of the descriptor field of the header is set noting that this block is the end of transmission. In addition to this, FAP uses a File Pointer (FP). The file pointer Day [Page 2]
RFC 520 A Proposed File Access Protocol Specification 25 June 1973 points into the file and is the point at which the next FAP read or write will commence. The file pointer is a general mechanism for addressing a file and should be flexible enough to handle both stream and record oriented systems. II. PROBLEMS OF IMPLEMENTATION As usual, not all systems will be able to implement this protocol in its full generality. The approach that should be taken is that no host should be required to provide for network users (in the name of complete protocol implementation) service it does not provide its local users. Some systems allow "random" access to some kinds of files on its system and not to others. In this case, this should be their implementation, i.e., not all operations are valid for all kinds of files. Some systems cannot move the byte pointer backwards without opening and closing the file. They should not be required to do this (although they may if they wish), but they should allow "spacing" down a file some distance before starting a transfer. Some systems may not allow read and write access to be available without closing and reopening the file. Systems should not be required to do both. In general, the rules of implementation are: 1) If a system normally allows that particular kind of access to that particular file then it should be allowed; if not, the system should not be forced to implement it. (In many cases, the legality cannot be known until the operation is attempted; i.e., it cannot be told of the first two cases above if they are legal when the file is opened but only on the read or write which violates the implementation restrictions). 2) A system should not try to simulate a facility if the simulation has side effects. For example, if simulating the capability of moving the byte pointer to the desired position has some side effects, then the simulation should be left to the process accessing the file. 3) All implementors should make known the capabilities of their implementations via NIC documents. Day [Page 3]
RFC 520 A Proposed File Access Protocol Specification 25 June 1973 III. FILE ACCESS PROTOCOL The FAP extension to FTP includes 6 new commands and the file pointer. Any implementation requires the file pointer and all six commands. But, as described above, it is not necessary to implement the commands in their full generality. III.1 THE FILE POINTER The file pointer represents an index or address within the file. The units by which the index is measured, is "logical byte size" and does not include any bytes related to transmission or structure. In particular, for transmission mode Stream and structure Record, the EOR and EOF markers are not counted. Local transformations on data must be taken into account. For example, Multics stores CRLF as NL. In this case, NL counts as two ASCII bytes since it was transmitted to or will be sent from Multics as CRLF. If transmission Mode is Image then the logical byte size is taken as the transmission byte size. There are two commands which operate on the file pointer: 1) SETP to move the pointer and 2) GETP to find out where it is at. These are described below in more detail. The file pointer may take on three classes of values. All may be mapped to some decimal number. The value B represents the beginning of the file (Byte 0). The value E represents the end of the file (or Byte n for a file n bytes long). The byte pointer may also take on any value between 0 and n. A file of n bytes .......... |----|----|----|----|-----------|----|----|----|----| ^ 1 2 3 4 n-4 n-3 n-2 n-1 ^ | | 0 n B E If a file is stored under set of parameters (TYPE, etc.) and operations are attempted on it under different parameters, the server does not guarantee that the information will be valid. III.2 COMMANDS III.2.1 OPEN <direction> <pathname> This command instructs the server to "open" the file <pathname> for access in the direction specified. The directions are read, R write, W; or both, B. A read direction implies that the data connection is Day [Page 4]
RFC 520 A Proposed File Access Protocol Specification 25 June 1973 from server to user; write, from user to server; and both implies connections each ways. Functionally, this command corresponds to RETR or STOR. Therefore, all the FTP parameter commands (TYPE, MODE, etc.) must be sent before the file is opened. If the direction is write (W) and the file specified by the pathname does not exist, there is an implied create with the open. The success of this create, is, of course, dependent on local access privileges and possibly whether or not an ALL command was sent. If applicable, the file created should be of the most general kind of file on which "random" access is allowed. (This is to allow the largest degree of compatibility with operations that may follow). This should be ignored if some site specific command has already specified the kind of file. This command identifies the file on which subsequent operations are to be performed. After the file is opened, the file pointer is at B and any of the other five FAP commands may be sent. It is acknowledged that some systems cannot open a file for access in both directions; an error reply 402 should be sent for this response. Replies ------- 258 451 500 504 550 402 454 501 505 434 455 502 506 4550 457 503 507 III.2.2 SETP <argument> This command causes the file pointer to be set to the number specified in the argument. This value will be the ordinal number of the starting position of the next operation. (Byte 0 is the first byte in the file). The argument may take on two other values besides <decimal number> : B, for BEGIN, which sets the file pointer at the beginning of a file (i.e. 0) and E, for END, which sets the file pointer to the last byte in the file. Two error conditions are possible. If the argument specifies an illegal change of file pointer (such as moving it backwards on some systems), then the error reply 402 should be sent. If the argument attempts to move the file pointer off the end of the file, then the EOF: <byte number> reply should be sent with the address of the end of the file (E), and the file pointer left at E. Replies ------- 258 402 480 Day [Page 5]
RFC 520 A Proposed File Access Protocol Specification 25 June 1973 III.2.3 GETP This command requests the server to return the value of the file pointer as a decimal number. Reply ----- 483 504 III.2.4 READ <arg> This command instructs the server to move as many bytes as specified (of size logical byte size) from the server to the user. The values the argument may take on are <decimal number> and ALL. ALL is interpreted as all data from the present position of the file pointer to the end-of-file. If a read requests more bytes than in the file, the number of bytes from the present position to the end of file should be transferred and an EOF: <byte number> response returned noting the position of the end of file. If the file is Record structured and a READ requests more bytes than in the record, then the number of bytes in the record from the file pointer are moved and the EOR: <byte number> reply is sent noting the end of record. The action of a READ leaves the file pointer at the position before the read plus the number of bytes moved, (i.e., updated). The EOF condition leaves it at E. Replies ------- 258 480 402 481 450 482 452 500-507 455 III.2.5 WRITe <arg> This command instructs the server to accept as many bytes as specified from the user. The result updates the value of the file pointer. The values the argument may take on are <decimal number> or ALL. ALL is interpreted as all data from the present position of the byte pointer to the end-of-file (or beyond). Associated with the write is an implied "append", if necessary previous information has been sent (such as allocation) and if the file's access privilege allow the append. If a write specifies more bytes than there are between the file pointer and the end-of-file, and expansion is not allowed, no data is sent and the file pointer is not moved. An error is returned specifying the byte position of the EOF. If the file is Day [Page 6]
RFC 520 A Proposed File Access Protocol Specification 25 June 1973 Record structured and a WRIT attempts to move more bytes than there are in the record, the file pointer is not moved and the EOR: <byte number> reply is sent noting the end of record. Replies ------- 258 480 402 481 450 482 452 500-507 453 III.2.6 CLOS This command instructs the server to "close" the presently open file, if any. The receipt of a CLOS without an open file is not an error. The effect is to notify the server that further operations are not directed at the file which is presently open. If an open is received by the server and it has a file open, it should close the open file and open the new one. Reply ----- 258 IV. SUMMARY IV.1 SYNTAX OPEN <direction> <pathname> CRLF CLOS CRLF SETP <byte pointer arg> CRLF GETP CRLF READ <transfer argument> CRLF WRIT <transfer argument> CRLF <direction>::= R|W|B <byte pointer argument>::= B|E|<decimal number> <transfer argument>::=ALL|<decimal number> <byte number>::= <decimal number> Day [Page 7]
RFC 520 A Proposed File Access Protocol Specification 25 June 1973
IV.2 REPLIES USED BY FAP
258 Operation successful
402 Command not implemented for requested value or action
433 Cannot transfer files w/o valid account. Enter account &
resend command.
450 FTP: file not found
451 FTP: file access denied
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.
457 FTP: transfer parameters in error.
480 EOR: <byte number>
481 EOF: <byte number>
482 File not open for operation
483 FP: <byte pointer>
500 Last command line completely unrecognized.
501 Syntax of last command is incorrect.
502 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).
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Via Genie ]
Day [Page 8]
mirror server hosted at Truenetwork, Russian Federation.