State and tracking need to be separated (Re: session-id redux)

I would like to request that we separate the discussions of  
tracking and statefulness on this list.  The confusion between these  
two issues is, I think, making consensus a lot more difficult.

Following Dan Connolly (whose manifesto [1] clearly separates these  
issues), let's use the term "Request-ID" for a non-cache-breaking,  
non-stateful, client-assigned version of Session-ID.  Request-IDs  
are a good, low-cost tracking solution (most importantly, low cost  
in the long term of protocol evolution). The issue of state is  
thornier, but let's not make it more difficult than necessary by  
trying to unify state with Request-IDs, which have different caching  
requirements.

Once we can focus on the issue of state by itself, I believe it  
will also become clearer that HTTP headers (not only Session-ID: but  
also Authenticate:) are the wrong places to put it.  Any proposal  
that does not support client/server balancing, and instead imposes  
all the burden of state maintenance on the server, is unacceptable.   
Hidden form fields can already do better.

My inclination would be to use Web links to attach state, and  
remove the issue from the HTTP protocol level altogether.  This will  
keep HTTP itself "stateless" (giving more freedom to future  
evolution of HTTP).  By turning the state into first-class Web  
objects, links also allow state to be media-typed and interpreted  
for the user, easing privacy concerns relative to most other  
proposals.  I'm working on a more precise proposal for state links,  
but feel free to jump in.


[1] <URL:http://www.w3.org/hypertext/WWW/Protocols/demographics.html>

--------------------------------------------------------------------
Paul Burchard	<burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

Received on Friday, 28 July 1995 05:46:07 UTC