Browse Prior Art Database

Memo to FTP group: Proposal for File Access Protocol (RFC0520) Disclosure Number: IPCOM000005081D
Original Publication Date: 1973-Jun-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 8 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People


Related Documents

10.17487/RFC0520: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 22% of the total text.

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:


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



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 nece...