- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Fri, 18 Dec 1998 09:38:06 -0500
- To: "'WebDAV'" <w3c-dist-auth@w3.org>
At the breakout session on collections in Orlando, the issue of referential integrity was raised. There was a request that we get on the record the reasons that led to our decision to exclude issues of referential integrity from the scope of the current collections spec. Here are some excerpts from a trip report I wrote after last spring's meeting in Redmond, where the decision was made to rule referential integrity out of scope: The second day was devoted to Collections. The new functionality being introduced in this area is membership-by-reference in collections and ordered collections. Discussion focused on two areas: referential integrity and scalability issues. The notion of "strong" references, whose integrity is guaranteed, was introduced at the Los Angeles IETF meeting. The complex issues surrounding referential integrity led us to drop strong references from the specification for now, but insure that our notion of references is extensible to allow for them in the future. There was no consensus on a definition of referential integrity. Some thought it applied only to deletes, others thought it applied primarily to moves, some thought it implied a particular policy about how to prevent broken references. Some policies mentioned were: A target resource cannot be deleted while there is any strong reference to it The target resource can be deleted, and any strong references to it are deleted as well. A target resource can be deleted, but any strong references to it must be notified or marked "broken". When a target reference is moved, any strong reference to it must be updated to reflect its new location. When a target reference is moved, any strong reference to it must be notified of the change in its location. There was controversy over what policies should be allowed for enforcing referential integrity for deletes. Suggestion: Let the owner of a resource be able to prevent strong references to that resource. Suggestion: Let the owner of a resource be the one who gets to decide whether that resource can be deleted in spite of strong references to it. Suggestion: Let there be only one kind of reference, one for which the server enforces referential integrity as far as possible. Suggestion: Weaken the notion of "strong" reference to mean only that the server must make its best effort to maintain referential integrity. Keep the notion of "weak" reference. Suggestion: Leave the policy for enforcing referential integrity on deletes up to the server. Suggestion: Mandate a policy of preventing the delete. Suggestion: Perform the delete, and mark the reference as "broken". Suggestion: Interpret enforcement of referential integrity to mean only that the server must notify the references that the target has been deleted. It is up to the references to decide what to do about this. Suggestion: Keep the definition of referential integrity and strong references at a fairly abstract level in the requirements, and save a discussion of policies for the protocol specification. Security concerns led some to suggest abandoning the notion of strong references altogether. A policy of preventing deletes could prevent owners from managing (deleting) their own resources. It was unclear what would happen for references that cross administrative domains, where conflicting policies might be in force on each domain. Strong references can be a security risk for the target's owner if, for example, the target got moved to an area of the server that was intended to be secret, allowing owners of the references to discover its existence. Strong references can be a risk to the reference's owner if it is possible to trace back to the reference, which might reveal a private area of a server. Some were skeptical about whether we really need strong references, since you can always discover whether a link is good by trying to follow it. Others felt that the usefulness of strong links for tracking moves outweigh the security threats. They are primarily meant to be used within a trusted group of collaborators, to prevent accidental breakage of links. There are also cases where it is useful to prevent accidental breakage of links between different trust sets. For example, anyone may want to link to RFCs at the IETF, and would like the links not to be broken when the RFCs are moved. Suggestion: There may be a requirement for discovery of what policy the server uses to enforce referential integrity. There was controversy over whether it should be possible to discover from a target resource which resources reference it. On the one hand, allowing discovery would support out-of-band negotiation with the owners of links when changes are contemplated. On the other hand, discovery would raise privacy concerns that at a minimum must be addressed in the security section. Some felt that it was unacceptable to require that strong references be advertised. Question: Can locking prevent a server from maintaining referential integrity? What happens if a target resource gets moved while one of the strong references to it is locked? WebDAV states that locking does not prevent a server from updating live properties, so the DAV:reftarget property can be updated. There may be some conflicts between strong referencing and the versioning specification. This needs to be investigated. Several proposals about Ref-Integrity on a MOVE or COPY of a referential resource were considered: 1. There is no Ref-Integrity header with MOVE or COPY. The request must fail if the server can't preserve the value of DAV:refintegrity at the new location. 2. The value of DAV:refintegrity will be weak by default at the new location. If the client wants a strong reference at the new location, it must use the Ref-Integrity header with the MOVE or COPY request. 3. Let the server downgrade DAV:refintegrity to "weak" if necessary at the new location. Define a new header that means: Fail unless you can preserve the referential integrity setting. Proposal: For DELETE on a target resource, provide a new header that says "Override integrity." Then the owner of the resource has a way to delete it even if there are strong references to it. Decision: We will postpone specifying strong references provided we can provide hooks for extensibility. Only one value for Ref-Integrity will be defined now: Weak. But we will allow values to be extended by private agreement now and officially later. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580
Received on Friday, 18 December 1998 09:33:00 UTC