WebDAV – IETF 56

Agenda Interim WG meeting and Interop Testing - Jim RFC2518bis: Lisa Dusseault –GULP = Grand Unified Lock Proposal –Other issues Quota: Brian Korver Bindings: Geoff Clemm Ordered Collections: Geoff Clemm ACL: Geoff Clemm DASL: volunteer??

Interop/Interim results Held face-to-face interoperability testing event in Sept, 2002 –37 people attended, tested 13 clients, 16 servers –much improvement in interoperability Progress underway to develop improved compliance test suite –Improved version of Litmus –"Harry" a database-driven compliance tester –Both currently held up by Adobe IP release process –Work underway to address this Continuous online interoperability testing

GULP Do UNLOCK requests to an indirectly locked resource work? –Or does the client have to address lockroot? Change/clarify what “submitted” means –W.r.t. lock tokens submitted in the If header Keep in mind goals of RFC2518bis and GULP –Clarify without changing spec –Improve interoperability

Agreed text so far A lock either directly or indirectly locks a resource. A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request.

Agreed text continued If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if a internal member is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of removing an internal member URL identifying that resource is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock.

First problem “An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock.” Confirm indirect?

Second problem: “submitted” “A lock token is "submitted" in a request when it appears in an If header.“ Julian asked for this to say that the token must be tagged with the lockroot URL –That is inconsistent with RFC2518 untagged syntax –Breaks clients –Harder to get right

What is locked The following operations must fail unless the lock-token for the lock is submitted in the request: 1. modify the content for a locked resource 2. modify a dead property of a locked resource, 3. modify a lockable live property be for a locked resource 4. modify an internal member URL in a locked collection, 5. modify any content, properties or URLs of any descendent of a depth-infinity locked collection.

Last piece If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail.

Allprop replacement proposal </propfind>

207 Replacement Proposal A –Define “partial success” response –New 400-level error code –Multi-status body Proposal B –Do nothing –Not an interoperability problem

Are ETags required Current consensus appears to be –Servers SHOULD implement –Standard will explain why this is a really good idea

Response bodies with extensible error codes Some text in latest version of rfc2518bis To do a complete job, need to define more codes and exactly what they mean Guidance from WG?

Small changes Changed domains to “example.com” or “example.org” Clarification how live property copy works differently than live property move More If header parsing/handling clarity Require servers supporting ‘bis’ to handle commas in If header