RE: Change to Lock-Token

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."

However Roy pointed out that this behavior is illegal. That the HTTP WG,
against his vociferous recommendations, decided to make the if-match
header only available for e-tags. As such the benefit of making lock
tokens look like e-tags is removed. We have no choice but to introduce
our own equivalent of if-match. At that point, we can make our lock
tokens look any way we desire.

		Yaron

> -----Original Message-----
> From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
> Sent:	Tuesday, March 25, 1997 5:05 PM
> To:	masinter@parc.xerox.com; w3c-dist-auth@w3.org
> Subject:	Re: Change to Lock-Token
> 
> >> 2) Identity.  While a strong entity tag will correspond to the
> resource
> >> when a lock is taken out on that resource, as soon as the resource
> is
> >> changed its entity tag (strong for sure, weak potentially depending
> on the
> >> scope of the change) will also need to change.  If intermediate
> results are
> >> saved to the HTTP server before the lock is released, the lock
> token will
> >> no longer correspond to the actual entity tag of the resource.
> >
> >This is a good argument for why lock tokens shouldn't be used as
> entity
> >tags, then.
> 
> Hmm.  This is true.  However, perhaps I am confused on the benefit of
> using
> an entity tag as a lock token.  I thought the benefit was that you get
> some
> extra capability (unstated) by exploiting the equivalence of lock
> tokens
> and entity tags.  However, since they are not guaranteed to be the
> same, it
> then appears that an entity tag is only a convenient token which can
> be
> reused at the time the lock is granted, thus gaining a small
> efficiency
> advantage.  Was this the intent?
> 
> However, that discussion is probably moot.  Previously I wrote:
> 
> >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 Wednesday, 26 March 1997 14:54:15 UTC