RE: Bindings, Locks, and MOVE

Phew!!! I couldn't believe what I was reading regarding write locks. What
use is a write lock that only sometimes is a write lock? Yikes. I'm glad
that is dead.

However there is still a point in the original post that concerns me. Let's
see if I understand the proposal:

When copying a resource into a tree that is currently locked then the lock
on that tree is lost?

Is that the proposal for how to handle locks at the destination of a copied
resource? That is my reading of the paragraph Judy provided.

		Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tue, September 07, 1999 7:19 AM
> To: 'Greg Stein'; w3c-dist-auth@w3.org
> Subject: RE: Bindings, Locks, and MOVE
> 
> 
> Thanks for bringing the discussion back to earth.
> 
> I agree with you that the compromise of saying that servers 
> SHOULD protect
> the path of the Request-URI used in locking a resource is a 
> poor one.  It
> doesn't respond to the issue that was raised, and it 
> needlessly muddies the
> waters for clients, which now don't know whether the path 
> will be protected
> or not.
> 
> I like your suggestion that we keep the MUST language, but 
> state that it
> applies only to write locks.
> 
> --Judy
> 
> 
> > -----Original Message-----
> > From: Greg Stein [mailto:gstein@lyra.org]
> > Sent: Friday, September 03, 1999 3:24 AM
> > To: w3c-dist-auth@w3.org
> > Subject: Re: Bindings, Locks, and MOVE
> > 
> > 
> > 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
> > 
> > Edgar Schwarz wrote:
> > > 
> > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote:
> > > 
> > > >    From: ccjason@us.ibm.com
> > > >
> > > >    <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.
> > > >
> > > > <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.
> > > 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
> > > 
> > > --
> > > Edgar.Schwarz@de.bosch.com 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.
> > 
> > --
> > Greg Stein, http://www.lyra.org/
> > 
>

Received on Tuesday, 7 September 1999 20:49:16 UTC