...

Digital copies of the latest revision of this document may be obtained through Prospero as SPMquot/papers/subjects/operating-systems/prospero/doc/protocol.PS.Z", in the #/INET/EDU/ISI/swa virtual system, or through Anonymous FTP from PROSPERO.ISI.EDU as SPMquot/pub/prospero/doc/prospero-protocol.PS.Z"

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...

This work was supported in part by the National Science Foundation (Grant No. CCR-8619663), the Washington Technology Center, Digital Equipment Corporation, and the Defense Advance Research Projects Agency under NASA Cooperative Agreement NCC-2-539. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of any of the funding agencies. The authors may be reached at USC/ISI, 4676 Admiralty Way, Marina del Rey, California 90292-6695, USA. Telephone +1 (310) 822-1511, email SPMquotinfo-prospero@isi.edu".
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...strings.
If you wish to send binary data around, we recommend that you encode it into a null-less form using the pfs library's binencode() and bindecode() routines.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...IDs.
XXX FUTURE DIRECTIONS: This is a specialized topic, since we have not done much implementation work on the ID field, pending greater consensus in the field. This section will go into the user's manual when we revise it: The user-level names for two links distinguished only by their ID fields are:

(name-component##4#4#5#5#6#6...##7#7#8#8#9#9...
or 1#1name-component2#2#10#10#1#1id-value-token11#112#2...)

The second form matches any 1#1id-type2#2. The first form is used to explicitly specify one or more 1#1id-type2#2s.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...queries.
The 1#1id-value2#2 of the REMOTE type is the same as the 1#1magic-no2#2 token specified in version 1 of the Prospero protocol.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...message.
Software developers wishing to obtain software identifiers should send electronic mail to pfs-administrator@isi.edu.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...HANDLE.
XXX HANDLE actually not yet implemented.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...client.
XXX: Not currently implemented.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...listed).
The protocol is currently in transition. The old format was as follows: Multiple component names are allowed, and are specified as a single token following the 1#1name-component2#2. The multiple components within a single name are separated by the unquoted slash (/). Currently distributed Servers and clients accept both versions of the protocol message, which means that the 1st component of a multiple-component name must be quoted if it contains a slash. If a space, tab, slash, or 1#1LF2#2 was to be included in a component of a single-component or multi-component name, the component must be quoted. Quoting a slash in a single-component or multi-component name meant that the slash is not considered to separate components of a multi-component name, but rather to be a part of a single component. This awkward syntax allowed us to have single components which contain slashes or horizontal whitespace or 1#1LF2#2s.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...implied.
This restriction seems odd, but it makes certain details of programming the client libraries much easier.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...suffix.
XXX review this; may not be accurate -swa.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...attribute
For an explanation, see section gif.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...size=-1>METHOD
See section gif for a description of the ACCESS-METHOD field.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...

CHANGE IN FORMAT: It used to be the case that the line returned for FIELD attributes did not include an 1#1attribute-type2#2 token. This has been changed. The older format will continue to work until all Prospero applications before Alpha.5.1 are gone.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...format.
Please note again that ID fields have not been fully implemented, in the absence of an appropriate standard; comments about them in this document are subject to change.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...FILTER.
XXX: This should go into the attribute documentation

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...server.
The security issues with loadable filters have not yet been fully addressed. Partly because of this, right now, all implementations except for the VAX implementation will only support PREDEFINED filters, and even the VAX implementation is not configured to support loadable filters unless you specially compile it to do so.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...command.
Versions of Prospero Alpha.5.2 and earlier required a preceding DIRECTORY command, not the OBJECT command.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...OBJECT).
XXX This used to be in one of two formats; older versions of Prospero (through Alpha.5.2) distinguished directories from objects. The old format will be used by some older clients, although we do not intend to support it in Alpha.5.3 and later servers. Therefore, if you plan to do Prospero development, please get the Alpha.5.3 version or later. The old way of retrieving information about a directory's ACL was to specify the option = DIRECTORY, exactly as one currently specifies the OBJECT option. The old way of retrieving information about an OBJECT's ACL was to specify the OBJECT option in the options field and replace the 1#1name-component2#2 field above with 1#1hsoname-type2#2 1#1hsoname2#2 12#12object-version13#13.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...ACL.
Named ACLs were implemented after the Prospero Alpha.5.2 release.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...ACLs:
CHANGE: In previous revisions of this Protocol manual, we distinguished NAMED ACLs from INCLUDED ACLs. This distinction no longer exists, and INCLUDED ACL retrieval was never implementd.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...HREF="footnode.html#1432">gif
XXX I have commented out information on the DIRECTORY NAMED/INCLUDED ACL. Destroy this message when it's clearly gone. -swa, 11/25/94
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...directory.
If you really want to shoot yourself in the foot, you can then call EDIT-ACL to remove these few rights. We will let you do this, but we are not making it easy for you.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...implemented.)
XXX: This feature must be specified. In addition, we must specify methods for refreshing links, garbage collection, and notification of the impending demise of objects.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...update.
This error message may change in response to future needs.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...SERVER-FAILED
This is used in the following situations, among others: if an internal table in the server fills up, or if the server cannot allocate enough memory to handle the request, or if the server detects an internal inconsistency in its database, or if the server has not implemented a command specified in the protocol.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...names.
This is not yet fully implemented.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...preference.
XXX Unspecified: (1) what happens if an attribute is created with the + suffix and then requested with the - suffix? (2) Or do we only specify the suffix at creation time? (3) Also, are the suffices returned during normal attribute listings? If so, does that mean that clients will not be able to use strict string comparison to retrieve desired attributes (that they'll have to trim off the + or -?)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...

RATIONALE: Under the version 1 protocol, the means of obtaining the access method information for EXTERNAL and FILE links was different; this made the code more complicated than it needed to be.

The reader may well ask why the host should be specified in the value of the ACCESS-METHOD field. Isn't the host name already specified in the HOST field? Including the host name as part of the attribute's value has some advantages:

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...1'
This file recently disappeared from the server. If you have a copy, please send it to SPMquotswa@isi.edu".
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...1' 1
This file recently disappeared from the server. If you have a copy, please send it to SPMquotswa@isi.edu".
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...system
Despite this, well known names from agreed upon starting points might be entered as application-defined attributes for objects.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...location.
To place a forwarding pointer, set the old object's FORWARDING-POINTER atribute. It must be manually moved to the new server at this time.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...sorting.
In the current implmentation, the only sort keys that may be specified must have an 1#1attribute-type2#2 of ASCII.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...visible.
Implementation detail (being phased out): Two types of links which may appear locally (either in the server, or on the client) are [-] deleted, and [N] native. It is not legal for these codes to be sent across the network. Type [N] links are converted to [L] and type [-] are skipped entirely.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...
Hidden/Not-Hidden/Externally-Hidden
Not yet implemented
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...format.
Implementers should use the asntotime() function in the pfs library in order to convert an ASN-TIME string into a UNIX timestamp, and the timetoasn() function to perform the reverse conversion. Applications writers are encouraged to use ASN-TIME format to represent all timestamps sent across the network.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...0.
The length of the total packet, including data, is available via the UDP layer, as are the port and IP address of the sending host.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...

You might think that the recipient needs to worry about the IP address of the FORWARD message it sends to the original client being different from that of the original server (the sender of this message). However, this is not the case. The existence of multi-homed hosts means that the sender of a message cannot assume that the IP address of a reply (as recorded in the UDP packet encapsulating the response it receives) is the same as the address the packet was sent to. The sender must use the connection ID to match up sent messages and received replies.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...octets.
The entire 255 octets are not available for address information, since they are part of the header, and the maximum header length header is limited to 64 octets.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Padma Indraganti
Thu Jun 20 13:02:20 PDT 1996