File Access Protocol requirements
---------------------------------

Obvious requirements: the FAP should allow users to create, name, open, read,
write and delete files, and set and enquire their other attributes (protection,
datestamp, etc).  For the convenience of clients and servers, the FAP should
use a fixed format as much as is possible, with fields aligned on "natural"
boundaries.

It is preferable that clients and servers should be able to communicate with
each other without having to know about each other's ideas on filing systems.
To this end we define a canonical form for file names, requiring that clients
convert their own peculiar forms to the canonical form, with servers converting
from canonical form to their own peculiar forms.  The canonical form is a list
of (zero or more) filename components, split apart by the client at the points
indicated by the user's use of the client's metacharacters, the user being
assumed to know how such a breakdown should be performed.

In order that filename components do not require the use of any metacharacters
(e.g. a NUL terminator), we use a length prefix to indicate the size of each
component.  To be decided: length byte or length word (or an option).

Authority is demonstrated by presenting an appropriate token: in the case of
an open file, where the server already has some context in which to process the
request, the token is the one supplied by the server at the time the file was
opened; while in all other cases the token will have been supplied by some
identity server.  The server should have no reason to reject its own validly-
issued tokens, but it is at liberty to reject identity tokens or apply a
restrictive set of access rights if it decides that it does not trust the
identity server, if the identity server is unable to validate the token when
the file server presents it, or if the identity of the user turns out to be
someone unknown.  The intention is that tokens should be universally valid,
hence must be chosen from a sufficiently large space that they are hard to
forge (48 bits?).  It is the server's prerogative to blacklist a user or
client system.  Note that although a file server must trust the identity
servers it need not trust its clients; indeed, this is a basic requirement
of the protocol.

FAP operations take the form of a request from the client to the server,
followed by one or more responses from the server to the client.  Clients may
issue a number of requests without waiting for responses, subject to overall
flow-control constraints.  To this end each request has a client-generated tag
field which the server merely echoes with its responses.  It is the prerogative
of the server to interpret client requests in whichever order it chooses, and
to send replies to those requests in whichever order it chooses: clients must
not assume that requests will be serviced in the order they were issued, nor
that multiple responses will necessarily be returned in the "obvious" order.
If a client intends that operation A is performed before operation B it must
wait for A to complete before requesting B.

The basic operations supported are: access file, data transfer, deaccess file,
modify attributes, create directory, delete file(/directory/redirector), rename
file(), define redirector.
