resource, the set of principals who have taken out a shared lock also
   must trust each other, creating a (typically) smaller trust set
   within the access permission write set.

   Starting with every possible principal on the Internet, in most
   situations the vast majority of these principals will not have write
   access to a given resource.  Of the small number who do have write
   access, some principals may decide to guarantee their edits are free
   from overwrite conflicts by using exclusive write locks.  Others may
   decide they trust their collaborators will not overwrite their work
   (the potential set of collaborators being the set of principals who
   have write permission) and use a shared lock, which informs their
   collaborators that a principal may be working on the resource.

   The WebDAV extensions to HTTP do not need to provide all of the
   communications paths necessary for principals to coordinate their
   activities.  When using shared locks, principals may use any out of
   band communication channel to coordinate their work (e.g., face-to-
   face interaction, written notes, post-it notes on the screen,
   telephone conversation, Email, etc.)  The intent of a shared lock is
   to let collaborators know who else may be working on a resource.

   Shared locks are included because experience from web distributed
   authoring systems has indicated that exclusive locks are often too
   rigid.  An exclusive lock is used to enforce a particular editing
   process: take out an exclusive lock, read the resource, perform
   edits, write the resource, release the lock.  This editing process
   has the problem that locks are not always properly released, for
   example when a program crashes, or when a lock owner leaves without
   unlocking a resource.  While both timeouts and administrative action
   can be used to remove an offending lock, neither mechanism may be
   available when needed; the timeout may be long or the administrator
   may not be available.








 
RFC 2518                         WEBDAV                    February 1999


6.2 Required Support

   A WebDAV compliant server is not required to support locking in any
   form.  If the server does support locking it may choose to support
   any combination of exclusive and shared locks for any access types.

   The reason for this flexibility is that locking policy strikes to the
   very heart of the resource management and versioning systems employed
   by various storage repositories.  These repositories require control
   over what sort of locking will be made available.  For example, some
   repositories only support shared write locks while others only
   provide support for exclusive write locks while yet others use no
   locking at all.  As each system is sufficiently different to merit
   exclusion of certain locking features, this specification leaves
   locking as the sole axis of negotiation within WebDAV.

6.3 Lock Tokens

   A lock token is a type of state token, represented as a URI, which
   identifies a particular lock.  A lock token is returned by every
   successful LOCK operation in the lockdiscovery property in the
   response body, and can also be found through lock discovery on a
   resource.

   Lock token URIs MUST be unique across all resources for all time.
   This uniqueness constraint allows lock tokens to be submitted across
   resources and servers without fear of confusion.

   This specification provides a lock token URI scheme called
   opaquelocktoken that meets the uniqueness requirements.  However
   resources are free to return any URI scheme so long as it meets the
   uniqueness requirements.

   Having a lock token provides no special access rights. Anyone can
   find out anyone else's lock token by performing lock discovery.
   Locks MUST be enforced based upon whatever authentication mechanism
   is used by the server, not based on the secrecy of the token values.

6.4 opaquelocktoken Lock Token URI Scheme

   The opaquelocktoken URI scheme is designed to be unique across all
   resources for all time.  Due to this uniqueness quality, a client may
   submit an opaque lock token in an If header on a resource other than
   the one that returned it.

   All resources MUST recognize the opaquelocktoken scheme and, at
   minimum, recognize that the lock token does not refer to an
   outstanding lock on the resource.




 
RFC 2518                         WEBDAV                    February 1999