Direct and Indirect References

In the advanced collection design, a  reference is a resource that is
independent of its target, e.g. operations on either don't affect the
other.  They have distinct sets of properties, and (baring referential
integrity) either can be deleted without affecting the other, and so on.
This allows us to not deal with, e.g., the security problems of relaying
requests from reference to a (possibly remote) target.

Yet there have also been suggestions that this is a *policy* that should
not and need not be built into the protocol.  I can easily imagine that, at
least in some limited cases, some users would prefer to sometimes be able
to get a kind of reference that is not independent, so that e.g. a PROPFIND
on the reference returns all and only the properties of the target, and so on.

Let me call such a reference a 'direct' reference.  Direct references (and
their targets) do *not* have properties 3.1.2 and 3.1.3.  Operations on one
*do* affect the other.  A collection listing *does* follow references.  A
GET on the reference just gets the target, a PROPFIND goes to the target,
etc.  This also means giving up on 3.1.8.

This kind of reference  would sometimes be useful, even if it could only be
implemented typically when both the reference and the target were on the
same server, and even though it would require care (e.g. to avoid cycles.
But this is true for symbolic links in file systems, too.)

If it's the case that this kind of reference would ever be desirable (and I
think it is), then I think we should alter the requirements document to
introduce this distinction (between direct and indirect references), and to
state which properties apply to which kind of reference.  I don't think we
should try to define this in the protocol document.  Direct references
raise too many hard issues to define now.  (Remember how much trouble we
got into just trying to define the semantics of referential integrity?)
But if we extend the requirements document, at least we won't be
*preventing* someone from defining the semantics of direct references later
on.

It's fine if the protocol provides only indirect references.  It isn't
going to do referential integrity, either.  We have to leave *something*
for future generations to do, after all.

I mentioned this to Judy and she said I ought to ask the list, which is
what I am doing now.

To be concrete:

This change would require adding the adjective "indirect" to requirements
3.1.2, 3.1.3, 3.1.4, 3.1.5(?) 3.1.8, and modifying the language in 3.1.12

FWIW, in the protocol, to implement direct references, you'd need to revive
DELREF, because DELETE on a direct reference deletes the target as well as
the reference.  But that's for the protocol, not the requirements.

Received on Thursday, 9 July 1998 18:03:15 UTC