Subject: RE: DELETE leaving a lock-null resource; was LOCK Scenarios

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Thu, 23 Sep 1999 23:40:19 -0700

The suggestion has been made that we introduce transactioning. I hope you
will not think me cheeky if I summarily reject the suggestion of using
transactioning. I, for one, would really like to be able to sell webdav
servers for something under $100,000 a piece.

Small problems need small solutions.
Big problems need big solutions.

Lock-null solves a small problem. We do not in the 99% case need
transactioning. There are systems that need transactioning and for those
guys I would recommend looking at TIP (RFC 2371). I actually released a spec
at one point specifying how to use TIP with HTTP and I have another spec I
haven't released which shows how to implement the TIP protocol itself using
HTTP. I did the later mostly because I hate seeing people inventing
arbitrary new protocols which can be implemented with existing systems for
no particularly good reason. But I digress...

Either way, lock null, much like PROPPATCH and LOCKs themselves, were
introduced to cover small areas of transactioning like semantics that even
low end systems require. Believe me, we WANTED to require transactioning.
Every time I look at PROPPATCH I want to vomit. It violates just about every
principal of good protocol design. I have similar feelings about
multi-status but that was required due to a flaw in HTTP's design not due to
the lock of transactioning. In either case, we had to make a choice between
designing a system that people could implement and one that read well on
paper.

BTW, in so far as what happens when you DELETE a locked resource I
completely oppose the suggestion that DELETING a resource results in a
lock-null resource. That is absolutely contrary to the definition of DELETE.
DELETE deletes the resource not the name. Since the lock is associated with
the resources deleting a locked resource deletes both the resource and the
lock.

		Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:[email-masked]]
> Sent: Thursday, September 23, 1999 8:22 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios
> 
> 
> <gmc/> After slightly wavering, I'm firmly back in the:
> "just say no to lock-null resources" camp.
> We just don't need the complexity of a "non-resource resource"
> for the minimal gain it provides.
> 
> Cheers,
> Geoff
> 
>    From: [email-masked]
> 
>    <jra>
>    There are a large number of situations in authoring 
> environments where
>    transaction semantics are required. WebDAV doesn't (yet) 
> support transactions,
>    and I don't think we should attempt to come up with a lot 
> of special cases (like
>    lock-null resources) supported by the protocol to overcome 
> this important
>    missing function. Rather let's propose an extension that 
> does support
>    transactions. Might be pretty hard with a stateless server though.
>    </jra>
>    <JC>
>    So you're not a fan of lock-null resources either at this 
> stage.  That seems
>    consistent.
> 
>    JimA and I have been doing all the talking for the last 
> day.  Anyone else want
>    to be heard?  :-)
>    </JC>
> 
>    <jra>
>    I don't really care that much one way or the other about 
> lock-null resources. I
>    think they add a lot of complexity to the protocol for 
> little functional gain
>    and wouldn't be opposed to removing them. But if they 
> stay, that's OK too.  If
>    lock-null stays, then I think it would be reasonable for 
> delete on a locked
>    resource to change the state of the resource to a 
> lock-null resource. To
>    complete the delete, the client would have to do the 
> unlock. This is at least
>    consistent semantics and allows the protocol to support 
> symmetric resource
>    life-times.
>    </jra>
> 
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 24 Sep 1999 05:48:22 -0400

From: "Yaron Goland (Exchange)" <[email-masked]>

   <yg/> The suggestion has been made that we introduce transactioning. I
   hope you will not think me cheeky if I summarily reject the suggestion
   of using transactioning. ...

<gmc/> I agree with Yaron that we do not want to bite off general
transactioning support as part of WebDAV.

   <yg/> BTW, in so far as what happens when you DELETE a locked resource I

<gmc/> If lock were *really* just associated with the resource, I'd be a
happy camper.  For one thing, it would mean that when multiple URL's
are mapped to a single resource, you could issue the LOCK against any
of those URL's and the result would be identical.  Similarly, you could
later on issue on UNLOCK against any of those URL's and again, the result
would be identical.

<gmc/> But I have seen various arguments in the past that a LOCK should
also protect the URL to resource mapping.  If "protect" just means
"keep from being deleted", then your conclusion still holds, i.e.
it makes no sense to LOCK a deleted resource.  But if protect also
means "reserves the right to change the URL to resource mapping",
then it is perfectly sensible to keep a LOCK after the resource is
deleted (that is pretty much what a lock-null resource is anyway).

<gmc/> I personally believe that the best answer is to fix the LOCK
semantics so it *really* is just on the resource (and not on the
name).  Then things are simpler and consistent, even in the case of
multiple URL mappings to a resource.  Rather than "protecting" a URL
to resource mapping, I'd propose that a locked resource be allowed to
MOVE (this is just a change to the state of the parent collection, not
to the state of the resource being moved), but that an attempt to
access the MOVE'd resource with that lock just returns a 302 indicating
where it has MOVE'd to.

<gmc/> And as for the question of whether DELETE deletes all bindings
to a resource or whether it just DELETE's the binding named in the
DELETE request-URL, I am an adamant supporter of the current advanced
collection protocol specification which states that it *only*
deletes the binding named in the DELETE request-URL.  This behavior
is *essential* in order to allow versioning-unaware clients to
be able to issue a DELETE without destroying the history of a
resource.

<gmc/> So there are really multiple threads here:
- Should locking be on a resource or also/instead on a URL-to-resource
  mapping?  (we know what it is now, but what *should* it be)
* I vote "on a resource".
- Does a DELETE delete all bindings to a resource, or just the one
specified in the request-URL.
* I vote "just the one named by the request-URL".
- Should a DELETE delete a LOCK?
* I vote, "no".  A DELETE modifies the state of the collection containing
  the binding, not that of the resource.  In particular, all other
  mappings to that resource will continue to exist and display the
  LOCK'ed semantics.  If you want to prevent a DELETE, you put the
  LOCK on the collection whose state is being modified.

<gmc/> I realize that this requires changes to 2518, and I would not
make such a suggestion lightly.  The problem is that 2518 was specified
without the use cases of multiple bindings and versioning in mind,
and needs to be revisited now that those use cases have been elaborated.

Cheers,
Geoff

---

From: Edgar Schwarz <[email-masked]>
Date: Fri, 24 Sep 1999 13:01:18 +0200

Geoffrey M. Clemm wrote:

> also protect the URL to resource mapping.
For my part I was just concerned that the locker should be able 
to find his locked resource after a MOVE.

> access the MOVE'd resource with that lock just returns a 302 indicating
This would give me what I wanted. I even could imagine that it is enough
that only a access with the lock token MUST get the new location.
For all others it's just gone, like other resources which are moved.
So a server could just remember lock tokens together with old and new
URLs and keep this data until it is accessed by the locker or the lock
expires.

>   LOCK on the collection whose state is being modified.
Agreement on all points. The last couple of days I thought that already
too much energy was spent with this topic.
This proposal seems to be as simple as possible, but not simpler.

Regards, Edgar

-- 
[email-masked] ON/EUE1, 07191/13-3382         Niklaus Wirth:
Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag.
Albert Einstein:  Mach es so einfach wie moeglich, aber nicht einfacher.

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 24 Sep 1999 08:59:28 -0400

From: Edgar Schwarz <[email-masked]>

   > also protect the URL to resource mapping.

   <es/> For my part I was just concerned that the locker should be able 
   to find his locked resource after a MOVE.

Yes, I believe that is the essential functionality to be provided, in addition
to the lock on the state of the resource.

   <gmc/> to resource mapping, I'd propose that a locked resource be allowed to
   MOVE (this is just a change to the state of the parent collection, not
   to the state of the resource being moved), but that an attempt to
   access the MOVE'd resource with that lock just returns a 302 indicating
   where it has MOVE'd to.
   
   <es/> This would give me what I wanted. I even could imagine that it
   is enough that only a access with the lock token MUST get the new
   location.  For all others it's just gone, like other resources which
   are moved.  So a server could just remember lock tokens together with
   old and new URLs and keep this data until it is accessed by the locker
   or the lock expires.

<gmc/> Ah yes, *much* better than the 302's, and provides better
compatibility with clients written against the existing locking
protocol.  Great idea, Edgar!

   >   LOCK on the collection whose state is being modified.

   <es/> Agreement on all points. The last couple of days I thought that
   already too much energy was spent with this topic.  This proposal
   seems to be as simple as possible, but not simpler.

<gmc/> I've been agonizing for months over trying to make the existing
locking protocol work unmodified in the presence of multiple bindings
and versioning.  There are massive numbers of edge cases and things
that just plain don't work.  If you just say that a lock is on a
resource, and then use Edgar's proposal that a lock token combined
with the original URL guarantee access to that resource, then multiple
bindings and versioning semantics interacts can be combined with
locking in a manageable fashion.

I'll make a pass through the current version of 2518 to identify the
sections that would need to be modified, and will run this against
Judy's list of use cases for locking in the presence of multiple
bindings, to see how the details play out.

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Fri, 24 Sep 1999 14:24:09 -0700

> protocol.  Great idea, Edgar!

I'm not convinced this will work, since it only handles the case where the
resource is moved just once.  What happens if a resource is locked, then
moved, and moved again?  How many steps is the server required to remember?

> bindings, to see how the details play out.

I'm looking forward to this.

- Jim

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 24 Sep 1999 18:05:00 -0400

From: Jim Whitehead <[email-masked]>

   Edgar Schwarz write:
   <es/> So a server could just remember lock tokens together with
   old and new URLs and keep this data until it is accessed by the locker
   or the lock expires.

   <ejw> I'm not convinced this will work, since it only handles the case
   where the resource is moved just once.  What happens if a resource is
   locked, then moved, and moved again?  How many steps is the server
   required to remember?

Subsequent MOVE's are not relevant.  The server is responsible for
retrieving the same resource whenever the client gives it a URL
and a lock token (think of it as a private binding that the server
keeps around).  The server could do this by just refusing to MOVE
or DELETE the resource (as is required by the current 2518 draft),
or by just remembering what resource is associated with that
<URL, lock-token> pair.  All we are doing here is giving the server
some additional flexibility in implementation that was constrained
by the current language in 2518.

Note: if a lock-token is included in a MOVE or DELETE request, it is
used to satisfy any locks on the source and destination *collections*.
Locks on the resource being moved or deleted are not even inspected
(since the state of the resource being moved or deleted is not being
modified).

Cheers,
Geoff