RE: state token and lock token confusion

Jim, you're right. We have settled the issue by ripping out all the state
token language but the text on the if-state-match and if-not-state-match
headers. So all the state token requirements are now GONE but one - state
tokens must be URIs.

As for your scenario, the point of state tokens is that we knew that SOMEDAY
there would be mechanisms to do the sort of thing you are talking about.
However they aren't here today. So what we wanted to do was create a
framework which would not prevent the introduction of such features in the
future. It turns out that the only key feature we needed today was scoped
names for state tokens which URIs provide. I also suspect that all state
tokens need to be globally unique but we are only requiring that for lock
tokens.

I apologize for the confusion. The reason for the unclear language, btw, is
that the state token part of the spec was kept in a physically separate
document from the lock part of the spec. We have stopped that practice. The
spec is now edited as a whole.

			Yaron

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	Monday, October 27, 1997 3:03 PM
> To:	w3c-dist-auth@w3.org
> Subject:	state token and lock token confusion
> 
> 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?
> 
> thanks.
> 
> Jim
> 
> 
> ------------------------------------
> http://www.parc.xerox.com/jdavis/
> 650-812-4301

Received on Monday, 27 October 1997 19:46:00 UTC