Subject: [http-state] my thoughts about the group's work

From: Dave Kristol <[email-masked]>
Date: Sat, 22 Aug 2009 20:27:01 -0400

Hi, folks.

I've been hesitant to weigh in to your discussions, because I don't 
expect to be very active in this group's work.  However, I feel obliged 
to point some things out, based on my experience with RFCs 2109 and 
2965.  I'd also encourage you to read my paper, which Adam cited a few 
days ago:  <http://arXiv.org/abs/cs.SE/0105018>, even though it's long. 
  (A closely related version was published in ACM Transactions on 
Internet Technology, Vol. 1, #2.)  If you do, you may avoid some of the 
painful lessons I learned the hard way.

I think it's a great idea that you've set out to document the current 
state of the cookies world.  I have been asked several times to do just 
that, and I've been asked why the aforementioned RFCs didn't do so.  One 
reason is that, at the time we began work on what became RFC 2109 (early 
1996), Netscape Navigator had been available for about 16 months, and 
the first version of Internet Explorer had been available about four 
months.  IE didn't support cookies until Oct., 1995 
(<http://www.microsoft.com/windows/ie/community/columns/historyofie.mspx>). 
  So, for practical purposes, at the time we began work, Navigator was 
it.  Things are different now, of course.

I want to strongly discourage you from trying to do more that describe 
the current state of things.  The temptation either to add features or 
to prescribe behavior can be very strong.  Don't.  At least not in what 
you're working on now.  One of the lessons in my paper is that you can't 
succeed in changing things if you don't have the buy-in of the 
stakeholders.  In 1996, the list was short, I thought we did, and it 
looked possible.  But in the end, as you know, hardly any of the "big 
boys" chose to follow the RFC(s).  Today there are at least four 
significant browsers and countless websites that use cookies.  The odds 
of nudging them away from what they're doing now are, IMO, very small.

I think it was Adam who expressed the sentiment that the result of your 
work should serve as a guide to implementors.  That's a great idea. 
However, my experience in this and other related endeavors is that most 
developers don't read standards, even if they know they exist.  At best 
they rely on books that people have written about the subject, which may 
contain misinformation, or they use the empirical approach:  "It seems 
to work in Firefox and IE.  That should be good enough."

So, for what it's worth, my advice would be to document in detail only 
what exists now.  That should result in a union and an intersection set 
of behaviors for clients and servers.  Based on Postel's advice to "Be 
liberal in what you accept and conservative in what you send," 
recipients should be able to handle the union set (or a large portion of 
it) and should send only what's in the intersection set.

Dave Kristol