Re: [http-state] [Technical Errata Reported] RFC6265 (4044)
Barry Leiba <barryleiba@computer.org> Sun, 06 July 2014 18:37 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 D23E91A032B for <http-state@ietfa.amsl.com>; Sun, 6 Jul 2014 11:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=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 N9afSiuyg8wx for <http-state@ietfa.amsl.com>; Sun, 6 Jul 2014 11:37:09 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94511A02FA for <http-state@ietf.org>; Sun, 6 Jul 2014 11:37:08 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id el20so2236846lab.21 for <http-state@ietf.org>; Sun, 06 Jul 2014 11:37:07 -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=bb02tNMJi+MfWKSg1Sf+OukBP79mQomafZWIXdDmqm0=; b=kb69B6frwaCWi4Z5D+xSc205v24MbaM2ERr2Eh0bxZZlyqhEuygvr1iRyYa8cQqD3l WRdIpTv+M0PiZ+xIfN91OIUiFkOioa6bqo8ypeObNA65HgccLAFHtnO6xetvrGVwJZea PTT2kZqH9TGCCFtGK+kP04y6ncsDIMYnofhaVuO5TBA7o6L6GN7344W/q2fnDjrZ53nw Q7nJWy7YWac6CyeKoWvTYGWEvXuVSbQkKHamqkNr1rk9trZ9TskMoCIzacFu9fZMqvll 7wpCpZvo/el5SEyAfVQCzmysQz/6cwI0G/Y4qrg/hVWFAH7oyzOkBq33eNo711juy7uz sjjg==
MIME-Version: 1.0
X-Received: by 10.112.164.146 with SMTP id yq18mr18918663lbb.5.1404671827035; Sun, 06 Jul 2014 11:37:07 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.152.104.80 with HTTP; Sun, 6 Jul 2014 11:37:06 -0700 (PDT)
In-Reply-To: <CAL38MXLiN56r8=-KmJsUUW-OLwDM3vJ0ouvFmTLsFGJLqXM1Rw@mail.gmail.com>
References: <20140706143958.45E66180015@rfc-editor.org> <CAJE5ia8eUw-fouPHF7L1kQsZriDAGe-32fzy6aCFFaeGQDN45g@mail.gmail.com> <CAL38MXLiN56r8=-KmJsUUW-OLwDM3vJ0ouvFmTLsFGJLqXM1Rw@mail.gmail.com>
Date: Sun, 06 Jul 2014 14:37:06 -0400
X-Google-Sender-Auth: SNx_aIN3PQREhmJaSAWy77SIen8
Message-ID: <CALaySJKaJ_Q0DytCCgoZW9DwzWTSSfg=7nJLv0TvchWKvb5cDQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Pierre Lepropre <plepropre@gmail.com>
Content-Type: multipart/alternative; boundary="001a1133bd1846cc2204fd8aa5d3"
Archived-At: http://mailarchive.ietf.org/arch/msg/http-state/rKLTEJHYKacvAOx9A6U-18_RZ28
Cc: http-state <http-state@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (4044)
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 18:37:11 -0000
The point of errata, though, is to record errors in the documents... not to suggest improvements. I don't see that either of these is reporting an error. Do you? There is an issue here: we need a way to record comments and suggestions, and we don't have that. But given what errata are meant for, my inclination is to mark both of these as "rejected", much as I appreciate the value of your comments. Barry, Applications AD On Sunday, July 6, 2014, Pierre Lepropre <plepropre@gmail.com> wrote: > Hello Adam, > > As I stated in the notes, whether I got it right or wrong doesn't really > matter in my opinion. > In either case, the second action item might seem a bit surprising. > > If it is stated that way, it's probably because there is a reason behind > it. Basically, I'm just suggesting to enhance a bit the explanation behind > it. > > Regards, > > Pierre. > > > 2014-07-06 17:56 GMT+02:00 Adam Barth <ietf@adambarth.com > <javascript:_e(%7B%7D,'cvml','ietf@adambarth.com');>>: > >> I don't think we should accept this errata. This errata adds >> non-normative text that isn't strictly correct. >> >> Adam >> >> >> On Sun, Jul 6, 2014 at 7:39 AM, RFC Errata System >> <rfc-editor@rfc-editor.org >> <javascript:_e(%7B%7D,'cvml','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=4044 >> > >> > -------------------------------------- >> > Type: Technical >> > Reported by: Pierre Lepropre <plepropre@gmail.com >> <javascript:_e(%7B%7D,'cvml','plepropre@gmail.com');>> >> > >> > Section: 5.3 >> > >> > Original Text >> > ------------- >> > Otherwise: >> > >> > Set the cookie's persistent-flag to false. >> > >> > Set the cookie's expiry-time to the latest representable >> > date. >> > >> > >> > Corrected Text >> > -------------- >> > Otherwise: >> > >> > Set the cookie's persistent-flag to false. >> > >> > Set the cookie's expiry-time to the latest representable >> > date. This is a best-effort approach to ensure that the cookie >> > will effectively expire when "the current session is over" >> > (as defined by the user agent) and not anytime before. >> > >> > Notes >> > ----- >> > The second action item isn't necessarily obvious for an >> implementer/reader. If I got the intention right, then I believe it might >> improve the "user-friendly" rating of this document. Otherwise, it might >> still be beneficial to explicit a bit the reasoning behind that action. >> > >> > 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] [Technical Errata Reported] RFC6265 … RFC Errata System
- Re: [http-state] [Technical Errata Reported] RFC6… Adam Barth
- Re: [http-state] [Technical Errata Reported] RFC6… Barry Leiba
- [http-state] [Errata Rejected] RFC6265 (4044) RFC Errata System
- Re: [http-state] [Technical Errata Reported] RFC6… Pierre Lepropre