W3C home > Mailing lists > Public > www-tag@w3.org > February 2006

Re: Draft State Finding

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Thu, 23 Feb 2006 10:05:42 -0800
Message-Id: <62DD5BB7-D4C4-4C2D-92BA-6A6EAD802A10@yahoo-inc.com>
Cc: <www-tag@w3.org>
To: David Orchard <dorchard@bea.com>

Hey Dave,

Great stuff!

Couple of questions/observations;

* 2 "What is State" - You should explicitly say that application  
state is (potentially) distributed across different components  
(clients and servers), and/or across different resources.

E.g., caches can keep application state away from the server. Cookies  
might also be used in a fashion where application state is only  
client-side (although it will usually be synced back to the server  
for persistence/portability, it doesn't have to be). An application's  
total state -- even from the perspective of one user -- might span  
many resources.

* 2 "What is State" - has the TAG defined sub-resource as your usage?  
Commonly, I hear the term used in the fashion "bar is a subresource  
of foo in the path /foo/bar."

* 3.1 "Browser State" - One interesting thing about browser state is  
that it's all generic; there is very little (any?) application- 
specific interpretation of the semantics of stored state on the  
browser side; the only exception I can think of is client-side cached  
javascript.

* 3.2 "Server State" - This could be broken up into "Server State"  
and "Session State"; they deserve separate treatment, esp. because of  
the confusion over "statelessness" and cookies.

* 4 "Decisions" - I think there's something missing here; one key  
decision is what you use session state *for*. There's a difference,  
for example, between using HTTP authentication (or cookies, or...)  
just for authentication/authorisation purposes, vs. varying the  
representation of a resource based upon the identity presented.

A "good" system (ignore who makes that decision for the time being)  
will only do the former, and mint different resources, because they  
really are different things. They might put the user identity (or a  
proxy for it) in the URI, as well as checking authentication in  
headers. You seem to hint at this in section 5.6, which I really like  
BTW.

* 7.1 "Ease of application construction" - isn't this just an  
artefact of current tools' capabilities/lack thereof?

* 7.2 "Security" - RFC 3875 section 9.7 ("Stateless Processing") has  
a nice summary of some risks.

* 7.4 "Performance" - I had a hard time reading this section.

Cheers,



On 2006/02/21, at 10:05 AM, David Orchard wrote:

> Per my action item and for our discussions, I attach a rough draft  
> of a finding on state.
>
> This probably should get a URI, etc.
>
> Cheers,
> Dave
>
>
> <State.html>
> <state.xml>

--
Mark Nottingham
mnot@yahoo-inc.com
Received on Thursday, 23 February 2006 18:07:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:38 GMT