From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc520.txt | 451 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc520.txt (limited to 'doc/rfc/rfc520.txt') diff --git a/doc/rfc/rfc520.txt b/doc/rfc/rfc520.txt new file mode 100644 index 0000000..d79deaf --- /dev/null +++ b/doc/rfc/rfc520.txt @@ -0,0 +1,451 @@ + + + + + + +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 + + This command instructs the server to "open" the file 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 + + 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 + : 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: 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 + + 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 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: 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: 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 + + 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 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: 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 CRLF + CLOS CRLF + SETP CRLF + GETP CRLF + READ CRLF + WRIT CRLF + + ::= R|W|B + + ::= B|E| + + ::=ALL| + + ::= + + + + + + + + +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: + 481 EOF: + 482 File not open for operation + 483 FP: + 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] + -- cgit v1.2.3