W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2000

Re: Lock Tokens

From: <jamsden@us.ibm.com>
Date: Tue, 11 Apr 2000 09:23:52 -0400
To: w3c-dist-auth@w3c.org
Message-ID: <852568BE.004A0375.00@d54mta03.raleigh.ibm.com>


Juergen,
These are common locking problems. See some comments below in <jra> tags.


|--------+---------------------------->
|        |          Juergen Reuter    |
|        |          <reuterj@ira.uka.d|
|        |          e>                |
|        |          Sent by:          |
|        |          w3c-dist-auth-requ|
|        |          est@w3.org        |
|        |                            |
|        |                            |
|        |          04/10/2000 07:17  |
|        |          PM                |
|        |                            |
|--------+---------------------------->
  >----------------------------------------------------------------------|
  |                                                                      |
  |       To:     w3c-dist-auth@w3.org                                   |
  |       cc:     reuterj@ira.uka.de, jjh@ira.uka.de                     |
  |       Subject:     Lock Tokens                                       |
  >----------------------------------------------------------------------|




Hi, all!

Section 12.1.2 of WebDAV defines:

<!ELEMENT locktoken (href+) >

and says:

"The href contains one or more opaque lock token URIs which all
refer to the same lock (i.e., the OpaqueLockToken-URI production in
section 6.4)."
<jra>
DAV4J only supports one at the moment, but I have a bug entry to fix this.
Don't know when it will get done though.
</jra>

I wonder, in what cases there could actually occur multiple href
elements and how they could be useful:
<jra>
I couldn't think of any.
</jra>

* Section 6.3:
  "A lock token is a type of state token, represented as a [single?] URI,
  which identifies a particular lock."
  This contradicts the above definition.

* Section 9.5:
  'Lock-Token = "Lock-Token" ":" Coded-URL'
  ...
  "The Lock-Token response header is used with the LOCK method to
  indicate the lock token created as a result of a successful LOCK
  request to create a new lock."

  In other words, a server will return a *single* lock token URI as
  Coded-URL in the Lock-Token header.  But what will be returned in
  the locktoken XML element of the corresponding response message body?
  The same single URI?  Or all URIs?  Section 6.3 says: "A lock token
  is returned by every successful LOCK operation in the lockdiscovery
  property in the response body ..."  So, is the Lock-Token header
  needed at all?  Anyway, what are multiple URIs for a single lock token
  useful for?
<jra>
The Lock-Token header contains the lock just granted by the LOCK method.
The XML element returns a lockdiscovery that contains all the (shared) lock
tokens for the target resource. The Lock-Token header is needed because the
activelock element of the lockdiscovery does not identify the principal
owning the lock. The owner element is not an authentication id or
principal.
</jra>

* Section 13.8:
  Does the lockdiscovery property contain all URIs of a lock token?
<jra>
It does. The question is, does an individual lock token entry contain more
than one href. I don't see why.
</jra>

* Example 8.9.6:
  "In this example the client has submitted a number of lock tokens with
  the request."
  For better understanding, I propose to change the wording, maybe
  into something like:
  "In this example the client has submitted a number of lock token URIs
  with the request, where each URI represents a lock token."
  Otherwise, all the URIs could refer to the same, single lock token.

* Section 8.10.4: "A successful result MUST return a single lock
  token ...", but this single lock token may contain multiple URIs,
  right?

Comments?

Bye,
     Juergen
Received on Tuesday, 11 April 2000 09:28:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:54 GMT