Subject: Re: [http-state] http-state charter

From: Dan Winship <[email-masked]>
Date: Mon, 03 Aug 2009 20:13:06 -0400

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

---

From: Ian Hickson <[email-masked]>
Date: Tue, 4 Aug 2009 00:16:26 +0000 (UTC)

On Mon, 3 Aug 2009, Dan Winship wrote:
> rejected as a standards-track RFC.

I think it's more important that we end up with an accurate spec than one 
that the IETF accepts.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Adam Barth <[email-masked]>
Date: Mon, 3 Aug 2009 17:34:43 -0700

On Mon, Aug 3, 2009 at 5:13 PM, Dan Winship<[email-masked]> wrote:
> deviate from the spec?

This approach would start us down the same path that has doomed
previous cookie RFCs to the dust bin of uselessness.

Adam

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 03 Aug 2009 19:08:20 -0600

> I think it's more important that we end up with an accurate spec than one 

The distinction between Informational and Standards Track RFCs seems
apropos here (consult RFC 2026 for details).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Barth <[email-masked]>
Date: Mon, 3 Aug 2009 18:57:00 -0700

> apropos here (consult RFC 2026 for details).

Forgive my ignorance of IETF process, but RFC 2026 says:

[[
   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.
]]

The "Informational" status does not appear appropriate for this
document because the Internet community seems to have reached
consensus about the behavior of the Cookie and Set-Cookie header as
evidenced by billions of such headers traveling over the Internet
between hundreds of implementations every day.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 4 Aug 2009 09:14:47 +0200 (CEST)

On Mon, 3 Aug 2009, Adam Barth wrote:

> The "Informational" status does not appear appropriate for this document 
> because the Internet community seems to have reached consensus about the 
> behavior of the Cookie and Set-Cookie header as evidenced by billions of 
> such headers traveling over the Internet between hundreds of implementations 
> every day.

As on author of one of those hundreds, I for sure would've appreciated the 
existance of such a document when I started my work.

If clarifying the existing practise isn't what you want to see, what exactly 
do you want?

Both RFC2109 and 2965 failed because they tried to engineer a new cookie 
concept that no author was interested in. I don't see how craftning yet 
another new thing has any better chance this time, so the "only" remaining 
work is instead documenting how things actually work today.

Or what am I missing?

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Tue, 4 Aug 2009 02:19:13 -0700

> If clarifying the existing practise isn't what you want to see, what exactly

That is what I want to do.  :)

More specifically, I think we should document behavior that is broadly
interoperable.  For behaviors that differ between major
implementations, we should use our judgement and spec the most sane
thing.

> work is instead documenting how things actually work today.

I think we should obsolete those cookie specs and replace them with a
standards track cookie spec that is actually useful.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 4 Aug 2009 11:31:17 +0200 (CEST)

> standards track cookie spec that is actually useful.

I certainly would have no problems with that!

-- 

  / daniel.haxx.se

---

From: Bil Corry <[email-masked]>
Date: Tue, 04 Aug 2009 10:37:19 -0500

> standards track cookie spec that is actually useful.

I agree.  How do we then resolve the concerns Dan Winship brought up?  Should we bring them up on the ietf-http-wg list and ask for their advice?  I did see that the latest httpbis draft contains a note about Cookies violating the header-combining rule:

-----
      Note: the "Set-Cookie" header as implemented in practice (as
      opposed to how it is specified in [RFC2109]) can occur multiple
      times, but does not use the list syntax, and thus cannot be
      combined into a single line.  (See Appendix A.2.3 of [Kri2001] for
      details.)  Also note that the Set-Cookie2 header specified in
      [RFC2965] does not share this problem.

from: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-4.2
-----

I'll have to dig through the ietf-http-wg list to see what their thoughts were when they created the note.

The quote above references a document from David Kristol about the history of cookies and his experience with creating RFC2964.  Looks like a cautionary tale:

http://arxiv.org/PS_cache/cs/pdf/0105/0105018v1.pdf

- Bil

---

From: Julian Reschke <[email-masked]>
Date: Tue, 04 Aug 2009 17:45:06 +0200

Bil Corry wrote:
> ...
> ..

See 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#changes.since.03>, 
which will lead you to 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/129>, which in turn 
is linked to an email thread from 2008: 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2008AprJun/0584.html>, 
and subsequent messages around 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/0300.html>.

BR, Julian

---

From: Pascal Gaudette <[email-masked]>
Date: Tue, 4 Aug 2009 16:41:52 -0400

Hi all,

I'm very new to both this list and the IETF, but I wanted to ask a question
that might have been discussed in the past, possibly even face to face
during IETF meetings...

The members of this list are currently discussing what type of standards
document the WG might end up writing.  But has there been any thought given
to the development of a set of whitebox user-agent tests that could be
deployed on a domain and used to *document* currently deployed user-agent
behavior? (IE produce a table of observed behavior vrs user-agent and test
case.)

I would see this as a very useful deliverable for the working group to
produce prior to any specification document, and I can see myself adding
test cases to such a test suite (provided it is written in a language I am
familliar with).  I am currently in the process of trying to implement
cookie support in a simple user-agent as part of Google's Summer of Code and
such a suite would be very useful to me... Many members of this list
probably have extensive knowledge of user-agent behavior, both where they
converge and where they diverge.  Deploying such a test suite would allow
the gathering of all such knowledge in a single, public place.

Unless such a thing already exists, in which case I shall be very happy to
be provided with a pointer...

Just some thoughts,
-- 
Pascal Gaudette <[email-masked]>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Aug 2009 18:26:49 -0700

FWIW -

Almost every discussion I've had with people in the IETF regarding  
cookies could be characterised as "we need to document how cookies  
actually work."

I would encourage people on this list to discuss how to make that  
happen, and not to try to second-guess the IETF process, what will and  
will not be acceptable to the IESG, etc; we'll get there soon enough.

Cheers,

On 04/08/2009, at 1:41 PM, Pascal Gaudette wrote:

> Hi all,
>
> I'm very new to both this list and the IETF, but I wanted to ask a  
> question that might have been discussed in the past, possibly even  
> face to face during IETF meetings...
>
> The members of this list are currently discussing what type of  
> standards document the WG might end up writing.  But has there been  
> any thought given to the development of a set of whitebox user-agent  
> tests that could be deployed on a domain and used to *document*  
> currently deployed user-agent behavior? (IE produce a table of  
> observed behavior vrs user-agent and test case.)
>
> I would see this as a very useful deliverable for the working group  
> to produce prior to any specification document, and I can see myself  
> adding test cases to such a test suite (provided it is written in a  
> language I am familliar with).  I am currently in the process of  
> trying to implement cookie support in a simple user-agent as part of  
> Google's Summer of Code and such a suite would be very useful to  
> me... Many members of this list probably have extensive knowledge of  
> user-agent behavior, both where they converge and where they  
> diverge.  Deploying such a test suite would allow the gathering of  
> all such knowledge in a single, public place.
>
> Unless such a thing already exists, in which case I shall be very  
> happy to be provided with a pointer...
>
> Just some thoughts,
> -- 
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state

--
Mark Nottingham     http://www.mnot.net/

---

From: Bil Corry <[email-masked]>
Date: Tue, 04 Aug 2009 21:31:42 -0500

> will not be acceptable to the IESG, etc; we'll get there soon enough.

So is it agreed then that this WG will work to produce a RFC that specifies Cookies as-they-exist-today?

Our charter currently reads (in part):

"The working group will create a new RFC that obsoletes RFC 2965 and
specifies Cookies as they are used in existing implementations and
deployments."

Does that work?

- Bil

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 5 Aug 2009 09:18:54 +0200 (CEST)

On Tue, 4 Aug 2009, Pascal Gaudette wrote:

> I am currently in the process of trying to implement cookie support in a 
> simple user-agent as part of Google's Summer of Code and such a suite would 
> be very useful to me... Many members of this list probably have extensive 
> knowledge of user-agent behavior, both where they converge and where they 
> diverge.

Actually, I would say it would probably help us all if you ask questions about 
grey areas or so on this list when you face them. It can be useful to put the 
light on specific areas of the cookie behaviors.

> Deploying such a test suite would allow the gathering of all such knowledge 
> in a single, public place.

While I won't argue that such a test suie will be very useful (not the least 
for interop), but the outcome of this group's effort is supposedly a spec that 
would contain all this info "in a single, public place."

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Wed, 05 Aug 2009 11:16:31 -0400

On 08/04/2009 11:37 AM, Bil Corry wrote:
> I agree.  How do we then resolve the concerns Dan Winship brought up?

Ignore them. It doesn't matter. There seems to be basically universal
consensus in the group that the most important thing is to have a
description of how cookies actually currently work. So let's write that.
Exactly how and where it gets published is not really that important. If
the end result is acceptable as a replacement for 2965, then great, we
publish it as that. If it's not, then we publish it as Informational. If
we can't push it through the RFC process at all then we publish it
through WHATWG or somewhere else. It doesn't matter; the document
doesn't need to have the blessing of any formal standards body anyway,
because its goal is to describe reality, not to try to change it.

-- Dan

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Aug 2009 09:28:29 -0700

I think it's agreed that we need to document current behaviour. How  
and where that happens, as well as its relationship to existing specs  
is still something that needs to be discussed more widely, I think.

Cheers,