Subject: Agenda for 12/6 telecon

From: Elias Sinderson <[email-masked]>
Date: Tue, 06 Dec 2005 11:47:14 -0800

Hi,

Enclosed below, please find the proposed agenda for tomorrows' telecon. 
It was infeasible to address all of the locking related issues in one 
call, so we'll have to address the remaining ones next time around. 
Please send me any other proposed agenda items that you want on the list 
for the next call.

Cheers,
Elias
_________________

(1) Celebrate RFC 4316 (1 min, Julian to do the honors.)

(2) Issues still on the table despite previous review / discussion / 
proposal. (29 min)
10 - Round-tripping namespace decls in properties
    (Please review latest proposal before telecon)
15 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15> - 
DAV:error description inconsistent with RFC3253
    (rough consensus on mailing list?)
46 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46> - URLs in 
Multistatus
    (address Lisas' recent questions)
188 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188> - 
PROPFIND include-dead-props
    (review Julians proposal)

(3) Remaining issues from 12/2 telecon (30 min)
105 - COPY for Collection Resources vs infinite loops
106 - COPY and the Overwrite Header vs merge behaviour desc added
107 - Status 102 present; but status-uri response header removed

(4) Locks, locking and the lockers who lock (120 min)
6 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=6> - 
Collection Lock vs MOVE with Overwrite
54 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54> - Locks 
vs multiple bindings
120 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=120> - 
DEEP_LOCK_ERROR_STATUS
124 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=124> - 
REPORT_OTHER_RESOURCE_LOCKED
132 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=132> - 
DEPTH_LOCK_AND_IF
133 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=133> - 
LOCK_SEMANTICS
136 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=136> - 
LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
    (May also resolve the next two issues, 140 and 143.)
140 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=140> - 
UNLOCK_NEEDS_IF_HEADER
143 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143> - 
LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER
138 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=138> - 
UNLOCK_WHAT_URL
141 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=141> - 
UNLOCK_WITHOUT_GOOD_TOKEN
145 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=145> - 
LOCKDISCOVERY_ON_UNLOCKED_RESOURCE
179 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=179> - 
DAV:no-lock
191 <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=191> - 
LOCK_ISSUES_ACCESS_RIGHTS

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Dec 2005 07:58:32 +0100

Hi,

as we're going to concentrate on locking issues, I'd like to remind 
everybody that the WG did compile a very short (but complete) summary of 
high-level locking semantics a long time ago. RFC2518bis will need to 
reflect the contents of this document in some way, potentially by just 
adopting it and making it an appendix.

Including the latest version 5.8 from 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0177.html>:

-------------- GULP (Version 5.8) --------------

- A lock either directly or indirectly locks a resource.

- A LOCK request with a non-empty body 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 empty content MUST be created by the request.

- 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 an internal
    member resource 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 deleting an internal member URI 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.

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

- A lock token is "submitted" in a request when it appears in an If
    header.

- If a request would modify the content for a locked resource, a dead
    property of a locked resource, a live property that is defined to be
    lockable for a locked resource, or an internal member URI of a
    locked collection, the request MUST fail unless the lock-token for
    that lock is submitted in the request.  An internal member URI
    of a collection is considered to be modified if it is added,
    removed, or identifies a different resource.

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

Best regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Wed, 07 Dec 2005 09:07:55 -0800

Julian Reschke wrote:

> everybody that the WG did compile a very short (but complete) summary 
> of high-level locking semantics a long time ago. RFC2518bis will need 
> to reflect the contents of this document in some way, potentially by 
> just adopting it and making it an appendix.

Ack, I meant to put an item on the agenda to discuss GULP - my bad, 
thanks for bringing this up. My recollection is that there seemed to be 
general consensus among the WG to include GULP as an appendix to 
2518bis, but I'd need to check the archives to be sure... At any rate, 
the information you posted will be relevant to todays telecon...

Thanks again,
Elias