- From: Paul Burchard <burchard@horizon.math.utah.edu>
- Date: Fri, 28 Jul 95 03:45:36 -0600
- To: www-talk@w3.org
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