State Management pre-draft - combinational requirement

	I would like to raise more public discussion about the combinational
requirement in the latest State Management pre-draft.

	The current effort at a revision of RFC 2108 began when Koen
pointed out that use of version 1 cookie attributes as in the RFC's
specifications for modern Set-Cookie headers are not handled adequately
by MSIE's implementation for historical cookies.  We all promptly agreed
that a revision to ensure backward compatibility with that old implementation
is important.  In the process of discussing a revision, it also was brought
out that the blanket port restriction has the side effect of blocking any
cookie sharing between http and https servers, even when such sharing should
not be blocked.  The desireablility of a discard attribute promptly reached
consensus, and of a commentURL attribute to accommodate i18n concerns beyond
the too meagre comment attribute is being discussed.  The new attributes
(port, discard and commentURL) all could be incorporated in a simple and
elegant manner as extensions to the RFC 2108 Set-Cookie header, but to
accommodate MSIE's parsing problems with that, we decided to create a
separate, Set-Cookie2 header for modern cookies.  The issue of how this
affects UAs which implemented RFC 2108 (e.g., Lynx in its v2.7 and v2.7.1
formal releases), i.e., if Set-Cookie headers regressed to historical, was
not a factor in these discussions.  Though in principle this is to be a
revision based implementation experience, it has proceded largely as if
there were none, and as if backward compatibility with RFC 2018 is not a
consideration (that's OK, don't worry about it :).

	Then we received a complaint that having Set-Cookie2 headers for
modern cookies and duplicates in Set-Cookie headers for historical UAs
is a "problem" for an organization which makes a practice of setting large
numbers of lengthy cookies, so the combinational requirement was born.
To get an idea of that "problem", try http://www.microsoft.com/ with a
clean cookie jar.  You will be sent through a series of redirections, and
cookie replacements, with the ultimate result of your cookie jar acquiring
two seemingly identical cookies for hosts which don't domain match according
either to RFC 2108 or the current pre-draft.  When I tried today, after the
multiple redirections and replacements abated, I ended up with the cookies
of identical name and value:

	Domain=.msn.com
	       ||||||||
	MC1=GUID=5e1a543305d611d188a708002bb74f65

	Domain=.microsoft.com
	       ||||||||||||||
	MC1=GUID=5e1a543305d611d188a708002bb74f65

I don't know if those should be considered "long" cookie name/value pairs,
and can only image what might be accomplished if private discussions led
to the maximum of 5 redirections becoming a minimum, and my UA could be
looped through 100 redirections.  Nor am I clear on why the ability to
load users' often limited resources with large numbers of lenthy, and
perhaps redundant, cookies should be promoted by the IETF.

	The objections that were posted about the combinational requirement
merit more careful consideration, IMHO.  The intent originally was to send
both Set-Cookie2 and Set-Cookie headers during a *transitional* period to
the modern State Management design,  This is essentially a "probing" 
situation, and as soon as either the UA or server detects that modern
cookie support is implemented in its State Management partner, only
Set-Cookie2 headers will be sent to the UA by the server's replies, and
the modern Cookie header format will be used in the UAs requests to the
server.  The sending of both Set-Cookie2 and Set-Cookie header thus
will become limited to just "first contacts", which are not likely to
involve large numbers of cookies (except, perhaps in lengthy redirection
and cookie replacement loops :).

	The principle objection to the combinational requirement is that
it makes the protocol excessively complex and correspondingly unreliable,
such that it in fact serves to discourage, rather than promote, the
implementation of a modern State Management design geared toward more
nearly adequate protection of users' privacy.   The section on combining
Set-Cookie and Set-Cookie2 headers (10) says:

  [...]                                           The user agent
                                                      ^^^^^^^^^^
  interprets the combined headers as follows.  First, it must establish a
                                                         ||||^^^^^^^^^^^^
  one-to-one correspondence between the cookies in the Set-Cookie and
  ||||||||||^^^^^^^^^^^^^^^
Set-Cookie2 headers. [...]

How can the UA establish that *one-to-one* correspondence?  The cookie
name/value pairs will all be in the Set-Cookie header, and the Set-Cookie2
header will have only additional attributes.  The ONLY correspondence check
which a UA can perform is to count the number of version 1 attribute sets
folding into a Set-Cookie2 array, and compare that with the number of
historical cookies folded into a Set-Cookie array.  If the two counts
are not the same, e.g., due to some semi-colon verus comma substitution,
or any number of possible network transmission glitches, there is NO basis
here for efforts at error recovery, or any efforts, whatsoever, for bona fide
correspondence checks.  If the counts are different, for any reason, the
UA will have no alternative but simply to throw the cookies and attributes
on the floor and hope for better luck next time.

        That section also points out, parenthetically:
 
        (Note that in this case the Set-Cookie2 response header that
         the origin server sends does not, by itself, conform to this
                                 ||||||||^^^^^^^^^^^^^^^^^^^^^^^^^^^^     
         specification.)
         ^^^^^^^^^^^^^
Think about that.  Is a "transitional" procedure for sending Set-Cookie2
headers which DO NOT CONFORM TO THE SPECIFICATION a way to promote
implementation of that specification, or a way to interfere with it's
implementation?!?  Think about that carefully, please.

        It is often the case in the real world that the squeeky wheel
gets oiled first.  But if instead the wheels are being rearranged so
that the wagon won't go anywhere, perhaps that is one case in which it
it truly appropriate to just say no.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Saturday, 26 July 1997 13:41:29 UTC