The ID field is a unique (or nearly unique) identifier for an object. If the underlying object changes (such as by editing), then some types of IDs will change and others will not. If two objects have the same ID, then they are considered by Prospero to be the same object. This is useful for distinguishing between two cases: (a) two links which happen to have the same name-component but different storage locations (a different host and handle pair), and which do not actually represent the same object, and (b) two links which have the same name-component and same ID, but possibly different storage locations -- in case (b), the objects are replicas and the client should access whichever one it chooses to. (Code is currently under development to enable servers to return a list of replicas in order of nearness to the client.) Two links with the same name-component and no ID specification are considered by Prospero to be different objects, not replicas of one another.
A problem with the ID field is that there is not an accepted
standard for universal document identifiers. An IETF working group has
been formed to consider such identifiers, and the ID
field exists in anticipation of their eventual agreement upon a standard.
We expect that there will be more than one type of universal document
identifier; therefore, there will be more than one id-type.
Prospero supports objects with several possible IDs.
For now, there are only two id-types defined. The REMOTE
id-type is used by the server when it has magic
knowledge (perhaps through a local database) that
two objects are the same. The REMOTE id type is a single
element which is the printed decimal representation of a positive
integer. This positive integer should be able to be stored in a 32
bit integer. A REMOTE id value of 0 means ``unspecified''.
The REMOTE
id-type cannot be sent across the network by clients in
queries. It is not guaranteed to be consistent across different
queries to the server, but server implementors are encouraged to make
the id-value token consistent across queries.
Many clients will locally generate ID fields to help the human user differentiate between conflicting links. These ID fields will have an id-type of LOCAL and an arbitrarily generated string as their id-value. They may not be sent over the network, and are not guaranteed to be unique from directory read to directory read, although implementors are encouraged to make them so. All available ID fields will be returned with every LIST operation.