effects of locks on collections, was: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt

> 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