RE: Rejected Requirements

At 3:55 AM 5/30/97, Dylan Barrell wrote:
>>7. Only the owner of a lock or a principal with appropriate access rights
>>may remove the lock.
>>
>>8. Only the owner of a reservation or a principal with appropriate access
>>rights may release the reservation.
>
>What is the point of having a lock if it can be revoked by anybody? You
>might as well not bother!

Ooops, I just realized that in my last post I was giving rationale for why
the requirements should still be there, yet I was one of the ones that
originally recommended their removal!  Hopefully Judith won't kill me...
:-)

As I recall, the rationale for removing these requirements was to not
constrain the implementation, especially since they discussed access
rights, an area we haven't totally fleshed out yet. An overly strict
interpretation of this requirement might have implied that there should be
a precise definition of "appropriate access rights" which implies an access
control system.

The original requirement for locks was:

5.3.2.3. Unlock.  It must be possible to remove a lock.   Only the owner of
a lock or a principal with appropriate access right may remove the lock.

The recommendation was to remove the last sentence, leaving it as:

5.3.2.3. Unlock.  It must be possible to remove a lock.

This constrains the draft to have unlock capability, but doesn't overly
constrain the design.  An argument could be made, I'm sure, that it now
underconstrains the design, which is a matter of taste.

However, the points made in my last post still hold -- despite the lack of
a requirement, I fully expect a WebDAV server will allow a
superuser-administrator to remove locks, and the current draft does allow
the owner of a lock to remove the lock.

- Jim

Received on Friday, 30 May 1997 14:43:06 UTC