Re: Session-ID proposal

Bob Wyman <bobwyman@medio.com>:
  > 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
Fair enough.
  > 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.
While documentation for Netscape's cookies is available on their site, I
hadn't noticed they had put it forward as an Internet Draft.  Have I
missed it?

FWIW, I think my proposal supports "clickstreams" too.  (Did you, by
chance, mis-read the first remarks of mine you quoted above?)  But that
wasn't the reason I proposed it.
  > 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.
What other requirements, specifically?  Lots of people have put forward
proposals for stateful sessions, but few have stated the requirements
they are trying to satisfy.  (Including me, I guess.)  In any case,
stuff evolves.  No doubt Netscape's cookies won't satisfy all
requirements forever either.
  > 
  > >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.
Perhaps "Session-ID" is a poor choice.  Let me leave it for now.  We
can argue about the right name later if the functionality is right.
("Session-State" sounds good.)

Yes, I had in mind more than a simple identifier, and I'm interested in
more than just "clickstreams".  But it could be a simple identifier.
I deliberately left the semantics unstated, rather than over-specify.
  > 
  > >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...
By "opaque" I meant more that only the server should be paying attention
to what's contained therein than that it couldn't be understood by someone
who happened to see the header.  But the server could, for example, encrypt
the content with a server-private key that it applied to all of its
Session-ID information.

As for CGI's A and B, you are correct in the abstract, but less so in
the specific.  I'm assuming the usual case of someone navigating
through a tree of pages by following hypertext links therein.  The
content is structured in a way that A and B are likely to be part of
one application (say, the LL Bean shopping cart).  So the Session-ID
information will be pertinent to both.
  > 
  > 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.
Agreed.  But since the semantics of the Session-ID are open-ended, a
server could encode path information therein.
  > 
  > > 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.
Suppose I'm browsing a catalog and have accumulated a "shopping cart"
embodied in a Session-ID.  I reach a page that describes a Full-Duplex
Framas.  Perhaps there's a link/button/icon that would let me examine
my current shopping cart and tell me my current balance.  An "add to
shopping cart" link/button/icon would select the Framas for purchase.
The Framas description (URL), however, has no session-specific
information and can be cached.  Any user would see the same stuff for
that URL.  The action occurs when I select a link that acts on my
shopping cart.

Now admittedly there's another possible implementation that, for example,
always tells me my current shopping cart balance.  That would require a
CGI (probably) to display the product description AND give me my balance,
and the resulting page would not be cacheable.
  > 
  > 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...
I agree about clickstreams, and reiterate that my proposal was more
than just clickstreams.

Dave Kristol

Received on Tuesday, 8 August 1995 16:23:48 UTC