RE: RFC-2518 LOCK-TOKEN: header

The current locking semantics allow multiple clients operating under the
same principal the flexibility of using the same lock tokens. This assumes
a single principal is more aware of their concurrent clients than say a
distributed work group. It does not however allow any other principal to
reuse the lock tokens. So although I agree with Geoff that locking and
access control are orthogonal issues, requiring principal+lock token is
useful, and not at odds with access control. Locks are an access control
mechanism no matter how one looks at them. They temporarily remove write
access to anyone not owning the lock. This seems quite reasonable and
doesn't necessarily have anything to do with ACLs. I guess I fail to see
the confusion.

Recall that the source of this issue is that the DAV:activelock element
does not contain the principal owning the lock. So there is no way for a
user to obtain the lock tokens they own through the DAV:lockdiscovery
property . I think this needs to be fixed. Otherwise, the semantics of
locking, with respect to  what is submitted for access, seem fine.

Received on Monday, 31 January 2000 06:30:39 UTC