Dave Kristol wrote: 
Foteos Macrides <MACRIDES@SCI.WFBR.EDU> wrote:
  > [...]
  >     (1) In section 10.3 concerning compatibility with MicroSoft's
  > implementation, the wording implies that this is a "proper" Version
  > 1 Set-Cookie header:
  > Set-cookie: xx="1=2&3-4";
  >     Comment="blah";
  >     Version=1; Max-Age=15552000; Path=/;
  >     Expires=Sun, 27 Apr 1997 01:16:23 GMT
  > which MicroSoft's parser mishandles by sending:
  >     Cookie: Max-Age=15552000
  > instead of the "correct"
  >     Cookie: xx="1=2&3-4"
  >     "Expires" is not one of the attribute names for Version 1
  > cookies.  Thus, isn't it a valid cookie name, and isn't it's presence
  > in a Set-cookie header that claims to be Version 1 but expects it to
  > be handled as a Version 0 Expires attribute invalid?  Also, skipping
  > that Expires ambiguity, isn't this what's "correct":

The sub-group originally thought it would be possible to send a single
Set-Cookie that would work with V0 and V1 cookies.  V0-capable browsers
wouldn't know what to do with the new stuff and would just pay
attention to the new.  V1-capable browsers would pay attention only to
what they understood and ignore the rest.  So the example Set-Cookie,
containing both Max-Age and Expires, could serve both.  Unfortunately,
MSIE can't handle this example.

(N.B.  I don't believe Netscape would handle the example Expires date.
Their spec said Wdy, DD-Mon-YY HH:MM:SS GMT.  Lou?  Ari?  Care to
Versions since 2.0 should be able to handle any date format you
throw at it.