Re: Locks and loopback bindings

Geoffrey M Clemm wrote:

> Julian wrote on 12/03/2004 03:44:41 PM:
> 
>  > Jim Whitehead wrote:
>  >
>  > > Lock really should
>  > > ignore any loopback binding. While loopback bindings could 
> theoretically
>  > > have existed in the 2518 world, it really is only the introduction 
> of the
>  > > BIND specification that starts raising these issues with any urgency.
>  >
>  > Well, there are good reasons not to implement bind loops at all (this is
>  > why the spec explicitly allows servers to reject requests creating them,
>  > see DAV:cycle-allowed precondition for BIND). The presence of bind loops
>  > creates all kinds of issues, including those what to do with
>  > PROPFIND/depth:infinity and code that walks hierarchies and gets into
>  > infinite loops. I'm not surprised that Depth:infinity locks in bind
>  > loops are hard to handle, but IMHO that only means that one should avoid
>  > bind loops :-)
> 
> Bind loops are fine.  Depth:infinity applied to bind loops is what
> causes the problem.  As Julian indicates, how a particular server decides
> to handle Depth:infinity locks in the presence of bind loops (for those
> very rare servers, if any, that actually support this) will be very
> idiosyncratic to that particular server.  It may decide to fail
> a Depth:infinity lock applied to a loop, or it may decide to lock all
> the resources included in the loop.  Or it may decide to do something
> totally bizarre(:-) such as Jim's suggestion, that it lock only resources
> that aren't parents of the resource being locked.  We need to maintain
> a discrete silence here, since we really can't predict what a server
> will need to do, or be able to do, in a case like this.  But this is
> a very unlikely edge case, and therefore I believe doesn't merit any
> spec space devoted to it.
> 
>  > I remember that Geoff was actually defending the ability to have bind
>  > loops, so maybe he can offer some opinion about how locks should behave.
> 
> We will not be supporting depth locks in our loop-supporting repostories.
> 
>  > Personally, I'd say: "the way they are defined by RFC2518, and if this
>  > hurts, don't do it".
> 
> I agree, where by "don't do it", I assume you mean "fail an attempt to
> create the lock", and it's got a well-defined error code (506) it it
> decides to do so.

OK,

to summarize: as far as Geoff and I (as most recent editors of the spec 
is concerned), the intent indeed is that RFC2518 semantics apply, and 
this is the reason why the spec is silent on it.

Jim, does this settle the question, or should I add this to the 
document's issues list?

Regarding the process, I'd like to submit a new draft this week, and I 
think that one should be WG-last-called. If we do a 4-week last call, 
people of plenty of time to review it until mid of January.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 6 December 2004 10:48:36 UTC