Re: RFC-2518 LOCK-TOKEN: header

   From: jamsden@us.ibm.com

   Some corrections and comments below in <jra> tags, but in summary, the
   owner element is not sufficient to identify the owner of a lock,

It is sufficient if it is just information that a client wants to
present to the user to help her decide whether she wants to cancel
(UNLOCK) an existing lock.

   and is not used by the server in any way.

I agree.

   It is purely a mechanism for clients to
   provide some more meaningful indication of the owner of a lock.

I agree.

   The authentication mechanisms are not specified by HTTP (although WebDAV
   does specify Digest and Basic for secured connections), but the
   authentication header is used by WebDAV to identify the user agent making
   the request, and it is this header that is used to determine if the
   requestor is the owner of the lock.

I have found no reference to an "authentication header" in rfc2518,
neither in terms of defining it, nor in terms of using it.

I have made this point in several postings ... and will continue
to do so until acknowledged or refuted (:-).

   The lock discovery element does not contain this information.

Which should come as no surprise, since the authentication header
is not defined (:-).

   "A lock token is a type of state token, represented as a URI, which
   identifies a particular lock.  A lock token ... can also be found
   through lock discovery on a resource."

   <jra>
   Yes, but you can't figure out which ones are yours.
   </jra>

For the purposes of the user deciding whether to cancel an
existing lock, the DAV:owner information should be sufficient.

   "User agent authentication has previously occurred via a mechanism
   outside the scope of the HTTP protocol, in an underlying transport
   layer."

   <jra>
   Its this user agent, identified by the authentication header, that is used
   to actually enforce locks. As far as the server is concerned, the lock
   token just goes on for the ride. It has to be specified, and the user agent
   has to own the lock, but otherwise the lock token isn't used.
   </jra>

Yes, for authenticated access control, a lock token is pointless -
one indication that the WebDAV locks are not the appropriate protocol
mechanism to support authenticated access control.

      The lock tokens are in
      the lock discovery, but you can't figure out which ones you own.

   This information is provided by the DAV:owner element in the
   lockdiscovery property.

   <jra>
   This is not the owner information used by the server to identify the owner
   of the lock. Rather it is client information used to provide a more
   meaningful indication of the owner of the lock for contact information. Use
   of this element for identifing lock ownership would create an
   interoperability problem because the actual contents are not specified in
   the WebDAV spec.
   </jra>

As long as this information is just presented to the user, there is
no need for detailing the actual contents.

      I continue to believe this is an open issue that requires clients to
      persist their lock  tokens outside the WebDAV repository. Lock tokens
   are a
      pain enough for the rare case where they are actually useful.

   How else do you handle the situation where the same principal has
   several clients acting against the same resource?  I believe this will
   be a common scenario.

   <jra>
   Yes, and lock tokens will be marginally useful for this situation. The only
   thing that can be done is a client can know if it got the lock from a LOCK
   request, or by some other means (IPC, reading from a file, from the
   DAV:lockdiscovery element, etc.). A client obtaining the lock from some
   other means can only assume that there might be other clients operating
   concurrently under the same principal, and can offer a warning before
   overwriting the resource.
   </jra>

A lock-token is not used by a client because it discovers it on a
resource ... it is only used if that client obtained that lock-token
through a LOCK request.  This guarantees that you will not have a
merge conflict amoung cooperating clients, which makes it very useful.
A client that wants to "steal" a lock, does so by unlocking the resource
and then requesting its own lock with a new LOCK request.

You could require that only the principal issuing a LOCK can "steal"
the lock, but this should be a client-controlled ACL issue, *not*
something hard-wired into the protocol.

Cheers,
Geoff

Received on Wednesday, 26 January 2000 23:57:25 UTC