Referential Integrity

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