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 >
- [http-state] [Technical Errata Reported] RFC6265 … RFC Errata System
- Re: [http-state] [Technical Errata Reported] RFC6… Adam Barth
- [http-state] [Errata Rejected] RFC6265 (4043) RFC Errata System
- Re: [http-state] [Technical Errata Reported] RFC6… Pierre Lepropre