Re: p1: BWS

Julian Reschke <julian.reschke@gmx.de> Fri, 19 April 2013 11:48 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF9821F95A0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Apr 2013 04:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.524
X-Spam-Level:
X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH4tNZ7pBdZy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Apr 2013 04:48:35 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2921F9593 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 19 Apr 2013 04:48:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UT9nm-00018X-45 for ietf-http-wg-dist@listhub.w3.org; Fri, 19 Apr 2013 11:48:26 +0000
Resent-Date: Fri, 19 Apr 2013 11:48:26 +0000
Resent-Message-Id: <E1UT9nm-00018X-45@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1UT9ni-00017K-KW for ietf-http-wg@listhub.w3.org; Fri, 19 Apr 2013 11:48:22 +0000
Received: from mout.gmx.net ([212.227.15.19]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1UT9nh-0002xs-OI for ietf-http-wg@w3.org; Fri, 19 Apr 2013 11:48:22 +0000
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M3gWF-1Ukgg61pKb-00rFYS for <ietf-http-wg@w3.org>; Fri, 19 Apr 2013 13:47:55 +0200
Received: (qmail invoked by alias); 19 Apr 2013 11:47:54 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp024) with SMTP; 19 Apr 2013 13:47:54 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/AVoZHUSvAQqf/TGm8bYibCtUBpqKqv7jiDGJn4b KFT9MKx49Ubvgw
Message-ID: <51712EE4.7000408@gmx.de>
Date: Fri, 19 Apr 2013 13:47:48 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Roberto Peon <grmocg@gmail.com>, Willy Tarreau <w@1wt.eu>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
References: <DB8598D0-7AD8-4A90-806B-E4C7B65118D7@mnot.net> <516F76CB.20406@treenet.co.nz> <20130418060211.GC13063@1wt.eu> <468FAE72-012D-43EB-A5A7-EAA137687F87@mnot.net> <CAP+FsNdrf-7h=8+68AirD8jJRvhBXf-1uxmXc_3R80418yW2uA@mail.gmail.com> <D258E088-782D-4E16-976C-235F94520964@mnot.net> <51710FC3.9060200@gmx.de> <B55F7972-91BF-456F-B4E1-070685394B44@mnot.net>
In-Reply-To: <B55F7972-91BF-456F-B4E1-070685394B44@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=212.227.15.19; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.359, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UT9nh-0002xs-OI aca0b1716eb8900da2aadf6a51ecdeb9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: BWS
Archived-At: <http://www.w3.org/mid/51712EE4.7000408@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17362
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 2013-04-19 13:39, Mark Nottingham wrote:
>
> On 19/04/2013, at 7:34 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>
>> On 2013-04-19 00:27, Mark Nottingham wrote:
>>> We can either:
>>>
>>> - make it a MUST
>>> - document what the exceptional circumstances are that cause the SHOULD (but I don't think it's that kind of SHOULD)
>>> - downgrade it to an "ought to"
>>>
>>> I do note that we say "generate" there (which I missed before, sorry); in our terminology, that means you DON'T need to fix it up when forwarding it; it's only when you're actually creating the element that this applies.
>>>
>>> So, I'd suggest we make it a MUST, and change the language slightly to clarify:
>>>
>>> "...but it MUST NOT be generated in messages..."
>>
>> I have no problem with *that* change.
>>
>> What concerns we much more is the "MUST accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream" -- that part is fine for parsing the message itself (everybody needs to be able to do that), but *not* ok for individual field values. We need a distinction here.
>
> Ah, yes, that was the part that sparked my original concern.
>
> The text in the latest draft is:
>
> """
> BWS is used where the grammar allows optional whitespace, for historical reasons, but senders SHOULD NOT generate it in messages; recipients MUST accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.
> """
>
> I'd suggest:
>
> """
> BWS is used where the grammar allows optional whitespace, for historical reasons, but it MUST NOT be generated in messages; recipients MUST accept such bad optional whitespace and remove it before interpreting the field value.
> """
>
>
>>> Also, in p2, I'd note that we do NOT allow BWS inside of media type parameters:
>>>    https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#media.type
>>>
>>> AIUI (thanks, Julian), this is because many implementations don't accept whitespace there at all. It might be worth noting in the text that this parameter construct is different in that aspect.
>>
>> I don't know whether it's because of implementations following the spec, or the spec following implementations.
>>
>> Somewhat outdated tests are over here: <http://greenbytes.de/tech/tc/httpcontenttype/>
>>
>> I'm more than happy to require recipients to handle BWS here for consistency with other header fields, as long as we tell generators to never ever use it.
>
> That would make current implementations non-conformant, where we already have interop. While consistency is good, that may be going too far for it.
>
> I was thinking of something along the lines of
>
> """
> Note that unlike some similar constructs in other headers, media type parameters do not allow whitespace (even "bad" whitespace) around the "=" character.
> """
>
> Would that work for you?
> ...


+1 on both.

Best regards, Julian