Re: State and tracking need to be separated (Re: session-id redux)

Paul Burchard:
>I would like to request that we separate the discussions of  
>tracking and statefulness on this list.  The confusion between these  
>two issues is, I think, making consensus a lot more difficult.

I support this request.

If I remember correctly, I was the person who introduced statefullness
into the session-id thread.  My reasons for bringing this up was that
Roy Fielding called session-ids `optional marketing gunk [with] low
priority'.  I feared that this opinion of session-ids could seriously
delay statefull dialog support, as any form of statefull dialog
support will either look a lot like session-ids, or is so powerful
that it allows trivial emulation of session-ids.

I still feel that the session tracking and the statefull dialog
problems could potentially be solved by introducing one single
session-id mechanism.  However I now think that such a solution is
infeasible, because discussions about one single mechanism are too
confusing.

The best way to get quick statefull dialog support (I don't care much
about getting quick session tracking support for marketing purposes)
is to develop request-id and session-id/cookies/anonymous
authentication/... separately.

Of course, I get this vision of a committee that splits off two
subcommittees for two separate problems, and after receiving the
standard extensions proposed by the two subcommittees, finds out that
the two standard extensions are to a large extent equivalent.

Many people in this thread argue that minimal statefullness support
mechanisms need to be far more powerful than a mere client generated
session-id plus a server-side database.  These people would not share
my committee vision.

>Following Dan Connolly (whose manifesto [1] clearly separates these  
>issues), let's use the term "Request-ID" for a non-cache-breaking,  
>non-stateful, client-assigned version of Session-ID.

>[1] <URL:http://www.w3.org/hypertext/WWW/Protocols/demographics.html>

Agreed.  Also, let's use the term `persistent' for a session-ID/
cookie/authentication value that is remembered by the browser for
future sessions, and `non-persistent' for values that are lost when
the browser exits.

It is still not clear to my, by the way, whether the anonymous
authentication in [1] is supposed to be persistent or not.  Dan
Connoly talks about clients not needing to maintain databases for
anonymous authentication, but I'm not sure what he means by this.


Earlier in this thread, I wrote up minimal requirements to make a
separation between the discussion of privacy and statefullness support
possible.  I restate them here:

*If* browsers have a configuration screen like

   +-----------------------------------------------------------------+
    Generate statistics-enhancing request-ids:
        ( ) Yes (different ones for each server)
        (*) No

    Handling of `statefull dialog' session-id/cookie/anonymous
    authentication/... requests:
        ( ) Always honor request
        ( ) Always honor request if it was done in a response to
            a form submission (POST).
        (*) Ask once for every site, use reply in later sessions
        ( ) Never honor request
   +-----------------------------------------------------------------+

where the (*) are the default settings, *and if* a web culture
develops in which commercial sites asking for a `statefull dialog'
session-id if the browser does not send a `statistics' request-id,
purely to get better statistics, are considered rude, *then* current
levels of privacy could be mostly retained even though we have
statefull dialog support.

Note that the NetScape Cookie implementation does not satisfy the
above minimal requirement.


>Paul Burchard   <burchard@math.utah.edu>

Koen.

Received on Friday, 28 July 1995 07:31:26 UTC