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

From: [email-masked]
Date: Fri, 24 Sep 1999 16:04:06 -0400

Sigh... I have had to delete a lot of WebDAV mail recently unread. WebDAV is
no longer the focus of my existence and my other duties are pressing so it
is difficult for me to properly contribute to these conversations. I will
throw in a few points of general experience that I hope will help:
<jra>
Too bad, your participation will be missed.
</jra>

1) I guarantee that if you change the way LOCK works you will end up with a
protocol that will be unimplementable on the majority of existing systems.
The namespace is locked by a LOCK request for a damn good reason, if you
change it, most of us implementers will probably just be forced to ignore
you so we can properly support our users.
<jra>
The issue of namespace control and resource contents control are separate.
Namespaces are the domain of collections. If a user wants to control a
namespace, then the collection managing or defining that namespace can be
(shallow) locked. Multiple bindings and versions introduce new locking problems
which we have to address. Some of these issues may require us to go back and
rethink existing semantics.
</jra>

2) A link to the history resource should never appear to a down level
client, they should only see a URL to a tip version. If this is not the case
with the version design then the version design is broken.
<jra>
non-versioning aware clients will see revisions selected by the default
workspace. Tip revisions alone would not provide any way for a site
administrator to provide a consistent set of revisions to these clients.

non-versioning aware clients can access all unversioned resources, including the
history resource and interpret the contents any way they want. It might not be
useful, but there's really no need to prevent it.
</jra>

3) MOVE doesn't move locks due to interoperability issues. If you want a
protocol no one but a couple of super high end providers can ship then go
right ahead, make the change.

The problem here is that the people really working hard on this protocol,
folks like Geoffrey and JimA, are basically super high end people. They are
not used to having to live in the crappy, confined, miserable, limited hell
known as consumer software. Therefore they make proposals which are 100%
consistent, elegant and imminently reasonable, if you are shipping a super
high end system.
<jra>
I have to strongly differ Yaron. Geoff and I have both consistently pushed for
simplicity and elimination of design by special case. Elegant, simple, useable,
and implementable go together. The process of getting there is MUCH harder.
</jra>

Asad and I used to represent the dirty masses and I did a good pitch at
representing clients (having worked on IE for all those years) but no one
seems to have taken our place. The discussions here are very far removed
from the reality of consumer software. You are creating a standard that will
only be implementable on brand new, high end systems. Existing users will
simply be screwed. WebDAV's current success has been that 2518 is easy to
implement. The stuff you guys are creating and the changes you are proposing
to 2518 to allow you to implement your super high end features will kill the
lower end market.
<jra>
WebDAV will continue to be a layered protocol with lots of options. Server
implementors will have lots of freedom to provide simple support, or extended
functions for users that need them. Adding bindings and versioning does not
require all server vendors to implement them.

B.T.W., there's lots of client activity going on based on the versioning
extensions, and these extensions are based on many existing client applications
and use cases. So I don't agree that we are so far off the mark.
</jra>

---

From: [email-masked]
Date: Fri, 24 Sep 1999 19:14:11 -0400

<gmc/> I agree with Yaron that we do not want to bite off general
   transactioning support as part of WebDAV.
</jlc> I agree.  I also agree with his implying that NULL LOCKS aren't really a
violation of this design philosophy.

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

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

<jlc/> I think if we say that locks are bound to URI's, I'm comfortable with a
null lock resource being left after a delete.  At least optionally.  This can be
very handy and leverages null lock resources well.

<jlc/> OTOH, if we go with a model that locks are bound to resources and that
DELETE deletes bindings, then something has to give. (If not, DELETE may
actually create a lock so that the null resource has a lock and so the original
resource also has a lock at its other bindings.  Hmmm.) I think what has to give
is that null locks go away.  At least for DELETE in this model.

<jlc/> I think Yaron just posted that DELETE deletes resources, not bindings.  I
prefer the "single UNBIND" model of DELETE.   A lot of discussion has already
gone into this.

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

<jlc/> I agree in principle about that changing to a pure model should be
easier.  (Pure URI or pure resource.)  I'm uneasy though about the mechanism
suggested to find where resources have moved to.  Seems messy.  Less so without
depth locks though.  More analysis later.

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

<jlc/> I'll play along for now. :-)

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

<jlc/> Sounds fine.

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

<jlc/> Sounds fine given the model.  I do think locking a collection is a rather
fat approach but I still agree with your point.

---

From: [email-masked]
Date: Fri, 24 Sep 1999 21:38:41 -0400

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

  <gc/>
  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).

Geoff, I think Jim's point was that the same lock could have been rooted at many
places over the course of time as it has moved.  In fact due to multiple
bindings and such... we've added even one more multiplier to the size of the
list that needs to be maintained.  His question though was how long does the
server need to maintain it.  I guess the server/lock would need to remember all
of it's URI's until the resource is eventually UNLOCK'd.

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

I see.  So the proposal is that a server either to protect the URI... or to
maintain a way for a client to follow where it moved to... and you're proposing
the mechanism to do the latter.  Interesting.  It could be a market
differentiator.  It would mean a bit more complexity for the client to support
either type of server though.  Not much though.  I think if the client supported
what you're proposing, they'd also work with a system that does URI protection.
They'd just wouldn't execute the code that deals with what happens after a
remapping.

Also note: in the presence of depth locks... zillions of resources can be
locked.  I don't think this necessarily increases the size of the list of lock
URI's maintained since I believe only the URI's of the root of the lock need to
be maintained... but it does mean that the resolution algorithm has to be more
sophisticated since it would also need to remap the URI of child resources also.

This means that a client must submit lock tokens with GETs and PROPFIND's just
to insure it gets redirected when necessary.  No biggie I suppose.

I'm not sure this would work well with clients that seperate the lock action
from subsequent actions on the locked resources.  That is, a human is running
the client code.  The human requests the locks.  Then a human requests various
actions on resources that "just happen to be locked".  I guess that whenever the
human requests an action on a resource, the client application would just need
to make a point of finding all locks that apply to a resource... even if
inherited... and submit them with the request.  I guess this sort of client app
often would have to do this anyway, but now they must also do it for PROPFIND
and GET also.  Okay, no biggie.

It also means that I believe for the first time in WebDAV, it actually becomes
functionally important to specify the URI at which we think a lock is rooted
when we submit the lock token.

Note: all of this also needs to apply to DELETE (UNBIND) in addition to MOVE.
It also in turn applies to a COPY that deletes the destination due to the
implicit DELETE phase.  It also applies to a BIND that deletes a previous
binding.

   <gc/>
   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).

I don't think this is what you were trying to say, but what you just said
inspired a thought.  If someone does a MOVE... and all the tokens of all the
would-be protected URI's are submitted, the server doesn't need to maintain a
remapping list because the client already knows which locks have lost those
mappings.  It's only the URI's for locks for which no tokens were submitted that
the server needs to remember the remapping.  This might provide for more
efficient operation.

A lock can have many mappings and a single operation can delete multiple
mappings of a lock. Previously we said that each lock had a particular URI that
was protected... and only when that URI was moved, did feel compelled to do any
kind of lock remapping.  Although we could probably guess, t now claim to know
what lock mapping(s) the client really cares about.  None are more privledged.
I think the previous paragraph has to be modified to state that if any of these
locks have other mappings than the mappings submitted with the token, then all
of those others that are broken by an operation need to go onto the remapping
list for that lock.  Is this really *required*?  I think technically yes... but
probably not in practice.   The client probably only knows a lock by one
mapping... and it will be the one that the client will submit.

Protecting a URI is sounding easier.  :-)

---

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Sun, 26 Sep 1999 00:12:19 -0700

> I admit that the requirement that the token be used with the GET
> statement is an incompatibility with the old spec, but it is by
> no means complex for clients to handle.

Perhaps I don't understand the proposal. I have provided examples below
which demonstrate how it appears to me that the proposal works. Please let
me know if I have analyzed the situation correctly.

Example #1 -

Hiro is writing up his new web page using Microsoft Word. Word is supposed
to be WYSIWYG but he knows that HTML handling is more art than science. So
he boots up Netscape, which many of his users use, to see how the document
looks in Netscape. Unfortunately the document isn't there anymore. He goes
back to Word, Word insists the document is still there! What is going on?

What has happened is that Word has locked the document but someone else
moved the document. Since Word continued to send in the lock token to the
old resource it appeared to Word that everything was fine. However when Hiro
went to use Netscape, which knew nothing of the lock token, the document was
gone.

Example #2 -

Irit is at work working on a document. Unfortunately people keep popping by
her office every five minutes to ask her questions. She really needs to get
some work done so she decides to go home. However she wants to make sure
that no one messes with her documents while she is going home. So she takes
out a long term lock on the document and then shuts down her computer. She
drives home and logs in from home. She tells her word processor to edit the
document. The word processor tells her that the document is gone! What
happened? She had a lock, who messed with her document?

What has happened is that the lock is still there but someone moved the
document. Since Irit's word processor doesn't know about this move there is
no way for her word processor find out where the document, with her lock
still on it, is. 
	BTW, if the document hadn't been moved then the word processor would
have gotten a lock error when it tried to lock the document, examined the
lock, saw that it belonged to Irit and started to use the lock token.
Because the document was moved the word processor never got the chance to go
through this process.

			Yaron