There are two things that I feel are somewhat unfortunate limits to this
proposal, though I generally like the proposal.
The first is that the proposal apparently doesn't allow for more than
one session with the same server (unless you have a multi-window
browser). It would be nice to be able to start a new session at any
time, even with a one-window browser, while not discarding other
active sessions. Intuitively, it seems to me that it ought to be
possible to re-initialize the state if you request some designated
resource, e.g. the home page, or some other "start new session" page.
Starting a new session ought to be in the hands of the server,
depending on the user's actions. If the user then uses browser
history commands to go back to pages that were conceptually part of a
previous session, you ought to end up in the previous session. On
first blush, to do this it seems that this would mean there would need
to be some kind of session ID that the browser could parse as part of
the data associated with the state-info, so that the browser could
tell which session with a particular server a given response was for.
The nature of this identifier would still be controlled by the origin
server. As the proposal now stands, the browser only has the tuple
(browser window, server IP address, server port) as the key for the
session. It would certainly be more complex to do what I suggested --
the required tuple would be (server IP address, server port, session
ID associated with "referer" page). In other words, the browser would
have to keep track of which session, if any, a given page was
associated with, and use that to pass back to the server on any links
from that page. It's a little more complicated, but not that much.
My feeling is that it would be a good idea to build a multi-session
capability in from the start so it doesn't have to be wedged in in
some ugly way later.
Secondly, I know from experience that people really like to be able to
re-enter a session after several days. So, I (provisionally...) think
that requiring or at least suggesting that browsers persistently save
the state-info would be a good idea. (Of course this opens up some
other UI cans of worms).
I know my suggestions contradict Dave Kristol's very reasonable desire
to keep it simple to have a minimal impact on HTTP and user agents, but
just thought I'd put in my 2 cents anyhow.
Now, I'll go back and re-read the thread, and probably find that there
are better ideas already floating around.
--Shel Kaphan