Re: draft-ietf-http-state-mgmt-01.txt LAST CALL

Marc Salomon:
>
[On sharing of cookies across domains, in an earlier message:]

>Sharing would be possible only when there were multiple domains in
>the Set-Cookie header.  Sharing with permission is OK, but leaking is
>bad.

Whose permission: permission of the user or permission of service
authors collaborating to do cross-server user tracking?

Many end users are very concerned about the way current netscape
cookies can violate their privacy expectations (there has even been a
WSJ article about this: `Internet Users Say they would Rather Not Share
the Cookies').  The state management draft tries to address these
concerns by, among other things, limiting the possible sharing of
cookies to one domain.

While this limitation rules out some applications, as your example
shows, it is necessary in order to address the privacy concerns.

[...]
>While we're here, why are there no client-initiated cookies that
>could perform functions (like Phill's or Brian's proposals) or to
>advertise well-known client state ('just browsing,' 'purchasing,'
>'max $ to spend' or other aspects of client preference as well as
>UA-instance ID) to the server.

Cookies are a general mechanism for stateful sessions, not a general
web shopping protocol.  Web shopping is just one area where state
management is useful.  Collaborative web systems are an other
application area.  

Including a `max $ to send' mechanism in the state management draft
conflicts with the goal of taking away the privacy concerns people now
have with netscape cookies.

What you call `client-initiated cookies' and `client state' has
nothing to do with session state management.  `client-initiated
cookies' are more like a business card mechanism (or more like a big
brother device, depending on your point of view).

In my opinion, no cleanness of design would be gained if these two
mechanisms were to share header names, quite the contrary.

>-marc

Koen.

Received on Friday, 14 June 1996 15:29:51 UTC