Redmond: Strong References

There were long discussions of strong references at Redmond, the upshot of
which was consensus in the room to remove strong references from the
collections protocol specification, but make sure that the protocol was
extensible to support them in the future.

I did not come away with a clear sense of whether the group thought strong
references should also be removed from the collections requirements.  My
inclination is to keep them in the requirements, and acknowledge that the
requirements for strong references will not be met by the first version of
the protocol specification.

Here is a summary of the discussions:

Definition of Referential Integrity

The requirements and protocol specification define strong references in
terms of referential integrity.  A strong reference is "a reference whose
referential integrity is guaranteed by the server."  But there is no
consensus on a definition of referential integrity.  I understood it to
mean that the server would guarantee that the reference would not be
broken.  Others thought it implied some particular policy for preventing
broken references, for example, that the server would prevent the target
reference from being deleted as long as there were strong references to it.
 Others thought it meant something weaker, perhaps that strong references
would be notified when they were broken.

Policies for Enforcing Referential Integrity

There was no agreement on what policies for enforcing referential integrity
should be allowed or required.  Some suggestions were:

1. Let the owner of a resource be able to prevent strong references to that
resource.

2. 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.

3. Let there be only one kind of reference, one for which the server
enforces referential integrity as far as possible.

4. 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.
 
5. Leave the policy for enforcing referential integrity on deletes up to
the server.

6. Mandate a policy of preventing the delete of a resource as long as there
are strong references to it.

7. Perform the delete, and delete the strong references as well.

8. Perform the delete, and mark the strong references as "broken".

9. 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.

10. When a target reference is moved, any strong reference to it must be
updated to reflect its new location.

11. When a target reference is moved, any strong reference to it must be
notified of the change in its location.

Considerations against Strong References

Security concerns led some to suggest abandoning the notion of strong
references altogether.  

1. A policy of preventing deletes could prevent owners from managing
(deleting) their own resources.  

2. It was unclear what would happen for references that cross
administrative domains, where conflicting policies might be in force on
each domain.  

3. 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.  

4. 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.

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.

Benefits of Strong References

They are primarily meant to be used within a trusted group of
collaborators, to prevent accidental breakage of links either by moving or
by deleting the target resource.  

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.

--Judy


Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	(716) 422-5169
Fax:		(716) 422-2938

Xerox Corporation
Mail Stop 105-50C
800 Phillips Road
Webster, NY 14580

Received on Thursday, 25 June 1998 14:40:33 UTC