A while ago I presented some thoughts about whether or not a new specification for HTTP cookies is needed to address problems with limiting cookies to a real site's domain, and not to multiple sites within a registry-like domain, such as co.uk and city.state.us, a problem that I've also discussed earlier.
I've just submitted an Internet Draft that proposes some of the suggestions I put forward in my previous article.
Compared to RFC 2965, which my draft is based on, the document removes two of the attributes, replacing them with new attributes that change the domain and path rules of cookies, respectively making the server and default path define the widest domain and path distribution possible.
The draft will be available from the IETF's Internet Draft repository, but I'm also making an archive copy available here
Comments, suggestions and alternative solutions are welcome either directly to me, or in the IETF HTTP WG mailing list after the draft has been announced there (That is also where broader discussion of the issues should take place).
Congratulations!Wording in introduction:While alternatives exists, they are more cumbersome than HTTP cookies, and cookies and their flexibility and ease of use may therefore have assisted the rapid spread of the World Wide Web.And I’d suggest making the phrase shorter. Maybe split it in several phrases.Typo:others use DNS IP address lookups of the Set-Cookie header’s Domain attribute as a heuristic metod to determine the appropriateness of permittingThat’s a quick reading of the introduction and about the changes. It’s interesting, I like the idea of SubDomain and SubPath. I didn’t get into enough details to learn about the backward compatibility of the spec (I don’t have enough time…). Maybe a few words on this?
Thanks robodesign.I’ve fixed what you pointed out.Regarding backward compatibility, there is a small section on it. Clients implementiong only this spec can’t work with sites setting cookies for parent domains, but sites that have been set up to work with the spec will work in older clients, which IMO is the important point.This is however only the first step of a process. Assuming it eventually reaches RFC status there will still be quite a few more draft versions before it reaches that status.
Yes, I agree: it’s important to have sites which use the new standard still working in the older implementations.