Subject: RFC 3744: Modifying ACEs

From: Werner Donné <[email-masked]>
Date: Sat, 05 May 2007 12:51:19 +0200

Hi,

Section 8.1 suggests that ACEs can be modified. In order to do
that it should be possible to match a modified ACE with the ACE
it modifies. How then is an ACE identified? As far as I can see
an ACE is only identified by its weak identifier.

Regards,

Werner.
-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: [email-masked]

---

From: Werner Donné <[email-masked]>
Date: Mon, 07 May 2007 09:40:28 +0200

This is a matter of concurrency control. If we compare it to
SQL transactions, then using a lock corresponds to the
isolation level SERIALIZABLE. Without a lock it corresponds
to READ COMMITTED. There is no general rule as to which
isolation level is best in all circumstances.

If the matter is left to the client there is no guarantee
of serializability, because some client may not use a lock.
This can lead to schedules like this:

PROPFIND1
LOCK2
PROPFIND2
ACL2
UNLOCK2
ACL1

A possible way to enforce serializability is for the server
to return an exclusive write lock with a short time-out in the
PROPFIND response. The ACL method would only succeed if the
lock token is present and the ACL method would implicitly
release the lock. If another client performs a PROPFIND for
the "acl" property between both operations, it will not get an
implicit lock. The second client would be required to do a new
PROPFIND if it wants to perform an ACL. Otherwise it was just
consulting the "acl" property.

Werner.