RE: New issue (?): locktoken (12.1.2) syntax

I agree with Julian that it makes more sense to have
each instance of a shared lock have its own timeout value
and lockowner, so I also vote to limit the number of
URI's for a given lock to be exactly one.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, July 11, 2002 5:37 AM
To: Jason Crawford; w3c-dist-auth@w3.org
Subject: RE: New issue (?): locktoken (12.1.2) syntax



Jason,

a few thoughts.

- a lock is a resource (by definition: it's identified by a URI)
- a lock token is a URI
- one could identify LOCK with BINDing the lock token to the lock resource
and UNLOCK with deleting the lock token, and that wouldn't affect the basic
functionality of shared locks

However, the difference is that if we have a 1-1 relation between lock
tokens and lock resources, each lock will have it's own timeout value and
owner, and I think this is what's implemented in moddav and IIS. So I think
the spec should reflect that.

Julian


-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Jason Crawford
Sent: Thursday, July 11, 2002 5:48 AM
To: Julian Reschke
Cc: w3c-dist-auth@w3.org
Subject: Re: New issue (?): locktoken (12.1.2) syntax


<<
Question: why would multiple lock tokens refer to the same lock? And *if*
there are multiple URIs referring to the same lock (a consequence of
BINDs???), what's the point in reporting more than one? Is anybody using
this? Has interoperability been tested?
>>
That caught me by surprise. But you made me read a bit and I did
uncover the following. Apparently in the case of a shared lock
it's considered the same lock, just different tokens. It's not
clear they actually mean that with the following wording, but the
following is just one of several places where they use the same
sort of wording.

7.2 Write Locks and Lock Tokens

  A successful request for an exclusive or shared write lock MUST
  result in the generation of a unique lock token associated with the
  requesting principal.  Thus if five principals have a shared write
  lock on the same resource there will be five lock tokens, one for
  each principal.


This leaves me perplexed about how UNLOCK works for shared locks. I
suggest we (1) check with Yaron if this was intentional and get an
explanation and (2) make it clear that each lock has one token and a
shared lock means that multiple locks are acting on a resource, not
just multiple tokens. (Does anyone know how to contact Yaron?)

J.

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com

Received on Thursday, 11 July 2002 08:53:44 UTC