W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: making progress on State-Info

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 9 Dec 1995 00:37:42 +0100 (MET)
Message-Id: <199512082337.XAA06249@wswiop05.win.tue.nl>
To: Dave Kristol <dmk@allegra.att.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, montulli@mozilla.com, eric@spyglass.com
Dave Kristol:
>As Larry Masinter's draft IETF meeting notes said, HTTP/1.1 will
>progress with separate pieces that will be brought together in time
>for the next IETF meeting.  I agreed to try to make progress on
>State-Info (http://www.research.att.com/~dmk/session.html).  (The
>actual topic area was "state management", and right now there's only
>the one draft proposal.)
>
>I claimed at the meeting, on the basis of http-wg mailing list
>activity, that there was "rough consensus" for the I-D I wrote,
>draft-kristol-http-state-info-00.txt.  I was advised that I had better
>confirm that here.  So, are there dissenting voices?

I too remember there being a rough consensus for incorporating
draft-kristol-http-state-info-00.txt into HTTP/1.1.

Let me try to break this consensus down into three separate issues:

1) Some web services need to maintain session state (where a session
is a series of requests and responses between one server and one user
agent).

I don't think anyone on this list would disagree with 1).  Several
existing services (like some games, some cooperative systems, some
tele shopping services, some library-like systems) already maintain
state, either through ugly, not completely reliable, and
cache-unfriendly hacks or by requiring user authentication (which is
reliable, but both cache-unfriendly and user-unfriendly).

2) HTTP/1.1 needs to introduce reliable and cache-friendly mechanisms
to support session state.

I also believe there to be a rough consensus on this.  I remember
someone saying that Java would, among other things, solve the session
state problem so why bother also solving it in HTTP, but many people
had objections to this reliance on Java.

3) draft-kristol-http-state-info-00.txt is internally consistent and
will offer good session state support.

I believe there is consensus on draft-kristol-http-state-info-00.txt
being robust, cache-friendly, and easy to implement.

There recently was some discussion on
draft-kristol-http-state-info-00.txt not addressing its stated privacy
concerns, but consensus was reached that
draft-kristol-http-state-info-00.txt does indeed provide adequate
privacy.

There has also been some discussion on scalability: some people think
that draft-kristol-http-state-info-00.txt will not scale to services
with a very large number of concurrent sessions and a very large
amount of session state.  I believe there to be at least consensus
that, if these large cases exist at all, they will be very rare.

>Dave Kristol

Koen.
Received on Friday, 8 December 1995 15:40:56 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:37 EDT