Re: [http-state] [Technical Errata Reported] RFC6265 (3931)

Barry Leiba <barryleiba@computer.org> Mon, 24 March 2014 14:39 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C41A1A01FE for <http-state@ietfa.amsl.com>; Mon, 24 Mar 2014 07:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgE7M1MH1u6M for <http-state@ietfa.amsl.com>; Mon, 24 Mar 2014 07:39:48 -0700 (PDT)
Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7271A01D5 for <http-state@ietf.org>; Mon, 24 Mar 2014 07:39:48 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id o15so5379638qap.37 for <http-state@ietf.org>; Mon, 24 Mar 2014 07:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BjqpSEXeUfXo8VjHwxx6Z09L63BN6RvFLGwGyjxByXI=; b=hfEDhqoNJJMKX99RkLCUrMhX0iYK9cIsi5N1cZXUL1/2rLWg/qewXq8ZpQ/+7dA6qD 7qfP0Jj0aRKWK+PjRngOEjo3VhlVMkgT0JzbX7nyA/FsHCuwFHaojQH5l5BLse38YUjo cl3d7VJ0ZvvIHzmQP8yL347oTLQ8uhfHLnhuNn8icN2nzXtXzknahf8CBy3swSx3iDOo xYuv5Bk4R1ZDd6HPmwycW6bt+i8Be2OWRUGMbjmOybc2A2uGN9j2/qj7DikdEVP0z0+L /Zyn65TT9QuDmd3TSAm533UilhMBiy4Itawqt2ZTlE2E6C/KZOHPTuaFLBeEhT41CyJC JHdw==
MIME-Version: 1.0
X-Received: by 10.140.23.52 with SMTP id 49mr71922001qgo.17.1395671987515; Mon, 24 Mar 2014 07:39:47 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.42.136 with HTTP; Mon, 24 Mar 2014 07:39:47 -0700 (PDT)
In-Reply-To: <20140324072303.ECB2E7FC393@rfc-editor.org>
References: <20140324072303.ECB2E7FC393@rfc-editor.org>
Date: Mon, 24 Mar 2014 10:39:47 -0400
X-Google-Sender-Auth: pYXTpCtDIzNPbymtOrCecS7O3_c
Message-ID: <CALaySJJc03Z=FT0QnnAaPra7R6zLmPk0VqFxjo+utHJ_AtFrOA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/http-state/gZSXx5NU1DvrEtfXAtF-VBRHRJ0
Cc: Pete Resnick <presnick@qti.qualcomm.com>, http-state <http-state@ietf.org>, joker.vd@gmail.com, "abarth@eecs.berkeley.edu" <abarth@eecs.berkeley.edu>
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3931)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state/>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Mar 2014 14:39:50 -0000

Semyon, you appear to be adding a requirement that parsers pay
attention to the weekday token, where the documented algorithm
specifically ignores it.  And, yet, at the same time you say in your
note that it's insignificant and can be ignored -- which is exactly
what the documented algorithm does.  Further, all your change does is
require the parser to recognize that it found a weekday and set a flag
that's never used.

I don't understand why you think this was an error.  Can you explain that?

Barry

On Mon, Mar 24, 2014 at 3:23 AM, RFC Errata System
<rfc-editor@rfc-editor.org> wrote:
> The following errata report has been submitted for RFC6265,
> "HTTP State Management Mechanism".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6265&eid=3931
>
> --------------------------------------
> Type: Technical
> Reported by: Semyon Kholodnov <joker.vd@gmail.com>
>
> Section: 5.1.1
>
> Original Text
> -------------
>    The user agent MUST use an algorithm equivalent to the following
>    algorithm to parse a cookie-date.  Note that the various boolean
>    flags defined as a part of the algorithm (i.e., found-time, found-
>    day-of-month, found-month, found-year) are initially "not set".
>
>    1.  Using the grammar below, divide the cookie-date into date-tokens.
>
>    cookie-date     = *delimiter date-token-list *delimiter
>    date-token-list = date-token *( 1*delimiter date-token )
>    date-token      = 1*non-delimiter
>
>    delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
>    non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
>    non-digit       = %x00-2F / %x3A-FF
>
>    day-of-month    = 1*2DIGIT ( non-digit *OCTET )
>    month           = ( "jan" / "feb" / "mar" / "apr" /
>                        "may" / "jun" / "jul" / "aug" /
>                        "sep" / "oct" / "nov" / "dec" ) *OCTET
>    year            = 2*4DIGIT ( non-digit *OCTET )
>    time            = hms-time ( non-digit *OCTET )
>    hms-time        = time-field ":" time-field ":" time-field
>    time-field      = 1*2DIGIT
>
>    2.  Process each date-token sequentially in the order the date-tokens
>        appear in the cookie-date:
>
>        1.  If the found-time flag is not set and the token matches the
>            time production, set the found-time flag and set the hour-
>            value, minute-value, and second-value to the numbers denoted
>            by the digits in the date-token, respectively.  Skip the
>            remaining sub-steps and continue to the next date-token.
>
>        2.  If the found-day-of-month flag is not set and the date-token
>            matches the day-of-month production, set the found-day-of-
>            month flag and set the day-of-month-value to the number
>            denoted by the date-token.  Skip the remaining sub-steps and
>            continue to the next date-token.
>
>        3.  If the found-month flag is not set and the date-token matches
>            the month production, set the found-month flag and set the
>            month-value to the month denoted by the date-token.  Skip the
>            remaining sub-steps and continue to the next date-token.
>
>        4.  If the found-year flag is not set and the date-token matches
>            the year production, set the found-year flag and set the
>            year-value to the number denoted by the date-token.  Skip the
>            remaining sub-steps and continue to the next date-token.
>
> Corrected Text
> --------------
>    The user agent MUST use an algorithm equivalent to the following
>    algorithm to parse a cookie-date.  Note that the various boolean
>    flags defined as a part of the algorithm (i.e., found-day-of-week,
>    found-time, found-day-of-month, found-month, found-year) are
>    initially "not set".
>
>    1.  Using the grammar below, divide the cookie-date into date-tokens.
>
>    cookie-date     = *delimiter date-token-list *delimiter
>    date-token-list = date-token *( 1*delimiter date-token )
>    date-token      = 1*non-delimiter
>
>    delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
>    non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
>    non-digit       = %x00-2F / %x3A-FF
>
>    day-of-week     = weekday / wkday
>    wkday           = "mon" / "tue" / "wed" / "thu" / "fri" / "sat" /
>                      "sun"
>    weekday         = "monday" / "tuesday" / "wednesday" / "thursday" /
>                      "friday" / "saturday" / "sunday"
>    day-of-month    = 1*2DIGIT ( non-digit *OCTET )
>    month           = ( "jan" / "feb" / "mar" / "apr" /
>                        "may" / "jun" / "jul" / "aug" /
>                        "sep" / "oct" / "nov" / "dec" ) *OCTET
>    year            = 2*4DIGIT ( non-digit *OCTET )
>    time            = hms-time ( non-digit *OCTET )
>    hms-time        = time-field ":" time-field ":" time-field
>    time-field      = 1*2DIGIT
>
>    2.  Process each date-token sequentially in the order the date-tokens
>        appear in the cookie-date:
>
>        1.  If the found-day-of-week flag is not set and the token
>            matches the day-of-week production, set found-day-of-week
>            flag. Skip the remaining steps and continue to the next
>            date-token.
>
>        2.  If the found-time flag is not set and the token matches the
>            time production, set the found-time flag and set the hour-
>            value, minute-value, and second-value to the numbers denoted
>            by the digits in the date-token, respectively.  Skip the
>            remaining sub-steps and continue to the next date-token.
>
>        3.  If the found-day-of-month flag is not set and the date-token
>            matches the day-of-month production, set the found-day-of-
>            month flag and set the day-of-month-value to the number
>            denoted by the date-token.  Skip the remaining sub-steps and
>            continue to the next date-token.
>
>        4.  If the found-month flag is not set and the date-token matches
>            the month production, set the found-month flag and set the
>            month-value to the month denoted by the date-token.  Skip the
>            remaining sub-steps and continue to the next date-token.
>
>        5.  If the found-year flag is not set and the date-token matches
>            the year production, set the found-year flag and set the
>            year-value to the number denoted by the date-token.  Skip the
>            remaining sub-steps and continue to the next date-token.
>
> Notes
> -----
> 4.1.1 defines "sane-cookie-date" as "rfc1123-date, defined in [RFC2616], Section 3.3.1". However, both RFC1123 and RFC2616 mandate that date starts with day of the week, and indeed, most servers send cookies where Expires starts with day of the week.
>
> In this particular case (Expire field) the day-of-week part of the date is insignificant, and client MAY ignore it.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6265 (draft-ietf-httpstate-cookie-23)
> --------------------------------------
> Title               : HTTP State Management Mechanism
> Publication Date    : April 2011
> Author(s)           : A. Barth
> Category            : PROPOSED STANDARD
> Source              : HTTP State Management Mechanism
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG