- From: <hallam@w3.org>
- Date: Sun, 14 Apr 96 20:46:49 -0400
- To: Koen Holtman <koen@win.tue.nl>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: hallam@w3.org
While I like Koen's draft I think that there is another point to bring up here, the "don't build systems that depend on it" point. If clients start producing exotic accept headers as a means of supporting bogus demographic schemes we have a clear violation of the "separation of concerns" principle. It will be difficult enough to develop the content negotiation scheme. It will be much harder todo this if changing the accept header mechanism will break demographic protocols. There are several hacks which have been agressively marketed as solutions to the demographics problem which will prevent usefull work by proxies. Chief culprits include systems based on cookies, adding user identifiers to the URI and so on. The point about these systems is that they are fragile and will break as caching is more widely deployed. State Info is a mechanism for improving client/server interaction. They are sub-optimal as session identifiers. I hope that we can address these issues directly in 1.2 and to that end I have 3 W3C technical drafts which describe an explicit mechanism for supporting session identifiers. I don't have a problem with a site tracking the browsing patterns of its users within its site. After all persistent connections would reveal such information if they were long enough. The real privacy issues occur when going across sites. We can't get into the discussion of the privacy issue at this time but when we do I believe that there is much more of a middle ground between the content providers and privacy advocates than people may believe. The main impediment to a working solution is likely to be the one-man-and-his-perl-script companies with a clueless hack they want to preserve until they go for a ludicrously overpriced IPO. Phill
Received on Sunday, 14 April 1996 17:49:50 UTC