Subject: [http-state] wrt documenting current practice or/and specifying new beharvior (was: Kristol: my thoughts about the group's work)

From: =JeffH <[email-masked]>
Date: Thu, 27 Aug 2009 15:55:03 -0700

Dave Kristol <[email-masked]> wrote on Sat, 22 Aug 2009 20:27:01 
-0400 (17:27 PDT):
 >
 > ...
 > I want to strongly discourage you from trying to do more that describe
 > the current state of things.  The temptation either to add features or
 > to prescribe behavior can be very strong.  Don't.  At least not in what
 > you're working on now. ...
 >
 > So, for what it's worth, my advice would be to document in detail only
 > what exists now.

Dave has very eloquently argued for a particular outcome of what I (and others) 
see as the crux of chartering and formally launching this effort as an IETF WG 
-- whether to just document present behavior or to do that plus specifying new 
behavior.

I had been composing a similar message to the group but Dave says it way better 
than I could and of course with direct experience in the topic at hand.

Based on Dave's input, I propose (as I've more or less said in the prior 
charter thread(s))..

1. the immediate work item is documenting present client and server cookie 
behavior to some agreed-upon value of "best effort".

Whether this document is on the informational or standards track is TBD. There 
is ample precedent that I'm aware of for Informational track for such a 
document. There may also be for Standards track. In any case, I think it is a 
2nd order concern, and is really a call for our ADs and the IESG to make (with 
our input of course).

draft-abarth-cookie-xx and the associated tests & harness are of course an 
excellent start for this effort.

2. the follow-on work item is new HTTP state-management (nee "cookie") 
behaviors and capabilities (e.g. draft-pettersen-cookie-v2-xx). Whether to 
spend cycles on them in parallel, or after completing (1) is a BoF and 
chartering topic.

Unless there are gobs of on-going cycles available over the next year+ for 
review and contribution to both (1) and (2) concurrently, my vote would be for 
(1) to be addressed first, then (2). "New" capabilities that we identify in the 
process of working through (1) can be slid into a list or on-going 
working-draft to await the stack being popped.

thoughts?

=JeffH

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 28 Aug 2009 09:26:00 +0200 (CEST)

On Thu, 27 Aug 2009, =JeffH wrote:

> review and contribution to both (1) and (2) concurrently, my vote would be 
> for (1) to be addressed first, then (2). "New" capabilities that we identify 
> in the process of working through (1) can be slid into a list or on-going 

+1

There's also a different nature of discussions between (1) and (2) and 
possibly also a different set of people who would be interested in 
participating between (1) and (2) so I think it makes perfect sense to do them 
cronologically.

Unfortunately, I'm not going to be in Hiroshima.

-- 

  / daniel.haxx.se

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 28 Aug 2009 11:23:04 +0200

On Fri, 28 Aug 2009 00:55:03 +0200, =JeffH <[email-masked]>  
wrote:
> [...]

 From my perspective documenting existing practice has no real value as it  
does not lead to improvements of our cookie implementation. Repeating  
myself, if Opera does something different than the other four main  
browsers I'd rather we make Opera non-conforming than have that particular  
situation not defined at all by the specification because implementations  
did not agree.

I have outlined in my charter feedback how I think we can be successful  
even if we require changes to some implementations, but have not had  
replies to that so far.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Aug 2009 11:39:46 +0200

Anne van Kesteren wrote:
> On Fri, 28 Aug 2009 00:55:03 +0200, =JeffH 
> <[email-masked]> wrote:
>> [...]
>>
>> thoughts?
> 
>  From my perspective documenting existing practice has no real value as 
> it does not lead to improvements of our cookie implementation. Repeating 
> browsers I'd rather we make Opera non-conforming than have that 
> particular situation not defined at all by the specification because 
> implementations did not agree.
> 

This stays controversial.

Documenting how cookies work in practice *includes* identifying things 
that currently vary across implementations. If implementations vary, and 
can get away with it, it means it's not *necessary* to specify a 
concrete behavior.

BR, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 28 Aug 2009 11:58:02 +0200

On Fri, 28 Aug 2009 11:39:46 +0200, Julian Reschke <[email-masked]>  
wrote:
>> it does not lead to improvements of our cookie implementation.  
>> Repeating myself, if Opera does something different than the other four  
>> main browsers I'd rather we make Opera non-conforming than have that  

I haven't seen many people disagree actually.

> can get away with it, it means it's not *necessary* to specify a  

You're making three assumptions that I think are false:

   1. That users of minority implementation O visit the same set of sites
      the users of implementations F, I, C, and S visit.
   2. That users of minority implementation O always report an issue if
      they encounter one.
   3. That implementation O has no known issues it intends to fix soon.

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 28 Aug 2009 12:54:48 +0200 (CEST)

> 3. That implementation O has no known issues it intends to fix soon.

A concern I have with fixing problems in current cookie behavior is that we 
then very easily slide away on the slippery slope and start thinking about how 
to fix all those problems we have in the protocol already and the next we know 
we're on the RFC2965 road to no-good-land.

The main problem we have with "documenting current behavior" is to identify 
the minorities that we actually deem are wrong and not document them as valid 
current practise. Wrong would be behaviors that are incompatible with the 
behaviors that the (vast) majority does - but only if the difference causes 
the implementations to behave significantly different.

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Fri, 28 Aug 2009 10:32:15 -0400

> implementations did not agree.

Hm... I think you're arguing against something he wasn't necessarily
arguing for... There is actually a three-way split here, not two-way:

    1. Document what existing implementations do, noting differences
       (descriptive spec)

    2. Document what a hypothetical implementation should do if it
       wants to be maximally interoperable (normative spec)

    3. Document what we wish implementations did, a la RFC 2109/2965
       ("optative spec"?)

Part of our problem seems to be that some people are considering the
normative spec to be "documenting existing practice", while others are
considering it to be "specifying new behavior".

Skimming the archive, it looks to me like you, me, Adam, and Ian are
arguing for a normative spec, and Daniel and maybe Julian are arguing
for a descriptive spec. Dave Kristol's email and the current spec text
hover somewhere between the descriptive and normative specs ("document
but recommend"). Your suggested update to the spec pushes it firmly to
normative.

For people who are against the normative spec on the grounds that it's
"specifying new behavior"; the argument against specifying new behavior
was that 2109 and 2965 failed because web sites didn't want to depend on
the new behaviors until most clients had been updated to support them,
but some clients were never updated to support the new behaviors, and so
as a result the new behaviors never got used. But that concern doesn't
apply to this spec--the entire point of this spec is to describe how to
interoperate with other people who *aren't* following the spec, so
opting in to it would make you *more* compatible, not less. So while it
may not, strictly speaking, count as "documenting current practice", it
doesn't have the problems that make us want to avoid "specifying new
behavior".

-- Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 28 Aug 2009 16:43:58 +0200 (CEST)

>    3. Document what we wish implementations did, a la RFC 2109/2965

I think this is a pretty decriptive way of seeing our possibilities. The lines 
between the different areas are a bit blurry at times though.

> Skimming the archive, it looks to me like you, me, Adam, and Ian are arguing 
> for a normative spec, and Daniel and maybe Julian are arguing for a 
> descriptive spec.

My primary motivation for staying in camp (1) has been since that's how I've 
viewed our set out task and then I've seen it as a worthwhile task to make 
sure we stay within set the boundaries.

If we decide we should rather be more camp (2), then I'll be willing to adjust 
to that and quickly adapt to match the other campers in here.

-- 

  / daniel.haxx.se

---

From: Dave Kristol <[email-masked]>
Date: Fri, 28 Aug 2009 11:30:02 -0400

> doesn't have the problems that make us want to avoid "specifying new

My argument was that recommending or, especially, specifying behavior is 
fruitless unless you have buy-in from the people who would make changes 
to the servers and browsers, i.e., the *vendors*.  And even then you 
face the problem that zillions of web apps might also need to be 
changed.  Things were much simpler in 1996, and we still failed to make 
recommendations stick.

My recommendation:  stick to the things you can control.

Dave Kristol

---

From: Adam Barth <[email-masked]>
Date: Fri, 28 Aug 2009 09:29:00 -0700

On Fri, Aug 28, 2009 at 7:43 AM, Daniel Stenberg<[email-masked]> wrote:
> I think this is a pretty decriptive way of seeing our possibilities. The
> lines between the different areas are a bit blurry at times though.

The line we should be worried about is between (2) and (3), but I
don't think it's that blurry.  As long as we stick to recommending
user agent behavior that is already "broadly" implemented (where we
take broadly to be some relatively objective criterion like 4 of 5
major browsers), then I think we'll avoid recommending things that
user agents will be unwilling or unable to implement.

To me, there seems to be a large difference between the changes
required by 2109/2965 and the normative requirements we're
considering.  For example, 2109 requires "Version=1" even though no
user agents do this.

> If we decide we should rather be more camp (2), then I'll be willing to
> adjust to that and quickly adapt to match the other campers in here.

I think our work will be most valuable of we reside in camp (2).  I'm
glad that we have some conservative voices in the group to help us
avoid slipping into camp (3).

On Fri, Aug 28, 2009 at 8:30 AM, Dave Kristol<[email-masked]> wrote:
> fruitless unless you have buy-in from the people who would make changes to
> the servers and browsers, i.e., the *vendors*.

Yes.  Getting buy-in from vendors is important.  I'm happy that Opera
has made their buy-in clear on this list.  I'm in contact with the
various vendors.  While no one has said "go to town and we'll
implement whatever you spec," the prevailing mood seems to be "cookie
compatibility is a pain point and we wish we had a spec we could
actually follow and still interoperate with the web."  I think we
should see producing that spec as our goal for "phase 1," as Jeff
calls it.

> And even then you face the problem that zillions of web apps might also need to be changed.

I don't think we should recommend *any* changes that require web apps
to change in any way.  That's too big a mountain for us to move.
Instead, we should focus on detailing how a user agent can best
interoperate with existing web apps.

Adam

---

From: Dirk Pranke <[email-masked]>
Date: Fri, 28 Aug 2009 12:45:59 -0700

On Fri, Aug 28, 2009 at 9:29 AM, Adam Barth<[email-masked]> wrote:
> don't think it's that blurry.

[snip]

> avoid slipping into camp (3).

Adam, correct me if I'm wrong, but it seems a primary motivation for
this whole exercise is to clarify what actual does and doesn't work
with cookies, *to clarify the various security implications of
cookies*. As such, both (1) and (2) are terribly important, because
they can tell application developers what will and won't work, and
what is or isn't safe, and I think that there is a lot of value to be
had there.

I agree that (3) is a very different effort. Kudos to Dan for breaking
it down nicely.

-- Dirk

---

From: Adam Barth <[email-masked]>
Date: Fri, 28 Aug 2009 23:35:55 -0700

> what is or isn't safe, and I think that there is a lot of value to be

I suspect different folks have different motivations for helping out,
but my motivation is twofold:

1) Make it easier to implement a new user agent that interoperates
with existing servers
2) Improve interoperability between user agents

In the process of writing this spec, we're going to generate a lot of
knowledge about the quirks of various user agents.  I agree this would
be useful to document, either in an appendix or in a separate
document.  I'm hopeful the test suite will make this task fairly
straightforward.

Adam