W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1995

Re: Session tracking

From: James Pitkow <pitkow@cc.gatech.edu>
Date: Wed, 10 May 1995 14:47:40 -0400 (EDT)
Message-Id: <199505101847.OAA15272@hapeville.cc.gatech.edu>
To: Multiple@cc.gatech.edu, recipients@cc.gatech.edu, of@cc.gatech.edu, list@cc.gatech.edu, <www-talk@www10.w3.org>

Jared Rhine writes on Wed, 10 May 1995 00:12:32 -0700:

> [The topic was session-tracking proposals, esp the proposed "Session-ID"
> header.]
>  JP> 1) identify sessions (esp. from firewalled domains)
>  JP> [...]
>  JP> If the 'From:' field is widely used, you'd have what you wanted(1).
> No, I don't believe so, because one of the stated requirements is that we be
> able to identify sessions without compromising the identity of the user.
> If this is the case, I fail to see how current HTTP practices allow for
> session tracking as you claim:

>  JP> My point is that the protocol does not need to be changed to handle
>  JP> session(1) &/or user identification(2) - WWW browsers/interfaces need
>  JP> to pass the right information.
> Elaborations?


  Inspection of the http specifications indicates the From: field be in 
Internet Mail Format and is supposed to give the name of the requesting user.  
Additionally, it recommends, but not require, that the address be valid.
Provided that the loci of control over contents of the From: field rests
on the client with the user, one can easily see where this field can be
used to support Chom's notion of multiple aliases and provide session tracking. 

  For example, a user upon start up of their WWW Browser for the first time
is asked to configure the From: field as part of the preferences which are 
currently configurable.  The user has the option of providing a real/valid 
address, or a bogus identification number.  This information accompanies 
requests and can be used by servers to customize information and track users 
across sessions.   Multi-user platforms that are not access controlled (e.g. 
Macs and PCs) can still be supported by providing browser level support for 
multiple aliases across multiple users.

  Now let's say that the user is not happy with the customization of the 
information/services provided by a server - it is the user who can reset 
the profiling and not be subjected to rigid server-side user models.  
Another scenario would be where the client keeps a table of aliases used for 
interactions with servers and allows the user to switch roles/aliases.  Here, 
the client could be used to generate unique client side ids.  And 
broadcasting of real identification is managed by the user.

  The downside with both being you may get name/id space collisions from 
clients behind the same gateway/firewall.  Following the 80/20 rule, I'd
argue that the majority of traffic will be correctly handled and that 
session id tracking is not a situation where 100/0 is required.  Where 
better assurance is needed to ensure the same user across each and every 
session, other mechanisms within http can be used.

  Of course there is the issue of session id management. Generous estimates 
(20 million users with 60,000 WWW servers) indicate that 1.2 x 10^12 possible
ids would need to be maintained by either the client or the server if every 
relation requires a different id.  In practice though, a user may have say 
10 aliases or so. Therefore each client would need to manage 600,000 ids for 
all WWW servers whereas each WWW server would need to maintain 1.3 x 10^13 ids.
Note that if you argue that each client will not interact with all servers,
this constant applies to both equations and therefore cancels, so the difference
in magnitudes remains the same.  An assumption being made here is that there 
will be always be more users than servers, which seems reasonable. So it seems 
from this approach that the latter solution (server-side) generation of 
sessions ids does not scale as well as client-side id/alias management, 
regardless of the loci of control approach argued above.

I'm away, so take your time in replying.

Received on Wednesday, 10 May 1995 14:48:27 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:17 UTC