W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1997

state token and lock token confusion

From: Jim Davis <jdavis@parc.xerox.com>
Date: Mon, 27 Oct 1997 15:02:51 PST
Message-Id: <>
To: w3c-dist-auth@w3.org
I am very confused about State tokens and Lock tokens.  I've read the spec
over and over and I am still confused.  Doubtless the following questions
have easy and obvious answers, and you should take them as indicating that
the language in the current spec is such that even well meaning and
somewhat clueful people can't understand what is meant, rather than as a
criticism of the design.

The spec (5.4.2) says "A lock token is a type of state token".  Then why
don't the examples of LockToken corresond to the syntax for State Tokens?
A State Token is supposed to begin with the string "StateToken" and contain
at least a Type and a Resource, but the only examples of Lock Token I see
are the Opaque ones, which don't do any of these things.

Moreover, the language of State Tokens (4.1.2) says "A state token must be
self describing such that upon inspecting a state token it is possible
to determine what sort of state token it is, what resource(s) it applies
to, and what state it represents."  I don't see how any of these properties
are tue of opaque lock tokens.

but my real confusion is how I could use State Tokens in a conditional
header for states of resources on different servers.  Suppose I want to
make an operation on resource R11 on server S33 conditional on resource
R259 on server S4 being in state Q1.   Okay, I see how to create  a state
token that names the condition, and I see how to pass it in an
If-State-Match header to S33.  What I don't see is how does S33 contact S4
to determine whether this state applies, and what guarantee S4 provides to
S33 that this state will remain true.  

In fact, I really can't see what use State Tokens are, except for Lock
Tokens, which I certainly see the use for.

Could someone enlighten me, even a little?



Received on Monday, 27 October 1997 19:03:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:12 UTC