150 likes | 244 Views
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.
E N D
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 xmlns=“DAV:”> <prop> <resourcetype/> <getlastmodified/> <quota xmlns=“http://www.xythos.com/ns/”/> </prop> <dead-props/> </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