Session-ID -> State-Info

At Roy Fielding's prodding, I have aligned the terminology of my
Session-ID pre-proposal to match the HTTP draft.  I also changed
the name of the header (but not the URL) from Session-ID to
State-Info.

Further comments are welcome.  Documents at
	http://www.research.att.com/~dmk/session.html

Dave Kristol

sing session-ids, Does this have any functional
  > implications? I don't see it as an important differnce.
The state information is stored on the client-side in both cases.
  > 
  > I cannot see any big differences in complexity.
  > Expiration-time that you mention as adding complexity
  > to cookies seems to me to be a separate issue, we
  > might want it also in the session-id mechanism. or
  > we may discard it from cookies.
Because the server initiates the session, I felt it was appropriate for
the server to decide when a Session-ID was no longer appropriate.  In
Netscape's cookies, the user agent examines the cookie and can decide
whether it had expired.
  > 
  > Probably an important issue is the diffence in
  > the "scope" of the ids/cookies. 
  > Distribution of cookies is determined by the
  > url (client send cookies along with request if
  > the url fills certain criteria). 
  > I thing your proposal leaves the issue open.
The user agent always returns the ID.  The server can decide whether
it's relevant to a particular request.
  > Everything in the "same window" will use the session-id.
  > What about non-windowing clients? 
They behave like a single-window client.
  > 
  > Tying the id to server/port combination may
  > not be enough, I think the cookie way of looking at
  > the whole url gives more possibilities (are there
  > reasons why not to do it?).
I wanted the client's role to be very simple.  With Session-ID ("State-Info"
imminently), the client never examines the content of the ID; it just sends
it along.  Having the client act on the URL may have advantages.  (I'd
like a proponent to give them.)
  > 
  > Could some kind of a .. "flow" (?)
  > system be thought of? Server would return a 
  > session-id in all transactions belonging to a
  > session, and client would always echo it in 
  > the subsequent requests to the same server.
That's essentially what I've proposed.
  > 
  > Or maybe to other servers as well? This gets complicated,
  > but maybe there is  need for somthing like this;
  > a server starts a session with a client,
  > client follows an external link to some other
  > server that gets the session-id, sends a request
  > to the original server to get information about
  > the session and acts on that if useful?
www-talk (or was it http-wg?) discussed this recently.  People expressed
concerns about privacy and the ability to correlate visits to multiple
servers.

[...]

Dave Kristol

Received on Thursday, 10 August 1995 09:27:09 UTC