From http://etherpad.com/na1WtVANL4 ...

[NOTE: THESE ARE NOT COMPLETE]

###

HTTP State WG
IEF 77

AB = Adam Barth
YP = Yngve Pettersen
MP = Mark Pauley
JR = Julian Reschke
DW = Dan Witte
RF = Roy Fielding
SC = Scott Cantor

1. Agenda bash & Blue sheets

No bashing

2. Review closed tickets (Adam Barth)

[issue and discussion missed here]

Issue #4 -- comma in set-cookie

MP: would love to be able to get rid of this

Issue #6 -- host-only cookies

IE team has expressed that they would prefer to move

Issue #2 -- semicolon in quotes

RFC 2109 allows this
didn't exist then, invented in the spec

JR: was this in the original spec?
AB: what is the original spec?
JR: Netscape document
AB: doesn't count as a spec

AB: FF has changed behavior to treat quote as any other character

Issue #9 -- editorial issue

Issue #8 -- just another test

Issue #3 -- registry controlled domains

e.g., setting cookie for "co.uk" (registry controlled)
AB: giant list of registry-controlled domains
AB: what do in the spec?
- include a huge list?
- reference publicsuffix.org ?
- some kind of heuristic?

(IE has own list, other browsers use Mozilla's list publicsuffix.org)

YP: related to "Cookie Monster" bug

Note: end of closed tickets, the scribe missed some tickets at the
beginning, will need to listen to audio...

Issue #10 -- handling i18n domains in domain attributes

DW -- we compare everything to punycode
AB: avoid putting non-unicode characters on the HTTP wire

LD:
- basic comparison issue
- step 1: know if they are valid

Issue #7 - better date parsing
DW: do we want to put text in to use 64-bit field?
AB: no text about what representable time is

RF: no chance that many devices have 64-bit date parsing - require
64-bit date parsing only when possible, allow older machines not to

YP: I did a poll, most of my colleagues have 32-bit platforms
YP: most smaller platforms have a fairly low cookie limit (e.g., 300 per
browser)
YP: not a major issue, cookies will be deleted for lack of space

MP: if browser asked to set cookie date too far in the future, clip it
to date closer in

Issue #12 - The path-match algorithm doesn't match IE or Firefox exactly
- discussion on UAs are willing to change (DW: yes)

Issue #1 -- Remove  nameless cookies?

Supported in IE, FF, and Chrome. Not in Safari.

AB: why not support it?
RF: only ever seen in JavaScript and used within that page
RF: my tendency is to say this is not legal syntax and I see no reason
to support it
AB: my sense is we want user agents to process it but say that servers
should never send it
YP: prefer to say that there is always one char in the name
JR: sounds like there is no interop on the wire here
JR: I would say don't do this
AB: we seem to require this out of document.cookie
DW: it makes me sad that we support this because of one website
DW: I'd support getting rid of this if more than one browser changes
behavior (so we don't have a special case)
DW: we should at least require equals sign
AB: I'm hearing that everyone hates this
JH: in other words, not putting this in the spec
AB: send patches to delete this in open-source browsers

Issue #5 -- Cookie ordering

AB: there are some subtle issues here
AB: could have two cookies with same name sent to server at same time
AB: browsers resolve this by accepting the first cookie
YP: perhaps spec should say that no order beyond path length
YP: either (1) be very strict or (2) servers cannot rely on ordering
MP: sort on (1) length of domain (2) length of path -- but I think
creation date doesn't matter

JH: any other major issues?

JR: any dependencies on httpbis?

AB: draft currently refers to existing spec, not bis

YP: IIRC the spec mentions recent syntax like obsolete whitespace

JR: probably safe to copy that because we're not planning to change it
JR: that way you can do the same as httpbis but not reference it

YP: we discussed what is in section 4, I suggest putting syntax as start
of section 5
YP: suggesting that we add max-age to server part of protocol
AB: max-age is not implemented in all browsers

YP: suggests having two complete syntax grammars for each of the client
and server sections of the spec

DW: asks if there's thought that IE would impl max-age
AB: don't know but one can hope

LucyLynch: would be good if priv sections get bolstered, would be a good
thing, came from Priv confab in DC and "profiling" is a hot topic

YP: <something about some RFC about priv  -- RFC2964>

MP: the test suite is quite a value-add for interop (!)

JR: perhaps test suite should be an appendix of the spec

ab: can be done (!)

JH: is there anything more to discuss from the floor?

[none]

JH: if we can address open issues then we can get this ready for WGLC

JH: do people want to address specs for doing future things for cookies?

YP: I have two or three relevant specs
1. $origin (where given cookie came from)
2. fix to address cookie monster bug
3. sub-tld / public suffix draft

MP:
- did we talk about cookie limits?
- important to us
- can have deleterious effect on web traffic
- sending many kb of cookies with each request
- some devices can't handle large cookies
- even set limit on total size of cookie headers

YP: upper limit of 4k, don't send cookie header longer than 5k

AB: spec does suggest limits

MP: perhaps something about compression of cookie headers, or some kind
of consideration

YP: servers are doing this to themselves
YP: but might be causing extra cost to users who pay by the byte

RF: was there resolution to issue about disclaimer text?
RF: I think there are many ways to use cookies that don't violate
architecture or introduce security concerns

AB: security considerations used to warn against using cookies, but we
removed that -- however we do talk about security issues

YP: should there be a definition of third-party cookies?
AB: many different definitions, could do in separate document, but I
would recommend against specifying this
JH: is the general notion of third-party cookies described in the
security considerations?
AB: good to add to privacy considerations
MP: interaction here between httpstate and browser behavior
MP: tradeoff between ability to add useful content from a third party in
a page and desire not to have your activities tracked by a third party
DW: I think it's out of scope
SC: third-party cookies can help you do session logout and clear state