RE: Bindings, Locks, and MOVE

Music to my ears.

> -----Original Message-----
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
> Sent: Wednesday, September 08, 1999 5:53 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: Bindings, Locks, and MOVE
> 
> 
> 
> 
> Copying a resource into a destination collection that is 
> locked requires the
> principal to own the lock, and provide its lock token in an 
> If header. The
> resouce inherites the lock of its new parent collection, the 
> lock is not removed
> from the parent. However, if the resource was locked, then 
> the lock is not
> copied. The lock state of the new destination resource is 
> determined by its new
> parent collection, not any lock the source resource might have had.
> 
> 
> 
> 
> 
> "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com> on 
> 09/07/99 08:49:07
> PM
> 
> To:   "'Slein, Judith A'" <JSlein@crt.xerox.com>, "'Greg Stein'"
>       <gstein@lyra.org>, w3c-dist-auth@w3.org
> cc:
> 
> Subject:  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 Wednesday, 8 September 1999 16:05:53 UTC