WebDAV Advanced Collections Conference Call - 1/26/99 Attending: Judy Slein, Geoff Clemm, Jim Whitehead, Chuck Fay ACTION ITEMS Geoff: Send a message on the semantics of COPY for references to the WebDAV mailing list. Judy: Spec changes All: Send comments to Judy via e-mail this week on the treatment of redirect references in sections 3.5 - 3.7 and 3.9. All: Once we have agreed on semantics of MOVE and COPY, revisit how they interact with chains of direct references. LOGISTICS REVIEW SPEC CHANGES LOCKING 3.6 Assuming that locking a direct reference locks its target, then in a chain of direct references, all the intermediate references would be locked. The server is responsible for detecting any loops. The semantics of MOVE for collections that is defined in WebDAV says that if any member of the collection being moved (or of any of its child collections, recursively) is locked, then the MOVE fails. This means that the server has to scan the whole collection hierarchy in order to determine whether it can perform a MOVE. If we have LOCKs on collections with direct references lock the targets of the direct references, there will potentially be locks scattered through many trees as a result. The situation will be somehow much worse for servers if we do this than it was when WebDAV considered only locks on ordinary resources. (How is it worse? I've lost it. JS) In the systems Geoff works with, there is a difference between locking a resource's content and locking down the resource so that it cannot be moved. (To do the latter, you have to lock the whole hierarchy down to the resource you care about.) That difference is lost in the WebDAV semantics. There are performance problems if we require servers to lock the targets of direct references. If the lock scope goes beyond one hierarchy, it can become prohibitively expensive. Geoff also dislikes allowing individual references (as opposed to collections that contain them) to be LOCKed. This is because file-system-based servers may not store the references as separate resources that can carry their own properties. If the target of a direct reference gets locked, what happens to alternative references to that target? Options: Get rid of direct references altogether, or give them to the versioning team to define Curtail lock on direct references Make direct references be aliases Let's have a LOCK on a direct reference lock only the reference, not its target. In that case, down-level clients will be "consistently surprised". LOCKS will work the same for all flavors of references. The client will think it has a lock, but the target resource may change. Keep the behavior of LOCK for references in collections and for individual references consistent. Should we also say that the server may reject a request to lock an individual reference? No. WebDAV requires support for locking individual resources. References should be like any other resource. Agreed: When LOCKing a collection, only its internal members are locked. In this context, that means that only references get LOCKed, not their targets. This will be true for both direct and redirect references. Agreed: Include rationale in the specification: Locking targets of direct references forces the scope of LOCK to go beyond a single collection hierarchy. This would be prohibitively expensive to implement. Combined with the semantics of MOVE as defined in the WebDAV specification, where a single lock anywhere in the tree below a collection can prevent the collection from being MOVED, this would force a server to scan the entire tree before performing any MOVE. Agreed: To keep semantics parallel between locking collections and locking individual references, a LOCK on any reference (direct or redirect) will lock only the reference, not its target. Agreed: If a client submits a lock token in an If header for a resource that is not locked, the request fails with a 412 (Precondition Failed). Down-level clients would find out in this way that the target resource was not locked. Point this out in the spec. SEMANTICS OF COPY Geoff thinks COPY should get passed through to the target, while DELETE and MOVE apply to the reference. But this may be impossible because WebDAV defines MOVE as COPY + DELETE. We'll return to this issue. DANGLING REFERENCES 3.13 In the discussion of PROPFIND and other operations on collections, state clearly what value of the Depth header produce the semantics described. REF-INTEGRITY HEADER Currently the spec lays out 3 cases: 1. do-not-enforce (server MUST NOT enforce referential integrity) 2. header not present (server MAY, but is not required to, enforce referential integrity using any policy it likes) 3. header present with any other value (If the server understands the value, it does the right thing. If the server does not understand the value, it MUST assume that some flavor of referential integrity is being requested, and enforce referential integrity using the policy of its choice.) This is pretty messy. We could: 1. provide another value "enforce" that lets the server use any policy, and require the server to fail the request if it gets a value it doesn't understand. (This would leave "enforce" with some vague meaning -- be explicit about that.) 2. just require the server to fail the request if it gets a value it doesn't understand Judy will make a decision and fix the spec. Judy will delete the "DAV:" prefix on the header value. DAV:refintegrity PROPERTY The values should be weak or ANY. ISSUE 2: REDIRECT REFERENCES Everyone should send mail to Judy this week with comments on sections 3.5 - 3.7 and 3.9. ISSUE 6: REFERENCING HEADERS IN RESPONSES This section summarizes things that are said elsewhere. There's some risk of conflict. Agreed: Take the normative language out of 3.14. Agreed: Make it clear that operations on collections that contain direct references do not get Ref-Type and Ref-Target headers back. Instead, they get reftarget and reftype elements in the response elements of a Multi-Status response. Agreed: Make it clear that No-Passthrough is an exception to the second rule. Agreed: LOCK as we have now defined its semantics gets applied only to references, not to their targets. However, we *do* want it to get Ref-Target back with the response. Agreed: No-Passthrough with LOCK is now a no-op (except that Ref-Target must come back with the response, which is not generally true if you use No-Passthrough with a request). Agreed: List GET and HEAD as exceptions to rule 2. Agreed: For chains of direct references, multiple Ref-Target headers will be returned, each including a hop number + URL. Consider including in 3.14 pointers to all the other places (the normative statements) in the spec that discuss what headers are included with responses. ISSUE 9: CHAINS OF DIRECT REFERENCES In general, just follow the semantics already in place. If a chain of direct references seems to need an exception in the semantics, there is probably something wrong with the semantics. PUT, MKREF, MKCOL -- just state the consequence of the current rules. If there is a dangling reference in the middle of a chain of references, the server won't know that it is in the middle of a chain. It will think it is at the end of a chain and is being asked to create the resource there. The result will be a new resource at the location identified by the DAV:reftarget property of the broken reference. Once we settle on MOVE and COPY semantics, check MOVE and COPY semantics and how they interact with chains of direct references.