Session-Id vs. Cookies

mwm@contessa.phone.net (Mike Meyer) writes:
> I think I've answered all the issues, except for the one of
> wanting a more structured object in general. Not having
> seen anything on that - except for Cookies - I can't really
> comment on it.

For session-ID functionality, I like your proposal: it's nice and  
simple and gets the job done.  But when such a session-ID mechanism  
starts being used as a way to carry along shopping baskets and other  
complex objects, it is technically obsolete from the start.

Also, I find Netscape-style cookies disturbing for privacy reasons;  
they regress from the principle of providing clear and constant  
feedback about what is being done with the user's input.  "Shopping  
basket" information may even be invisibly transported to a  
completely different server without any visual hint to the naive  
user.

What I want to sketch here is how one might implement cookies  
without abusing HTTP headers.  Moving the cookie out of a header and  
into a genuine HTTP object means first that the cookie can benefit  
from the existing linking, caching, and security mechanisms of HTTP.  
 But in addition to the technical benefits, a linked cookie object  
could be a human readable document, presented to the user in some  
subsidiary way by the user agent, thereby easing the privacy  
concerns.

The central new ingredient would be a "Cookie" link relationship  
with some rather interesting semantics (admittedly requiring some  
extensions to existing linking concepts).  The "Cookie" relationship  
can be decomposed as the combination "Collective Volatile" of two  
simpler new relationships:

  1.  Collective.  A link of this type is many-to-one, bringing  
together the _collection_ of all source objects linked to the given  
target.  The collection is not just an explicit list, because  
"subtree inheritance" is imposed, so that all objects with URIs in  
the same subtree as a member, are also automatically members of the  
collection.  Assigning a new target to any source in the collection  
causes collective replacement of the target for the entire  
collection.

  2.  Volatile.  Neither client nor server are required to maintain  
the link unless it is acknowledged by the other party in each HTTP  
transaction.  In particular, this implies that if the URI of the  
target is itself "volatile" (i.e. does not translate into a URL),  
each side must refresh _both_ the target object and the link in each  
transaction.

How to implement this?  The volatility rule (2) means that we must  
usually make use of the HTTP "Link:" entity header, in both  
responses and requests, in order to maintain the link.

Furthermore, in the most common scenario, the cookie is a  
client-specific "volatile" object, not maintained on the server.   
For this reason we must use MIME multipart bodies and "cid:" URIs in  
order to transport the linked cookie together with the document in  
each request and response transaction.

Unfortunately, the specification of cid: URIs  
<URL:http://www.w3.org/hypertext/WWW/Addressing/URL/4_1_Cid.html>  
does not seem to be in good enough shape to turn this into a  
concrete proposal just yet (e.g., the "multipart/related" media type  
does not seem to exist according to  
<URL:ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types>).  
 However, someone more versed in multipart yoga might be able to  
clear this up.

--------------------------------------------------------------------
Paul Burchard	<burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

Received on Wednesday, 26 July 1995 04:46:54 UTC