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.