Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks.

Lisa wrote on 12/28/2004 02:30:19 PM:
>
> I don't consider that this issue is resolved or fixed.  Here's what I 
> asked for in the bug text:
> 
> " - when a resource with bindings A, B is locked via a LOCK request to 
> A, what
> MUST the contents of the lockdiscovery property look like for both A 
> and B?

Whether or not a resource is mapped to multiple URL's (via bindings or
any other mechanism) has no effect on the lockdiscovery property.
So the lockdiscovery property is exactly what the locking protocol says
it will be when that resource is mapped to a single URL.

Since the binding protocol does not modify the definition of the
lockdiscovery property, I would object to it restating that definition,
especially since that definition may be revised in 2518bis.

>   - when a resource with bindings A, B is locked via a LOCK request to 
> A, how
> MUST the server respond to an UNLOCK request to B?"

That depends on how this question is resolved in RFC2518bis
(or preferably, in a separate locking protocol document split off from 
2518bis).
If an UNLOCK must be applied to the URL to which the original LOCK
request was applied, then it must be unlocked via an UNLOCK to A.
If an UNLOCK can be applied to any URL that identifies a resource
that is locked by that lock, then it can be applied to B.
This is the same question that arises in the context of a depth
lock, and the answer should be consistent.  As I recall, the last time
this was discussed, the group was leaning towards the latter (i.e. that
the UNLOCK can be applied to any URL that identifies a resource locked
by the lock), but this is a question that should/must be resolved by the
locking protocol, not be the binding protocol, if we want consistent
behavior defined.

> I would like to have requirements on the server behavior in these 
> cases, because otherwise it will be very likely for server implementors 
> to do slightly different things.

I would also like to have locking behavior defined, which is why I 
continue
to advocate splitting off the locking protocol from 2518bis for rapid
action.  But putting a couple of bits of information about the locking
protocol in the binding protocol that have a 50/50 chance of conflicting
with how the semantics are defined in the locking protocol makes no sense 
at all.

So I completely agree with Julian's marking this issue as resolved.

Cheers,
Geoff


> 
> Lisa
> 
> On Dec 21, 2004, at 2:44 AM, bugzilla@soe.ucsc.edu wrote:
> 
> >
> > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2
> >
> > julian.reschke@greenbytes.de changed:
> >
> >            What    |Removed                     |Added
> > 
----------------------------------------------------------------------- 
> > -----
> >              Status|REOPENED                    |RESOLVED
> >          Resolution|                            |FIXED
> >
> >
> >
> >
> >
> > ------- You are receiving this mail because: -------
> > You are the QA contact for the bug, or are watching the QA contact.
> >
> 
>