RE: Change to Lock-Token

I'm sorry, I thought we agreed that lock tokens had to be unique across
space and time at the Irvine meeting. I didn't realize it was an open
issue. If it is, I'm with the 6 foot tall Chair Dude. =)
		Yaron

> -----Original Message-----
> From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
> Sent:	Wednesday, March 26, 1997 5:49 PM
> To:	Yaron Goland; w3c-dist-auth@w3.org
> Subject:	RE: Change to Lock-Token
> 
> Yaron Goland wrote:
> >I was never arguing that lock tokens should be entity tags. What I
> was
> >arguing for was that the format of a lock token should be the same as
> an
> >entity tag. This would have, I thought, given us the benefit of being
> >able to use lock tokens in if-match headers and thus be able to say
> >things like "Don't execute this message unless my lock still exists."
> 
> OK, to my mind it is settled that entity tags should not be used as
> lock
> tokens because they are not unique enough (due to the case of multiple
> advisory locks against the same resource), and because they cannot be
> reused in if-match headers.
> 
> However, just how unique lock tokens must be has not yet been settled.
> Based on the argumentation in my previous post, it seems that lock
> tokens
> might need to be globally and temporally unique.  That is, if my DAV
> server
> generates a lock token, it is guaranteed to be unique across all other
> DAV
> servers, and for all time.  Or does a lock token just need to be
> unique for
> a few weeks (i.e., should a client be required to expire a lock token
> if it
> has held onto it for too long?)
> 
> I have re-copied my rationale for this to the end of this message:
> 
> >>1) Uniqueness. According to my reading of the HTTP 1.1
> specification, an
> >>entity tag (strong or weak) need only be unique for a given
> resource.  DAV
> >>has the extra requirement that lock tokens must be unique across an
> HTTP
> >>server (and perhaps even globally unique).  Lock tokens are the
> "key" for
> >>DAV locks, and hence having as unique a key as possible is very
> desirable.
> >>Note that DAV locks are not a substitute for strong authentication
> working
> >>with an access control scheme.
> >
> >Thinking through this some more, I have recalled more of the
> rationale for
> >why uniqueness constraints cause entity tags to be insufficient as
> lock
> >tokens.
> >
> >1. If multiple advisory locks are allowable on the same resource
> (advisory
> >locks are currently not in the specification, but they are in the
> >requirements as reservations), and they use the same lock tokens as
> >exclusive write locks, then multiple simultaneous locks might be held
> on
> >the same resource.  In this case, the entity tag is not sufficient,
> since
> >each lock needs a separate lock token to distinguish it from other
> locks on
> >the same resource.  However, this does not argue for global
> uniqueness,
> >only more uniqueness than is provided by a minimally unique entity
> tag.
> >
> >2. If a single server is acting as the coordinating agent for several
> >separate servers (such as might be the case for a large-scale
> >implementation of WEBDAV which handles high numbers of users), having
> a
> >lock token which is unique across those cooperating servers allows
> them to
> >map a lock token back to the server which handles it.  This argues
> for
> >uniqueness across those cooperating servers.
> >
> >3. If you look to a future when a protocol will hopefully exist to
> support
> >a whole Internet of coordinating WEBDAV servers, the lock tokens need
> to be
> >unique across the entire Internet, and hence globally unique.
> >
> >4. Since lock tokens may be held by a client long after they have
> been
> >expired by the server, lock tokens must also be temporally unique
> (unique
> >across time), since otherwise there is the potential that a client
> may hold
> >an expired lock token which coincidentally matches a current token
> (taken
> >out later by another person).  If a lock was taken out on a resource
> by
> >person A and the lock token is the entity tag E, and no edits were
> >initially written to that resource, and the lock expires, and then
> person B
> >takes out another lock on the resource which is also granted the same
> >entity tag E, person A could then potentially write to the same
> resource
> >(unless it was caught by authentication).  This argues against the
> use of
> >entity tags as lock tokens.
> 
> - Jim
>

Received on Thursday, 27 March 1997 00:42:25 UTC