Re: [http-state] http-state charter

[Dan Winship <[e-mail]>]

On 07/31/2009 05:10 PM, Bil Corry wrote:
> Dan Winship wrote on 7/31/2009 11:46 AM: 
>> So I think the goal should be to first produce an Informational RFC,
>> describing real-world cookies, and then either (a) have 2965
>> reclassified as historical, or (b) write a second RFC obsoleting 2965
>> and providing a new profile of Cookie/Set-Cookie usage that is both
>> acceptable to the IETF and compatible with existing usage. (So it would
>> end up being a lot more like 2109 than 2965.)
> 
> Do you think we can skip the Informational RFC and jump straight to
> writing a RFC that obsoletes RFC 2965?

I am not an RFC expert (IANAIANA?) and am just basing this on what I've
absorbed through IETF mailing list osmosis, but there are various things
in the real-world-cookie spec that I imagine would result in it being
rejected as a standards-track RFC. Eg:

    * Cookies are built on top of HTTP, but violate one of RFC 2616's
      MUST-level rules (because Set-Cookie headers can appear more than
      once in a message but can't be merged together)

    * The handling of domains makes wildly unjustified assumptions
      about organization and delegation of authority in DNS. (And in
      fact, every implementation makes *different* assumptions.)

But if you try to fix those things, then you're no longer documenting
how cookies are *actually* implemented.

Hm... maybe we could do it by producing a "cleaned up" cookie spec, with
an appendix explaining the various ways that real-world implementations
deviate from the spec? (I guess RFC 2109 might be a starting point for
the cleaned-up spec... and it's already been accepted as an RFC.)

The question though is whether the "cleaned up" version is actually
going to be useful to anyone, or if everyone will just ignore it like
2109 and 2965. If it's not going to be used, then there's not much
reason to do things that way, as opposed to just documenting the
existing cookie behavior as a non-standards-track document. But I guess
this ties into whatever goals the WG would have *other* than
documenting-existing-cookies.

-- Dan