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

Marc writes:
> Syntax:
> The augmented BNF doesn't contain a comment keyword as per HTTP 1.1.
> Translucence of the cookie is important, as the cookie speaks the server's data
> on the user for the user at the user's command.  A server's documentation of
> the contents of its cookies can both aid a user in determining whether they
> want to keep a cookie in their cookie jar, and could be used legally in certain
> jurisdictions bind a content provider's representation of cookie functionality
> to actual functionality to prevent abuses.  The absence of cookie commentary
> can be of value itself.  This can be accomplished either by commenting each
> chip in the cookie or by providing a URI as a link to a key describing this
> flavor of cookie.

Boy, am I tired of the extended metaphors on cookie, especially the
mixed metaphors.  A translucent, flavored cookie?  

Anyway, the spec states that while the cookie is to be considered opaque,
it may contain anything which the server chooses, including commentary,
patriotic songs, or whatever:

     The VALUE is opaque to the user agent and may be anything the
     origin server chooses to send, possibly in a server-selected
     printable ASCII encoding.  ``Opaque'' implies that the content is
     of interest and relevance only to the origin server.  The content
     may, in fact, be readable by anyone that examines the Set-Cookie

So you may embed a comment within the cookie if you like.  That comment
is part of the cookie, though, and cannot be hacked off.  This makes
parsing the name/value pairs much easier as you don't need a new seperator
for the Value and the comment.   

Please don't, by the way, drag into the cookies requirements for legal
explanations for any jurisdiction; we went through this with the Warnings
and it is not a good idea.  See the mailing list archives.

> 7.2  Protocol Design
> |Therefore a request-host is limited as to what values it can set for Domain.
> |We consider it acceptable for hosts and to
> |share cookies, but not and
> I'm not a DNS guru, but it seems possible to use cookies, redirects and
> cooperating DNS domains to achieve the 1:n cookie functionality in accordance
> with this document:
> Say that and conspire to create a new domain between them called
>  In the DNS is also and is also
> (perhaps multi-homed).  One initiates a connection to,
> recieves a redirect with a Set-Cookie (cookie-1) to which itself
> returns a Set-Cookie (cookie-2) for
> and et al conspire to redirect all requests with cookie-1 to the
> appropriate * where cookie-2 is sent and the user is tracked.  If this
> is correct, then Set-Cookies in 302 responses are as dangerous to privacy as
> 1:n cookies.

Note in your example that all of the actual data is coming from  From the
user's point of view, they are connecting to, and lots of features in
User Agents will make that obvious.  If two sites (say, and
are so interested in sharing cookies that they are willing to appear as
to the user, then I think that they have done enough to make the user aware that
they may share information.  

					Ted Hardie

Received on Thursday, 20 June 1996 13:04:47 UTC