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 10:23:53 UTC