Re: Session-ID proposal

-- [ From: Bob Wyman * EMC.Ver #2.5.02 ] --

Dave Kristol wrote: 
> Actually, I had "clickstreams" in mind less than "shopping carts" and 
> library system navigation.

If this is the case, I would suggest that you could do reviewers a service
by stating this in the introduction to your draft. I would also suggest that
it may be a disservice to introduce a protocol modification that has such
limited utility. This is particularly true since we already have outstanding
the Netscape "cookie" proposal which appears to be able to support
"clickstreams" as well as a range of other requirements for session state.
If your limited proposal is accepted into HTTP, it seems inevitable that
someone else will argue for and probably succeed in getting a second session
state mechanism adopted that handles the other requirements. The result will
be, of course, more crust and rust introduced into this young, but rapidly
tiring, protocol.

>The point of the proposal is that all interesting state should be
> embedded in the opaque session information.

It is clear from your comments that you view the opaque data carried in the
"Session-ID" to be something other than and more than a simple identifier
for a session. I must admit, however, that I'm confused since if you concern
is really just "clickstreams" then you should be satisfied with a simple
identifier... Anyway, I would suggest that you call the thing something
other than an "ID." You should seriously consider following Behlendorf's
lead and calling it "State:" or "Session-State:" Perhaps the non-native-
english-speakers will object to my desire to have protocol tags be faithful
to the English language... Nonetheless, I think that as long as we're not
using hex numbers to identify these things, we should view such faithfulness
as a means of clarifying the intent of the author.

>A CGI can examine the incoming  Session-ID, if any, and can 
> generate a new one or repeat an old one.  Clearly the content
> of the opaque information is application-dependent.

If the opaque information is really application-dependent then there is a
small problem here... You state in your proposal that the "Session-ID" must
be returned in the next request following the response in which it is
received. Thus, I may get a Session-ID from CGI script "A" and if the next
URL I request is CGI script "B", then I am required to forward the Session-
ID I received from "A" to "B". (I won't reflect on privacy concerns at this
point...) The problem here is that "B" won't have any idea if it understands
the opaque data received since it has no way of knowing who authored it.
Even if I had sent the Session-ID back to "A", script "A" would have no way
of knowing how to interpret the opaque data. Inevitably, we'll see people
embedding "application ids" into this otherwise opaque data and then
building informal consensus on how to inspect the beginning of a session id
to determine if it is "yours." The opaque data will start to be less opaque.
This will get really ugly when people start declaring rules like: "If you
don't understand the session data, push it back in the response inside a
wrapper defined in RFCXXXX." The result will be rapid accretion of odd bits
of session data and rapidly growing packets...

Note: The Netscape "cookie" proposal has much the same problem, however, the
impact is somewhat limited by their inclusion of the "path" attribute on the
cookie. The client is able to be somewhat specific about who it sends the
session data to. This reduces the problem somewhat, but not completely.

> Other proposals similar to this one have run into caching problems
> because the  state is somehow embedded in the document or URL.
>  I wanted to avoid that.  I'm  assuming that the resource content is
> the same, independent of Session-ID ... Given this treatment of 
> Session-ID,  it's expected and desirable for a caching  proxy to serve
> out the same content when possible.

You imply here that a Session-ID offers no additional semantic richness to a
client-server exchange. Thus, a session using Session-IDs and one without
would result in identical content exchanges other than Session-ID. If this
is the case, it would appear that there is no apparent benefit to a client
from hassling with Session-ID's. The only benefit from these things is to
allow server administrators to characterize their load and marketing or law
enforcement folk to study our behaviour. If Session-ID is to have some
utility to the client, then there must be a mechanism specified for a
caching proxy to obtain correct and appropriate Session-ID's for each
request -- even if the response body is cached.

Anyway... the basic point here is that I think that clickstreams aren't
important enough to address in isolation of the other requirements for
server state. It appears that a solution to the larger problems will
incorporate a solution for clickstreams as a subset. But, it appears that
the larger problems cannot be solved as a simple super-set of clickstream
support. Thus, we should probably address the harder problems first...

		bob wyman

Received on Tuesday, 8 August 1995 11:30:37 UTC