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 <[email protected]>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------