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

Pierre Lepropre <plepropre@gmail.com> Sun, 06 July 2014 18:45 UTC

Return-Path: <plepropre@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 0169E1A0A81 for <http-state@ietfa.amsl.com>; Sun, 6 Jul 2014 11:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 eMyiJpoPDBAI for <http-state@ietfa.amsl.com>; Sun, 6 Jul 2014 11:45:05 -0700 (PDT)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CD61A0326 for <http-state@ietf.org>; Sun, 6 Jul 2014 11:45:04 -0700 (PDT)
Received: by mail-ob0-f178.google.com with SMTP id wn1so3635504obc.23 for <http-state@ietf.org>; Sun, 06 Jul 2014 11:45:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G74m+tRMC7RKFdP57jVv1z7q+agxPRUkojBa5duplus=; b=czpFqjT5JU571fL3L6iR8DgrOV0C7sdB/74/jlQ+8j4Y+YUWWB68BqO9sY6bOahHR4 8/pk2g82HwlN01azgiT5Ms4QhAoRdfuXk7Boyx+OGm7Uh7et0kZ+h2EbzwHjHKwqg5sP VX1m/yfSS0TVgrD+ZCa64Jytd7n2vqkU1BsHsDp8DakBZfCA0jRUYpdD4pdCBwL/HKla FqXTy4nrJE2bVmbXvr3VakQBn9GLJ7AauvphVO9rmi5hNRUIBNQranhKVfg64Xnw2i3H lEDGLw73580AY3Pvxh9tnDf8zy6PRFLu2Gg78HcQ5OI+A6AKf9+7ilpyqEXzQb8zj9qR 3jiQ==
MIME-Version: 1.0
X-Received: by 10.60.62.148 with SMTP id y20mr3538931oer.80.1404672304226; Sun, 06 Jul 2014 11:45:04 -0700 (PDT)
Received: by 10.202.197.9 with HTTP; Sun, 6 Jul 2014 11:45:04 -0700 (PDT)
In-Reply-To: <CAJE5ia_WO06Z23Xu39C1Oj9pSTojAsSg78QzFh38d6TTxPBZbQ@mail.gmail.com>
References: <20140706143152.F350F180015@rfc-editor.org> <CAJE5ia_WO06Z23Xu39C1Oj9pSTojAsSg78QzFh38d6TTxPBZbQ@mail.gmail.com>
Date: Sun, 06 Jul 2014 20:45:04 +0200
Message-ID: <CAL38MXJ4upUz-cpCg6PRdoNQcHWWj_sh+XSLFrP7JUhTmKYKRA@mail.gmail.com>
From: Pierre Lepropre <plepropre@gmail.com>
To: Adam Barth <ietf@adambarth.com>
Content-Type: multipart/alternative; boundary="047d7b67017fb8294404fd8ac1f0"
Archived-At: http://mailarchive.ietf.org/arch/msg/http-state/aKDTk6txk0wLJiHl3vCoJuIVz0o
X-Mailman-Approved-At: Mon, 14 Jul 2014 10:52:04 -0700
Cc: http-state <http-state@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, Barry Leiba <barryleiba@computer.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (4043)
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: Sun, 06 Jul 2014 19:00:20 -0000

Hello Adam,

I agree the "default-path" is a term-of-art and yes, you are right it would
break references later in the document.
I'm sorry if my explanation wasn't accurate enough; it is not necessarily
easy to explain it in a concise matter.

Firstly, as I stated in the notes, although the construction of
"default-path" is stated right after it's written in Section 5.1.4 and that
the context might give a clue that "default-path" means "default cookie
path", "default-path" is never used again in Section 5.1.4. "uri-path",
"request-path" and "cookie-path" are the only terms being used in that
section.
Therefore, the reader might get confused as to what exactly the
"default-path" refers to whereas "default cookie-path" is a bit more
explicit; it's a specific case of the more general term "cookie-path".

Secondly, regarding the references being broken, there are only two other
references, one in Section 5.2.4 (where "default-path" and "cookie-path"
are being tied together) and one in Section 5.3. I mentioned them briefly
in the notes too.

Hope this helps,

Pierre.


2014-07-06 17:55 GMT+02:00 Adam Barth <ietf@adambarth.com>:

> I don't think we should accept this errata.  This sentence is the
> definition of default-path, which is a term-of-art within this
> document.  After the errata, this sentence is no longer defines this
> term, breaking the references later in the document.
>
> Adam
>
> On Sun, Jul 6, 2014 at 7:31 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=4043
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Pierre Lepropre <plepropre@gmail.com>
> >
> > Section: 5.1.4
> >
> > Original Text
> > -------------
> > The user agent MUST use an algorithm equivalent to the following
> > algorithm to compute the default-path of a cookie:
> >
> > Corrected Text
> > --------------
> > The user agent MUST use an algorithm equivalent to the following
> > algorithm to compute the default value for a cookie-path
> > (and thereby matching the server-side semantics as defined in 4.1.2.4):
> >
> > Notes
> > -----
> > The term "default-path" is not formally defined before and is quite
> misleading for the reader
> >   A. going through the section 5.1.4 as it's only used there once and
> not again
> >      until section 5.2.4 (once again) and 5.3 (once again).
> >   B. not being a native English speaker
> >
> > Furthermore, the true meaning of the "default-path" only appears
> sometime after at section 5.2.4 where it's finally bound altogether.
> Therefore, my personal recommendation would be to also replace the other
> occurrences of the "default-path" terms by "default cookie-path"
> >
> > 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
> >
> > _______________________________________________
> > http-state mailing list
> > http-state@ietf.org
> > https://www.ietf.org/mailman/listinfo/http-state
>