Subject: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG?

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Aug 2007 17:35:07 +0100

Hi folks,
Answers to this question during the BOF were not conclusive, so I would 
like to poll mailing list members on whether revision of RFC 2965 (HTTP 
State Management Mechanism) should be in scope for the proposed WG.

Question: Should RFC 2965 revision be in scope for the WG?

Please chose one of the following answers:

1). No
2). Yes
3). Maybe (this includes "yes, but when the WG completes the currently 
proposed milestones" and "yes, but this should be done in another WG")
4). I have another opinion, which is ....

Please send answers to the mailing list, or directly to me *and* Mark 
Nottingham <[email-masked]>.
And of course feel free to ask clarifying questions/correct list of answers.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 12 Aug 2007 15:20:42 +0200

> And of course feel free to ask clarifying questions/correct list of 

3. As long as it doesn't take away cycles from delivering RFC2616bis.

Best regards, Julian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 12 Aug 2007 19:54:25 +0200

> 4). I have another opinion, which is ....

My response:

Yes - updating of 2965 to document how the mechanism works, and possibly 
describing issues due to non-conformant uses and inherent limitations in 
the mechanism, SHOULD be in scope for the WG.

No - creating a new cookie mechanism to supplant the one specified in 2965 
SHOULD NOT be in scope for the WG.

That doesn't fit any of alternatives 1-3, so I'm a 4....

---

From: Leif Johansson <[email-masked]>
Date: Mon, 13 Aug 2007 10:50:43 +0200

Harald Tveit Alvestrand wrote:
> Yes - updating of 2965 to document how the mechanism works, and
> possibly describing issues due to non-conformant uses and inherent
> limitations in the mechanism, SHOULD be in scope for the WG.
>
> No - creating a new cookie mechanism to supplant the one specified in
> 2965 SHOULD NOT be in scope for the WG.
>
Actually that sounds like 2 - it sais "revisions", not "reinvention" :-)
But whatever the number agree
with what you say.

    Cheers Leif

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 13 Aug 2007 10:45:04 +0100

> That doesn't fit any of alternatives 1-3, so I'm a 4....

Good point. I've implicitly assumed that new mechanisms of any sort are 
out of scope for the WG. Otherwise the proposed WG would have HTTPEXT 
acronym ;-)
With this clarification, I think your answer is 2).

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Aug 2007 21:23:09 +0100

Alexey Melnikov wrote:

> Hi folks,
> Answers to this question during the BOF were not conclusive, so I 
> would like to poll mailing list members on whether revision of RFC 
> 2965 (HTTP State Management Mechanism) should be in scope for the 
> proposed WG.
>

If you haven't replied to this question, please send your replies by 
September 3rd.

Thanks,
Alexey

---

From: Stefanos Harhalakis <[email-masked]>
Date: Tue, 28 Aug 2007 20:04:49 +0300

> If you haven't replied to this question, please send your replies by

I don't know if I'm supposed to vote, but I'd suggest 1 (No). The rationale 
can be summarized in the question: "Why yes?".

---

From: Stefanos Harhalakis <[email-masked]>
Date: Tue, 28 Aug 2007 20:44:10 +0300

> can be summarized in the question: "Why yes?".

 Sorry for replying to self but I'd like to change that to 4:
Discuss it in the list first. 

  Then, maybe vote for '3'.

  After reading the minutes (again), I understand that this will only change 
RFC 2695 to 'become' the Netscape doc. So, I don't actually see it as a hi 
priority issue, thinking that a well accepted document already exists 
(Netscape) and there is no confusion. Also, shouldn't this become a new RFC 
that will replace 2695?

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Aug 2007 15:41:15 -0400

3. maybe

in particular, the group might consider that the privacy mechanisms
specified have not worked so well, and consider whether there should be
some additional protection for users against abuse of cookies.  I don't
think it would be appropriate for the WG to relax protections against
cookie abuse.

however this topic might be a rathole and might best be deferred until
the group has completed other milestones.
>> 3). Maybe (this includes "yes, but when the WG completes the
>> currently proposed milestones" and "yes, but this should be done in
>> another WG")

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 30 Aug 2007 01:34:57 +0200

> 4). I have another opinion, which is ....

3.

Not convinced it really requires yet another revision or that it needs
to be rolled into the HTTP/1.1 protocol standard as such.

Regards
Henrik

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 31 Aug 2007 08:17:40 -0700

Cookies: Yes

At least logically, cookies belong in the base HTTP specs.
But I wouldn't put it as "revising" RFC 2965, just trying to
figure out what to do to accommodate the current situation with regard
to state management in HTTP.

2817/2818: I'm on the side of "separate working group for HTTP security";
not that I don't think it should be handled, but that you're more likely
to make progress with a WG specifically chartered to deal with HTTP
security as a narrower focus.

Larry