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

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 <https://tools.ietf.org/html/bcp9#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
<https://tools.ietf.org/html/bcp9#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.
> >
> >
> >
> >