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

Julian Reschke <julian.reschke@gmx.de> Tue, 08 January 2013 02:19 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A7A21F8727 for <http-state@ietfa.amsl.com>; Mon, 7 Jan 2013 18:19:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1-chL6z+JFE for <http-state@ietfa.amsl.com>; Mon, 7 Jan 2013 18:19:29 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id DEDEF21F871D for <http-state@ietf.org>; Mon, 7 Jan 2013 18:19:28 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LdKAB-1TA1bq47qD-00iPTC for <http-state@ietf.org>; Tue, 08 Jan 2013 03:19:27 +0100
Received: (qmail invoked by alias); 08 Jan 2013 02:19:27 -0000
Received: from p54BB30A6.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.48.166] by mail.gmx.net (mp031) with SMTP; 08 Jan 2013 03:19:27 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18UCqJUGrcU4o1+nLydZnXkimq9IP2VZZY0LKle7v VCVL16NaEEjj/d
Message-ID: <50EB8226.3090303@gmx.de>
Date: Tue, 08 Jan 2013 03:19:18 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <50EB00C6.6050301@KingsMountain.com> <CAJE5ia8LPNEsPNh3z=b0CYg8wKQfArWoQJYzd=ChugLxjxYYZw@mail.gmail.com> <50EB2D8D.1050102@qti.qualcomm.com> <CALaySJKcDZVOtAYySNUKXrpmx+ymBZ+EVnEKafWpVCQyFcd9Ow@mail.gmail.com> <CAJE5ia_G_FVcKJBkw9C2_TPHxQfMen9i9DyAy24yOs_Qa8vscQ@mail.gmail.com>
In-Reply-To: <CAJE5ia_G_FVcKJBkw9C2_TPHxQfMen9i9DyAy24yOs_Qa8vscQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Pete Resnick <presnick@qti.qualcomm.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, Eran Hammer <eran@hueniverse.com>, http-state <http-state@ietf.org>, Barry Leiba <barryleiba@computer.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3444)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 08 Jan 2013 02:19:29 -0000

On 2013-01-07 21:48, Adam Barth wrote:
> On Mon, Jan 7, 2013 at 12:28 PM, Barry Leiba <barryleiba@computer.org> wrote:
>>>>>> Happy to go that route.  So how about this correction?:
>>>>>>
>>>>>>      path-value        = *av-octet
>>>>>>      extension-av      = *av-octet
>>>>>>      av-octet          = %x20-3A / %x3C-7E
>>>>>>                        ; any CHAR except CTLs or ";"
>>>
>>> So you want to allow space but not tab, right?
>>
>> Well, that's what the current text ("any CHAR except CTLs") says.  If
>> we want to "fix" that, then now's the time, while we're
>> precisificatifying the ABNF.
>>
>> So, which should it be?:
>>
>> 1:  av-octet = %x20-3A / %x3C-7E    (allows space, but not tab)
>>
>> 2:  av-octet = %x21-3A / %x3C-7E    (allows neither space nor tab)
>>
>> 3:  av-octet = %x09 / %x20-3A / %x3C-7E    (allows both space and tab)
>
> This grammar is intentionally "loose" because there is such a wide
> variety of crazy Set-Cookie headers in the world.  Allowing tab
> doesn't seem harmful, so I'd recommend (3).

Big -1.

We're now changing the spec instead of fixing an editorial bug.

If we *really* want a change, this needs way more IETF review than an 
Erratum gets.

Best regards, Julian