Re: session-id redux

In message <199507261138.NAA07954@wswiop05.win.tue.nl>, Koen Holtman writes:
>
>  Session-id allows for a reliable and relatively straightforward
>  implementation of what I call a `statefull dialog' between user and
>  service, that is a dialog that extends beyond the submission of one
>  form.  By allowing statefull dialogs, session-id will greatly increase
>  the potential of the web as a two-way communications medium.

Let's be careful here: the proposed mechanisms can be split quite
clearly among those where the information in the request _may_ affect
the response, and those where it _may not_; that is, those mechanisms
that interfere with caching, and those which do not.

If your application requires a "stateful dialog" between client and
server, clearly there are interactions with caching: the if a request
for resource R is made first with dialog identifier X and subsequently
with dialog identifier Y, a proxy must not satisfy the second request
with a cached response from the first request.

To my mind, any of the mechanisms for implementing "stateful dialogs"
are authentication techniques. The dialog identifier, cookie, or (in
some uses of the term) session ID works just like a user ID in an
authentication mechanism.

On the other hand, my Request-ID proposal had no caching interactions.

Yikes!!! My most recent set of proposals vanished into the bitbucket!
Before Brian and others throw in the towel, consider this revised
set of proposals:

I'm not risking email again. I'll stick it on the web:

http://www.w3.org/hypertext/WWW/Protocols/demographics.html

Dan

Received on Wednesday, 26 July 1995 11:49:27 UTC