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

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 23 Oct 1999 11:56:52 -0400

OK, now that the new versioning protocol draft is out the door,
time to get back to locking (:-).

I'll try out the: "Simplified RFC-2518 Locking, Version-2" proposal
against the issues raised here.

   From: [email-masked]

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

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

<gmc/> The server has to remember the association of a lock token with a
particular resource.  Since this is the server, it doesn't need to
use some URL ... it just keeps a handle on the resource that
is independent of the http URL space.

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

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

Right.

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

And if we do not support depth locks, the issue goes away completely (:-).

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

<gmc/> Right.  The client uses the lock token for all requests on a
locked resource, rather than only using them for requests that might
update the locked resource.

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

<gmc/> Also note that a human would always need a client doing the real
work in a locking context, since it is unlikely that a human ever would
or could remember the lock token strings that are needed to work with a
locked resource.

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

<gmc/> Without depth locking, the lock token is all that is needed.

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

<gmc/> If the server just keeps track of what resource is locked by
a particular lock token, then remapping just consists of returning
a valid URL to that resource in a 302.

   <jc/> 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.  :-)

<gmc/> Associating a lock token with a single resource until
it is unlocked is probably even easier (:-).

Cheers,
Geoff

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 23 Oct 1999 13:38:12 -0400

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

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

Using the updated proposal where a process gets back a 302 when it
tries to access a locked resource that has moved, word will have to
update its path to the document the next time it accesses it for read
or write.  When it does so, the user will know to look
at the new place in a different process.

Also note that a user is already used to some difference between what is
seen in the process that has the lock and another process that does not.
In particular, any changes that have not yet been saved will only appear
in the process with the lock.

   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?

Probably somebody who had a good reason do so (perhaps fixing a bad
copyright statement in her document).  In either case, there is no
lost update problem, since she has no pending updates to the document
(except for those only in her head, which we can't take responsibility
for :-).

My generic response to this situation: locks are great for preventing
lost updates.  You LOCK,GET,edit,PUT,UNLOCK.  The faster you get in and
out with your lock, the better.  If you want to leave the world locked
up so that your job is easier, you're ignoring the needs of all the
other people that need to get their jobs done.

With the speed of development and deployment being forced by "internet time",
I believe the days of locking up the world to get long-term stability are over.

Cheers,
Geoff

---

From: [email-masked]
Date: Sun, 24 Oct 1999 21:16:56 -0400

<gmc/>

Geoff, you're "forgetting" about depth locks again.  :-)  Multiple
resource can have the same lock token.  So providing a lock token
doesn't uniquely define what resource you're acting on.   The server
needs a mapping for  URI + token ->  resource.

My posting above predates your most recent proposal.   I believe
it's the case in the recent proposal that the server only needs to
remember one URI for a single resource/lock pairing.  Even if the
resource moves, it's only
the URI used when the lock was first created that needs to be
remembered by the server.  But no... it's not that easy.

(1) If we say that, then it's up to the client to remember that
   original URI even if redirected... just in case it gets moved again.  If
   the server is unable to redirect after a second move, then I
   assume the
   client can detect (via etag-uri combination) that there's
   been a second movement, and will reinvoke a method based on
   the original  URI and lock token... just to determine where
   it has moved to again.  Anyway, the point is that if the
   server doesn't remember a second URI, then the client must
   remember the first URI.

(2) If the server remembers all URI's, then the client is relieved of
   this burden.

   (1&2) BTW, in either case, the client has to use etags because
   in the presence of depth locks where multiple resources can
   have the same locktoken, and if namespace manipulation has
   occured, a URI+token to resource mapping may not be unique...
   and I don't think a client can trust a server to somehow
   detect a collision and somehow do "the right thing".  This
   is an admittedly rare thing... but if the client cares,
   they have to use uri-tagged etags.

whoops! I don't mean etags... I mean guid tags... but we
don't have that yet.  It would need to be added to the spec.

BTW, after the URI+token->resource mapping is done within the
server, it also needs to do a resource->URI mapping so that it
knows what to return.  And of course if all bindings to the
resource have been removed, the server will need to generate
a binding/URI for that resource so that there is a URI to which
to redirect the request.

   <gmc/>

   <gmc/>Right.

Given the exchange that I've heard between Yaron and company, I'd
like to propose that the client also have some say over this.  If
the client wants the URI protected, he can request it.  I suppose
that would have to be a FLAG on the lock request.  If the server
can't respect the request, it has to fail the lock.  I suppose
we'd need an error code or something to express this so that a
client could deal with that particular failure programaticly.

I think you've mentioned that before.  :-)

guid tags too I guess... as soon as we invent them.  It doesn't seem
like a huge burden but it could be.  If a client cares enough about
all this to do the guid tag stuff... then they also have to collect
guids for all resource that it locked.  That's a bunch of state for
the client to remember rather than just a single URI that is the
root of his lock.  Especially in some of Yaron's scenarios.

Yup.

Also correct.

I think you missed my point.  It single resource can have multiple
URI's so we need to do what I mentioned above, which
is a pain, or we need to say that simply finding a resource (perhaps at
a different URI) and doing lock discovery to get a token won't work because
the person doing the lock discovery doesn't know the URI that the server
is protecting (via remapping in this case).  No
biggie.  We don't get this with protected URI's either.  I think we just
need to remind clients of this.  -- BTW, this could be done if lock
discovery also provides a URI that supports the remapping.  But then a
client that tries this lock discovery approach
would be at the mercy the lock owner who could
MOVE the resource and unlock it before the second entity finds out.  Anyway,
this seems like another use of lock discovery that should be deprecated.

BTW, do we require that one be the lock owner to use the token for this
purpose?  So if one application wants to pass the URI of a resource to
another application... it also needs to pass a lock (and perhaps a guid).
But if the second application isn't logged on as the first person, then?

One other thing, the proposal would also have to clarify the target selector
header.  Well, maybe not HAVE TO.  The problem I'm refering to is that for
binding related requests like DELETE, BIND, MOVE, it isn't just the target
that is important to be specified, but also the parent.  It's the binding
between the two that we want to specify.   I had a target selector based
solution to this in mind, but I think the real solution is to have guid
tags for both parent and the resource in the request.  If the guid check
fails on either the parent or target, the client can try to figure out what
to do.  -- Another
approach is to lock both the parent and the child... but if the redirected
URI for the DELETE isn't the one that uses the parent, then you'd not get
the right affect, so you'd still want the guid check anyway.  That really
seems to be the best approach in a server that lacks lock URI protection.

Anyway, I propose that the **client** be able to specify if it needs the server
to protect the LOCK URI.  If the client specifies this and the server can't
support it, it must reject the request with a new unique response code
and the client figures out how to deal with that.

J.