Subject: Re: Bindings, Locks, and MOVE

From: [email-masked]
Date: Thu, 2 Sep 1999 17:50:41 -0400

<JS>
This discussion began with Yaron's comment that saying that "it MUST NOT be
possible for a principal other than the lock owner to make a locked resource
inaccessible via the URI mapping used to lock the resource" is too strong.
It may make sense for write locks as defined in RFC 2518, but may not make
sense for other sorts of locks that don't restrict MOVE and DELETE.
</JS>
I believe that this is not specific to any particular type of locks.  All
clients need to insure that they have at the very least a way to unlock
the the locks they have created.  I assume that to unlock (a resource), we
have to provide a URI of a (the?) resource locked by that lock... so if
someone else changes the URI, it's
very likely that we're not going to be able to figure out what the new
URI is... and will have to leave the lock around until it times out.

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 2 Sep 1999 21:44:23 -0400

From: [email-masked]

   <JS>

<gmc> Since the server needs to deal with this in case the client just
neglects to remove the lock, and if having another client MOVE your
locked resource is a rare occurrence (which I believe it is), then
this does not seem to be especially problematical.

Cheers,
Geoff

---

From: Edgar Schwarz <[email-masked]>
Date: Fri, 3 Sep 1999 08:29:55 +0200 (MESZ)

> this does not seem to be especially problematical.
Would it be possible to say:
  If a locked resource is moved the server SHOULD create a indirect
  reference resource which should exist for some sensible time.

Yes I know, it's complicating the server :-)
I imagine the above happening perhaps when somebody is reorganizing
a directory structure and deep in the collections there are some
locked resources.
So the lock owner at least has a decent chance to find out where his
resource has gone to.

Regards, Edgar

-- 
[email-masked] ON/EMS1, 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: Greg Stein <[email-masked]>
Date: Fri, 03 Sep 1999 00:23:33 -0700

This whole thread (post-Judy's message) seems to be picking out a very
minor detail of her post. Personally, I find this nit-picking of detail
counter to the goal of her original post: "test its conclusions with the
mailing list members."

For myself (and mod_dav), the first "AGREED" portion makes complete
sense, and I do agree with it.
[btw, is *anybody* going to be implementing cross-server MOVE/COPY? is
it necessary to have that feature in the spec at all? of the umpteen DAV
servers out there now, I don't know any that do this or plan to do this.
It would be nice to cut the thing and not worry about it.]

The second "AGREED" portion does not make a whole lot of sense. The
commentary states that the position is too strong [because it might not
make sense with other types of locks]. Are there other locks out there?
Do people have concrete, useful examples? I haven't heard of anything
besides a write-lock yet. Regardless, I think it should be enforced in
the spec that a write-lock MUST have guaranteed protection of the
Request-URI. Put in some language that says other locks can define the
MUST/SHOULD nature of protection. Otherwise, leave it in the intuitive
state: a write lock says that others cannot monkey with your URI.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: John Stracke <[email-masked]>
Date: Fri, 03 Sep 1999 09:03:48 -0400

> servers out there now, I don't know any that do this or plan to do this.

It's still early, though.

> It would be nice to cut the thing and not worry about it.]

I dunno.  I certainly appreciate not wanting to implement it; it's going to be a
marginal case, especially since you can't expect that the request's WWW-Authenticate:
will work for both servers.  But it has the potential to be a really *useful* marginal
case.  :-) As long as the protocol designers are willing to expend the thought to make
it work, and as long as the results don't overcomplicate the base case, I'd say leave
it in.

It occurs to me that one possible way to implement it would be in a proxy, which, in
response to a cross-server COPY, would do what sitecopy does.  Such a proxy could live
out on a fast backbone site, providing services that would take too long if the client
did them itself over a slow link; and it could store the user's credentials for
various servers, so that it could provide the right credentials to each server it
talks to.

--
/============================================================\
|John Stracke    |http://www.ecal.com|My opinions are my own.|
|Chief Scientist |===========================================|
|eCal Corp.      |Speak softly and carry an Illudium Q-32    |
[email-masked]|Explosive Space Disintegrator.             |
\============================================================/