> [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?
Sure:
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.
Jim.