- From: Vladimir Zelenyak <www-talk-request@w3.org>
- Date: Sat, 6 Jan 1996 18:44:05 PST
- To: www-talk@w3.org
- Cc: Koen Holtman <fielding@beach.w3.org>
Roy Fielding: >Daniel W. Connolly: >>Each HTTP request should include a header field of the form: >> >> Request-ID: $session $request++ >>e.g. >> Request-ID: 342%33a4d443 12 > >A) Must be optional (it can indeed be used to identify individuals, > if the individuals are not sophisticated enough, or if the tracker > is persistant). Besides, all headers are optional in HTTP. > >B) Should be shorter (optional marketing gunk has low priority) I'd like to point out that having some form of session-id in HTTP should be given a *high* priority, because there are much more important things than marketing gunk connected to session-id. A session-id allows the server to distinguish between individual sessions, and this makes possible keeping session state information in a server-side database. The need to keep session state has been discussed at length before on this list, and session-id seems to be the minimal solution to this problem. (With minimal, I mean minimal in terms of extra browser complexity needed.) Session-id allows for a reliable and relatively straightforward implementation of what I call a `statefull dialog' between user and service, that is a dialog that extends beyond the submission of one form. By allowing statefull dialogs, session-id will greatly increase the potential of the web as a two-way communications medium. Compared to this, the improvement possible through better clicktrail analysis by the marketing department is not very significant. I want my browser to support session-id because this will allow me to get new interesting services. If I can't have the services without giving up some of my privacy, I will in fact gladly give up some of my privacy. But with an adequately designed session-id mechanism, the amount of privacy I need to give up can be kept very small. As said before in this thread, the session-id should at least be different for each server talked to. One other idea is for the browser to only send session-id info to a server starting from first POST request (form submission) done on that server by the user. Thus, users only get an identity if they start talking back to the server. Privacy would not be decreased in other cases. A session-id is needed as soon as possible. Not to allow better statistics, it needn't improve the possibilities for statistics much at all, but to allow new kinds of services to be added to the web in the future. Of course, the question of how much user privacy may be traded away to increase the quality of web advertising and prevent the web-equivalent of spamming is an important one. But as shown above, the main advantages of session-id can be had without fully answering this question. Koen.
Received on Saturday, 6 January 1996 11:44:28 UTC