Re: Draft Minutes from IETF WEBDAV BOF

At 5:14 PM 1/6/97, Sean Shapira wrote:
>In his draft minutes of the IETF meeting, Jim Whitehead wrote:
>
>> LOCKS.
>> [...]  It was observed
>> that the proposed "read lock" was really a convenience access control
>> function to modify the read permissions on a resource, and that a read lock
>> might not really be a lock.
>
>More generally, I believe there was discussion regarding whether
>sufficient distinctions were being made within the DAV effort
>between access control functionality (designed to ensure changes
>are made by those who have permission) and database locking
>functionality (designed to ensure the logical integrity and
>consistency of all operations performed on possibly changing
>information).

Agreed.  I'll clarify this in the minutes.

I also agree that our locking was blurring the distinction between access
control and serialization control.  This was partly intentional.  While I
personally believe that defining a Web access control scheme would be very
beneficial to the DAV activity, I also know that developing such a scheme
would significantly delay the development of a DAV protocol specification.
Hence there was an early decision not to explicitly address access control,
at least in the first rev. of this working group's activities.  Given this,
the "locks" initially proposed can be viewed as both locks, and a simple
access control scheme.  The initial locking proposal has since received
significant critical attention, much of it negative.

At the recent Design Team meeting (notes from this meeting are currently
being revised prior to being posted to the list) a decision was made to
limit the scope of locking activity specified to only exclusive write
locks, which can exist on either partial resources (byte ranges), or whole
resources.  The semantics of a write lock is that only the owner of a write
lock may modify the locked resource.  Locking is now completely orthogonal
to access control, so it is entirely possible (but useless) to have a write
lock on a resource on which a user does not have write permission.

>This highlights the tension between the authoring and versioning
>communities represented at the meeting.  From an authoring perspective,
>these "assisted move" operations will be required functionality of
>any competitive product.  From a versioning perspective, assisted move
>operations appear as compound operations requiring the renaming of one
>document in a repository and the simultaneous modification of several
>others.

The question is really whether "assisted" | "magic" move should be in the
HTTP interface to the repository.  I totally agree with you that assisted
move should be in the *user* interface of an authoring tool.   However, I
think the burden of proof rests on you to explain why assisted move should
be part of the semantics of MOVE, especially since HTTP is an
object-oriented protocol, and hence the scope of almost all methods is the
resource to which they are addressed.  Having side-effects on other,
non-specified resources seems very undesirable from both an authoring and a
versioning standpoint.  When a user requests an operation, they need to
know exactly what action will take place, and which resources will be
affected.  Failure to do this will result in a lack of user understanding
and confidence in the functionality.

- Jim

Received on Monday, 6 January 1997 21:29:31 UTC