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...''
--------------------------------------------------------------------