Advanced Collections Conference Call
October 6, 1998

Minutes taken by Jim Davis (first part) and Judy Slein (second part).

Present: Roy Fielding, Jim Davis, Judy Slein, Jim Whitehead, Alan Babich,
John Stracke, Jim Amsden

Agenda

Judy's list of issues (from email)

1. Optional backpointers
2. Terminology (direct/indirect or something else)
3. Which methods get passed through for direct references
4. "There should be a choice about whether deleting the target of a direct
reference deletes all (direct) references" (Roy's, I think)

1. Backpointers:

We agree that the list has reached rough consensus that it is okay to
define the backpointer property as an optional property.

2. Terminology:

We will try using "direct and redirect" instead of "direct" and "indirect"

3. What methods get passed?

Are "direct references" resources?  This is a difficult philosophical issue.

When a reference is a member of a collection, and one does a PROPFIND
on the collection, there won't be any way to distinguish a reference
from a 'real' resource.

It would be good to state the rationale for why DELETE, COPY, and MOVE
don't pass through.  If DELETE doesn't MOVE can't, because MOVE is a
"macro".  DELETE doesn't, because deleting the reference obtains the
desired new state (the resource no longer appears in the collection),
and deleting the target as well would be unnecessary extra work.
What about COPY?

The purpose of references is to have secondary 'configurations'
without having to worry about making copies that can get out of sync.
DELETE, COPY, and MOVE affect the secondary 'configuration'.

We agree on the three methods

4. "There should be a choice about whether deleting the target of a direct
reference deletes all (direct) references"

We agreed that this behavior must be optional, because while it's
pretty easy to implement direct references, it not easy to implement
back pointers or the semantics of deleting references when target is
deleted.

Issue: must define the behavior if the target of a direct reference
has been deleted?

Issue: 

Should the client be able to request creation of a reference whose
referential integrity is not enforced?
  Counter argument: few if any servers will implement both choices
  Putting in the choice complicates the protocol for no benefit.
    Counter-counter argument: Some DAV servers currently under development
      support both types of integrity.

The use case (Fielding) is to be able to create a reference, have the
target go away, have the target get recreated, then have the reference
work again.  There is some skepticism about the reasonableness of this case.

Should a client be able to choose when DELETEing a target to not
enforce referential integrity?
  No, because this requires all clients to be correct.

It could be that once we work out the behavior of references whose targets
have been deleted, Roy's case won't be workable for other reasons.  

{Ed: the notetaker changed to Judy Slein at this point}

If we decide to support a client request for referential integrity / no
referential integrity, it should be applied when a reference is created.

Semantics of Dangling References

PROPFIND on a collection: 207 Multistatus, with a 404 Not Found as the
status for the dangling reference.
GET on a dangling reference: 404 Not Found + Ref-Type header
PROPFIND for a single property on a dangling reference: needs more thought
PROPPATCH on a dangling reference: 404 Not Found, so in this case there is
no distinction between the case where the reference is not there and the
case where it's a dangling reference.  Is this ok? 
PUT on a dangling reference succeeds.

There needs to be more discussion on the semantics of dangling references.

We will take back to the list the issue of whether clients need to have a
choice about whether references will be deleted when their target is
deleted.

Jim Amsden protested against the conclusion that there is consensus that
optional backpointers are ok.  He will send another note to the list on this
issue.  

Against backpointers: WebDAV should define only properties that are needed
for the protocol to operate.

Counterargument: There is a requirement to be able to navigate upward from a
resource that referenced, to find out what collections it is referenced
from.  The DAV:references property satisfies this requirement.

Proposal: Don't put optional backpointers into the Advanced Collections
spec, but instead write an informational rfc that recommends the
DAV:references property as the way to provide interoperable backpointers.
No decision.

*** Meeting Adjourned ***