Suppose I'm interested in the use of a Session-ID as a way to simplify
a magazine subscription service. The Session-ID constitutes (no
surprise) a way to track a "session", something you can't do easily
with a stateless protocol. In my case, it can track where you are in
the service hierarchy and that you've authenticated yourself. It can
also carry expiration information. I wouldn't want to have to wait
until all the client vendors had picked up the set of magazine
subscription extensions (along with the shopping basket extensions)
before I could offer such a service.
>
> It's only the lack of serious client-side capabilities in today's
> Web that's keeping you from thinking about this as the client-side
> issue it naturally is. Shouldn't we be devoting the effort
> currently going into server-side kludges (I've done my share of
> this) to improving the client capabilities? From what I hear, Billy
> G. understands and fully intends to exploit this weakness of the
> Web...
[...]
It seems to me we have the choice of creating either client-side or
server-side kludges. Putting the kludges in the server makes the
software distribution problem simpler and makes it easier to start up
new services. All it takes is a little cooperation from a client.
Hence my earlier proposal for a very simple Session-ID mechanism, and
my general support for simple, general mechanisms in the protocol.
Dave Kristol