Re: [http-state] comments on http-state charter
=JeffH
> Thank you for the suggestions, I've (mostly) incorporated them. Below is the
> latest draft of the charter --
super, thanks.
> I've purposely left off the WG task of
> creating new features for cookies and instead made the focus of the WG to
> only document existing cookie behavior. This is based on the feedback I've
> seen so far and I think it'll help keep us from getting distracted.
agreed.
> Also, I
> think it'll be challenging to add new features until we have a spec that
> enumerates existing behavior. However, rather than having to form the WG
> again to address new features, we could allow the WG to elect to tackle new
> features at a future date -- perhaps after the bulk of the work for the
> primary task is completed.
yes, the working group can be re-chartered at a later date.
minor comments on the latest charter draft below.
thanks,
=JeffH
> Charter: HTTP State Management Mechanism (http-state) WG
>
> Last Modified: 2008-08-10
>
> Mailing Lists:
> General Discussion: http-...@ietf.org
> To Subscribe: https://www.ietf.org/mailman/listinfo/http-state
> Archive: http://www.ietf.org/mail-archive/web/http-state/current/maillist.html
> Alternative Archive: http://groups.google.com/group/http-state
>
> Description of Working Group:
>
> The HTTP State Management Mechanism (aka Cookies) was originally
> created by Netscape Communications in their informal Netscape cookie
> specification ("cookie_spec.html"), from which formal specifications
> RFC 2109 and RFC 2965 evolved. The formal specifications, however,
> were never fully implemented in practice; RFC 2109, in addition to
> cookie_spec.html, more closely resemble real-world implementations
> than RFC 2965, even though RFC 2965 officially obsoletes the former.
> Compounding the problem are undocumented features (such as HTTPOnly),
> and widely varying behaviors among real-world implementations.
^
cite..
http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies
..here?
> The working group will create a new RFC that obsoletes RFC 2965 and
> specifies Cookies as they are actually used in existing
> implementations and deployments. Where differences exist among the
> most common implementations, the working group will document the
> variations and provide a recommended choice for new implementations.
^
updates and
> This will also allow existing implementations to improve
^^^^^
facilitate
> interoperability if they so choose.
>
> The following specifications, RFCs and Internet-Drafts should be
^
documents,
> considered:
> * cookie_spec.html - Netscape Cookie Specification
>
http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html
* Browser Security Handbook
http://code.google.com/p/browsersec/wiki/Main
> * RFC 2109 - HTTP State Management Mechanism (Obsoleted by RFC 2965)
> http://tools.ietf.org/html/rfc2109
> * RFC 2964 - Use of HTTP State Management
> http://tools.ietf.org/html/rfc2964
> * RFC 2965 - HTTP State Management Mechanism (Obsoletes RFC 2109)
> http://tools.ietf.org/html/rfc2965
> * Widely Implemented - HTTPOnly
> http://www.owasp.org/index.php/HTTPOnly
>
> Goals and Milestones:
> TBD
---
end
_______________________________________________
http-state mailing list
http-...@ietf.org
https://www.ietf.org/mailman/listinfo/http-state
Bil Corry
> minor comments on the latest charter draft below.
Thanks, below is the current draft. Additional feedback welcome.
- Bil
Charter: HTTP State Management Mechanism (http-state) WG
Last Modified: 2009-08-18
Mailing Lists:
General Discussion: http-...@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/http-state
Archive: http://www.ietf.org/mail-archive/web/http-state/current/maillist.html
Alternative Archive: http://groups.google.com/group/http-state
Description of Working Group:
The HTTP State Management Mechanism (aka Cookies) was originally
created by Netscape Communications in their informal Netscape cookie
specification ("cookie_spec.html"), from which formal specifications
RFC 2109 and RFC 2965 evolved. The formal specifications, however,
were never fully implemented in practice; RFC 2109, in addition to
cookie_spec.html, more closely resemble real-world implementations
than RFC 2965, even though RFC 2965 officially obsoletes the former.
Compounding the problem are undocumented features (such as HTTPOnly),
and widely varying behaviors among real-world implementations.
The working group will create a new RFC that obsoletes RFC 2965 and
specifies Cookies as they are actually used in existing
implementations and deployments. Where differences exist among the
most common implementations, the working group will document the
variations and provide a recommended choice for updates and new
implementations. This will also facilitate interoperability among
existing implementations if they so choose.
The following specifications, RFCs, Internet-Drafts and documents
should be considered:
* cookie_spec.html - Netscape Cookie Specification
http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html
* RFC 2109 - HTTP State Management Mechanism (Obsoleted by RFC 2965)
http://tools.ietf.org/html/rfc2109
* RFC 2964 - Use of HTTP State Management
http://tools.ietf.org/html/rfc2964
* RFC 2965 - HTTP State Management Mechanism (Obsoletes RFC 2109)
http://tools.ietf.org/html/rfc2965
* I-D - HTTP State Management Mechanism v2
http://tools.ietf.org/html/draft-pettersen-cookie-v2
* I-D - Cookie-based HTTP Authentication
http://tools.ietf.org/html/draft-broyer-http-cookie-auth
* Widely Implemented - HTTPOnly
http://www.owasp.org/index.php/HTTPOnly
* Browser Security Handbook - Cookies
http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies
* HTTP Cookies: Standards, Privacy, and Politics by David M. Kristol
http://arxiv.org/PS_cache/cs/pdf/0105/0105018v1.pdf
Julian Reschke
> ...
> The working group will create a new RFC that obsoletes RFC 2965 and
> specifies Cookies as they are actually used in existing
> implementations and deployments. Where differences exist among the
> most common implementations, the working group will document the
> variations and provide a recommended choice for updates and new
> implementations. This will also facilitate interoperability among
> existing implementations if they so choose.
Anne correctly mentioned that in RFC2119 terms, "recommended" is the
same as "RECOMMENDED", which in turn is the same as "SHOULD".
So when the charter say "provide a recommended choice", is this about
making normative requirements? I think this really needs to be clarified.
BR, Julian
Yngve N. Pettersen
> The working group will create a new RFC that obsoletes RFC 2965 and
> specifies Cookies as they are actually used in existing
> implementations and deployments.
I am not sure about this point, *unless* the intention is to include the
entire RFC 2965 specification (including headers and header syntax) in the
new specification. If that is the intention, I think it should be spelled
out, since RFC 2965 defines a different syntax.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yn...@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
********************************************************************
Adam Barth
> On Wed, 19 Aug 2009 03:50:01 +0200, Bil Corry <b...@corry.biz> wrote:
>> The working group will create a new RFC that obsoletes RFC 2965 and
>> specifies Cookies as they are actually used in existing
>> implementations and deployments.
>
> I am not sure about this point, *unless* the intention is to include the
> entire RFC 2965 specification (including headers and header syntax) in the
> new specification. If that is the intention, I think it should be spelled
> out, since RFC 2965 defines a different syntax.
I don't think our intention is to support all the features of 2965 in
our first document, just as we're not going to support all the
features of 2109. Is creating a feature superset required for
obsoleting an RFC? That would seem to preclude ever removing features
that were not adopted by the marketplace.
Adam
=JeffH
Only issue I can see at this point is the omission of a ref to..
http://tools.ietf.org/html/draft-abarth-cookie-01
=JeffH
Yngve Nysaeter Pettersen
On Wed, 19 Aug 2009 17:50:55 +0200, Adam Barth <ie...@adambarth.com> wrote:
> On Wed, Aug 19, 2009 at 7:01 AM, Yngve N. Pettersen<yn...@opera.com>
> wrote:
>> On Wed, 19 Aug 2009 03:50:01 +0200, Bil Corry <b...@corry.biz> wrote:
>>> The working group will create a new RFC that obsoletes RFC 2965 and
>>> specifies Cookies as they are actually used in existing
>>> implementations and deployments.
>>
>> I am not sure about this point, *unless* the intention is to include the
>> entire RFC 2965 specification (including headers and header syntax) in
>> the
>> new specification. If that is the intention, I think it should be
>> spelled
>> out, since RFC 2965 defines a different syntax.
>
> I don't think our intention is to support all the features of 2965 in
> our first document, just as we're not going to support all the
> features of 2109. Is creating a feature superset required for
> obsoleting an RFC?
I think we might need input from an AD on that, but IMO the proposed
document will at most obsolete 2109 (again), but is updating a
specification that is in many areas different from RFC 2965 (particualrly
the Set-Cookie2 header syntax), and which is following a parallel track.
One way to think about it is that if Netscape cookies are v0.1 (just to
keep with the 2965 version numbering), 2965 cookies are v1.0, then the
proposed document might be considered v0.5, on a different branch/fork of
the cookie specification.
> That would seem to preclude ever removing features
> that were not adopted by the marketplace.
Again, I think an AD will provide better information, but my impression is
that that happens as part of moving a specification from Proposed Standard
to Draft Standard and then to Full Standard, based on a minimum of
interoperable implementations.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yn...@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
********************************************************************
Adam Barth
<yn...@opera.com> wrote:
> I think we might need input from an AD on that, but IMO the proposed
> document will at most obsolete 2109 (again), but is updating a specification
> that is in many areas different from RFC 2965 (particualrly the Set-Cookie2
> header syntax), and which is following a parallel track.
Fair enough.
> One way to think about it is that if Netscape cookies are v0.1 (just to keep
> with the 2965 version numbering), 2965 cookies are v1.0, then the proposed
> document might be considered v0.5, on a different branch/fork of the cookie
> specification.
That's an interesting way of thinking about the issue. From my
perspective, it's most important to obsolete the RFCs that using
conflicting syntax (e.g., requiring $Version=1 in the Set-Cookie
header). Specifications that use new HTTP headers (e.g., Set-Cookie2)
don't seem to be in direct conflict.
Adam
Yngve N. Pettersen (Developer Opera Software ASA)
>> One way to think about it is that if Netscape cookies are v0.1 (just to
>> keep
>> with the 2965 version numbering), 2965 cookies are v1.0, then the
>> proposed
>> document might be considered v0.5, on a different branch/fork of the
>> cookie
>> specification.
>
> That's an interesting way of thinking about the issue. From my
Think of the specifications as versions of a product, e.g. a browser, where
the vendor occasionally updates older versions that does not completely
overrule newer release with a higher version number.
> perspective, it's most important to obsolete the RFCs that using
> conflicting syntax (e.g., requiring $Version=1 in the Set-Cookie
> header).
Which only 2109 does, so that is the one that should be obsoleted.
2965 do update the syntax if the Cookie header, for 2965 compliant client
when sending cookies to servers or domains that have sent 2965 style
cookies. IMO that is a conditional expansion of the syntax, and should not
be obsoleted in any way, particularly since I think we will need it if we
are to better solve the issues inherent in the Cookie Monster Bug.
> Specifications that use new HTTP headers (e.g., Set-Cookie2)
> don't seem to be in direct conflict.
Which IMO means that 2965 should be left alone during this round.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yn...@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
********************************************************************
Adam Barth
you for precisely the reasons you state below. :)
Adam