WebDAV%20

1
WebDAV IETF 56
2
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??

3
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

4
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

5
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.

6
Agreed text continued

• If a collection is directly locked by a
  depthinfinity 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 depthinfinity 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 depthinfinity 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.

7
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?

8
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

9
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.

10
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.

11
Allprop replacement proposal

• ltpropfind xmlnsDAVgt
• ltpropgt
• ltresourcetype/gt
• ltgetlastmodified/gt
• ltquota xmlnshttp//www.xythos.com/ns//gt
• lt/propgt
• ltdead-props/gt
• lt/propfindgt

12
207 Replacement

• Proposal A
• Define partial success response
• New 400-level error code
• Multi-status body
• Proposal B
• Do nothing
• Not an interoperability problem

13
Are ETags required

• Current consensus appears to be
• Servers SHOULD implement
• Standard will explain why this is a really good
  idea

14
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?

15
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