Subject: RE: Locking, moving and deleting

From: "Stefan Eissing" <[email-masked]>
Date: Tue, 2 Oct 2001 15:13:48 +0200

> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
>
>    From: Lisa Dusseault [mailto:[email-masked]]
>
>    On Behalf Of Clemm, Geoff
>    > The best way to explain the defined MOVE semantics for a LOCK
>    > is to say that a LOCK is on a URL, but that it is deleted
>    > when the resource mapped to that URL is deleted.
>
>    So far I can follow; it's not a bad model.  I'd append "or moved"
>    to the end; most people will consider this different than "deleted"
>    because we have different methods for MOVE and DELETE.
>
> I agree that is worth making explicit to avoid any confusion.
>
>    I don't follow your example as well (reproduced below) because WebDAV
>    doesn't specifically allow for one resource to be mapped by
> several URLs.
>
> WebDAV allows for one resource to be mapped to multiple
> URL's because HTTP specifically allows for one resource to be mapped
> to multiple URL's.  In particular, section 9.6 of RFC 2616:
>
>  "A single resource MAY be identified by many different URIs. For
>  example, an article might have a URI for identifying "the current
>  version" which is separate from the URI identifying each particular
>  version."
>
> Therefore the locking protocol (and the rest of WebDAV) must have
> well defined behavior in those cases where multiple URL's do identify
> the same resource.
>
>    Let's keep it simple and assume that a WebDAV system only maps URLs to
>    resources 1:1.
>
> That's fine, but it is good to keep the multiple mapping scenario in
> mind for when someone suggests a "simpler" model that does
> not handle the multiple mapping scenario.

Well, RFC 2518 Ch. 6 says:
  "The ability to lock a resource provides a mechanism for serializing
   access to that resource. Using a lock, an authoring client can provide
   a reasonable guarantuee that another principal will not modify a resource
   while it is being edited..."

This gave me the impression that locks are on a resource and not
on one particular URL of that resource.

I agree that multiple URL and deep locks on collections provide
some interesting challenges to define consistent behaviour. But
I find it a little bit hard to give up the assumption
   locking resource == locking resource content + properties

So, maybe I have misunderstood this thread?

//Stefan

---

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 2 Oct 2001 10:15:24 -0400

From: Stefan Eissing [mailto:[email-masked]]

   RFC 2518 Ch. 6 says:
     "The ability to lock a resource provides a mechanism for
      serializing access to that resource. Using a lock, an authoring
      client can provide a reasonable guarantuee that another
      principal will not modify a resource while it is being
      edited..."

The purpose of a lock is serializing access to a resource,
but that is not incompatible with saying "the lock is on a URI
and controls access to the resource mapped to that URI".

You just need to expand your equivalence as follows:

locking resource == locking URL == locking resource mapped to that URL.

Cheers,
Geoff