- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 14 Mar 2003 15:19:59 +0100
- To: <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, March 14, 2003 1:26 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > ... > > > 14) Section 8.11, The Effect of Locks on Properties and Collections > > > > "This means that if a collection is locked, its lock-token is > required in > > all these cases: > > - DELETE a collection's direct internal member > > - MOVE a member out of the collection > > - MOVE a member into the collection, unless it overwrites a pre-existing > > member" > > > > I think the latter is not really consistent with RFC3253. > > I think Lisa pointed it out, but the spec doesn't talk about URI protection. This > section is probably a good place to mention it. Geoff came up with some > wording that I don't have handy now. He and I disagreed with whether we > should say that lock protection is for write locks or just locks. > Anyway... Maybe this gets resolved by the adoption of GULP. I just wanted to clarify that a MOVE into a collection A overwriting a member *does* modify the state of the collection. > The Effect of Locks on URL Mappings > The resource located at the request-URI of the LOCK request MUST remain > at that URI until the lock is removed via UNLOCK or until an operation with the > proper lock-token header alters or destroys that mapping. This contraint insures > that the principal that locked the resource will be able to find that resource at the > same location as long as it holds the lock. > > Feel free to offer a better wording. I think the way to go is to get agreement on the current or a revised version of GULP, and use that in a single place within the spec. > ... Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 14 March 2003 09:20:07 UTC