On Dec 20, 2005, at 11:23 AM, Julian Reschke wrote:
> Lisa Dusseault wrote:
>> I'm unhappy with the consequence of the GULP model that a DELETE of a
>> binding to a locked resource may or may not work depending on whether
>> that binding was the one locked. I propose to change it by requiring
>> that a DELETE of a binding to a locked resource needs a lock token.
>
> I still don't see concrete text, but anyway...
You could consider the current draft to hold concrete text.
>
> 1) The cost of locking a resource with multiple bindings will be
> significantly higher.
>
> 2) I don't see any gain to a client. The purpose of a lock is that
> while the resource is locked the client is protected from others
> moving away the resource, or modifying it's lockable state. Just
> protecting the binding that was locked achieves exactly that.
It's simpler for the client -- simpler client logic, fewer special
cases. In particular, it's a model that plain RFC2518 clients (clients
that haven't implemented any of BIND) can understand.
>
> 3) Multiple bindings to a resource cause the server behaviour to
> become more complex, yes. But the change you suggest doesn't help
> here; for instance it would mean that a client (without the lock
> token) is allowed to add a new binding to a locked resource, but not
> to remove it.
Since that's covered in the BIND request, which is not part of RFC2518,
I didn't see a need to get into that. DELETE is part of RFC2518 thus
we have to cover its behavior.
>
> As long as the model describes the semantics in RFC2518, and a client
> gets what it wants, I don't see any reason for coming up with a more
> complex model.
>
> So the summary is... Why does it matter, and how does that justify a
> more expensive implementation?
I'm not convinced it' s a more expensive implementation. The best case
for that argument is that it's a more expensive *server*
implementation, for those servers which implement BIND. It seems
simpler for everybody else.
It matters because of the behavior with clients that are not aware of
BIND.
Lisa