Re: FYI: Chrome plans to ship an implementation of same-site cookies.

Let's not lawyer up on the meaning of the phrase "intended status" -- it's completely advisory and up to the draft submitters. If we actually adopt a document, that's when we need to be concerned about this.

Cheers,



> On 26 Mar 2016, at 5:04 AM, Phil Lello <phil@dunlop-lello.uk> wrote:
> 
> I'm clearly not disputing the point of a standard or objecting to the work, however the status exists for a reason.
> 
> BCP9 describes Informational as:
>    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
>    designation is intended to provide for the timely publication of a
>    very broad range of responsible informational documents from many
>    sources, subject only to editorial considerations and to verification
>    that there has been adequate coordination with the standards process
>    (see 
> section 4.2.3
> ).
> 
>    Specifications that have been prepared outside of the Internet
>    community and are not incorporated into the Internet Standards
>    Process by any of the provisions of 
> section 10
>  may be published as
>    Informational RFCs, with the permission of the owner and the
>    concurrence of the RFC Editor.
> 
> BCP9 describes Proposed Standard as:
>    The entry-level maturity for the standards track is "Proposed
>    Standard".  A specific action by the IESG is required to move a
>    specification onto the standards track at the "Proposed Standard"
>    level.
> 
>    A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be well-understood, has received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable.  However, further experience
>    might result in a change or even retraction of the specification
>    before it advances.
> 
>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed Standard
>    designation.
> 
>    The IESG may require implementation and/or operational experience
>    prior to granting Proposed Standard status to a specification that
>    materially affects the core Internet protocols or that specifies
>    behavior that may have significant operational impact on the
>    Internet.
> 
>    A Proposed Standard should have no known technical omissions with
>    respect to the requirements placed upon it.  However, the IESG may
>    waive this requirement in order to allow a specification to advance
>    to the Proposed Standard state when it is considered to be useful and
>    necessary (and timely) even with known technical omissions.
> 
>    Implementors should treat Proposed Standards as immature
>    specifications.  It is desirable to implement them in order to gain
>    experience and to validate, test, and clarify the specification.
>    However, since the content of Proposed Standards may be changed if
>    problems are found or better solutions are identified, deploying
>    implementations of such standards into a disruption-sensitive
>    environment is not recommended.
> 
> 
> IMHO announcing the release into the wild while saying "I think they're solidly enough defined to ship and let folks begin experimenting with. We plan on pushing them out the door in Chrome ~51" implies Informational Status, since it 'does not represent an Internet community consensus or recommendation' and does not meet the Proposed Standard requirement of 'generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review' if it's released for experimentation - once it's shipped, it's a de facto standard.
> 
> Proposed Standard also states 'However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended.'
> Best wishes,
> Phil Lello
> 
> 
> On Fri, Mar 25, 2016 at 4:40 PM, David Morris <dwm@xpasc.com> wrote:
> 
> What working code is called isn't really relavent in terms of RFC status.
> The point of a standard is to get all implementors to do it an
> interoperable fashion. Standards can originate outside of a WG. And as far
> as I can recall, this WG hasn't rejected this work.
> 
> On Fri, 25 Mar 2016, Phil Lello wrote:
> 
> > Can I ask that the draft change the "Intended Status" to "Informational" -
> > it seems to me that by being shipped in a full release rather than a beta,
> > it reflects a standard defined outside the IETF processes.
> >
> > Best wishes,
> >
> > Phil Lello
> >
> > On Fri, Mar 25, 2016 at 9:35 AM, Mike West <mkwst@google.com> wrote:
> >       Hello, HTTP WG folks who are interested in cookies. :)
> > We've talked on and off about same-site cookies as a defense in depth
> > against CSRF and related attacks; I think they're solidly enough
> > defined to ship and let folks begin experimenting with. We plan on
> > pushing them out the door in Chrome ~51, and I hear that folks at
> > Mozilla are planning on beginning an implementation in Q2:
> >
> > Spec: https://tools.ietf.org/html/draft-west-first-party-cookies
> > Intent toShip: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/csCt
> > W3M3-wg
> >
> > There's a very slightly updated -07 that I'll upload once things open
> > up again, but it doesn't contain any normative changes. Feedback on
> > the existing text (or Chrome's implementation) would be much
> > appreciated.
> >
> > -mike
> >
> >
> >
> >
> >
> > ____________________________________________________________________________
> >
> > This email has been scanned for spam and viruses by Proofpoint Essentials
> > cloud email security - click here to report this email as spam.
> >
> >
> >
> >
> 

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

Received on Saturday, 26 March 2016 01:15:29 UTC