Re: #481, was: WGLC: p7 MUSTs

Alex Rousskov <rousskov@measurement-factory.com> Sun, 30 June 2013 19:47 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 6127A21F9C0E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 30 Jun 2013 12:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 ha+-D4HdXVRa for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 30 Jun 2013 12:47:46 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1860E21F9C10 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 30 Jun 2013 12:47:45 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UtNaX-0005gY-P3 for ietf-http-wg-dist@listhub.w3.org; Sun, 30 Jun 2013 19:47:09 +0000
Resent-Date: Sun, 30 Jun 2013 19:47:09 +0000
Resent-Message-Id: <E1UtNaX-0005gY-P3@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <rousskov@measurement-factory.com>) id 1UtNaI-0005fK-QU for ietf-http-wg@listhub.w3.org; Sun, 30 Jun 2013 19:46:54 +0000
Received: from measurement-factory.com ([209.169.10.130]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <rousskov@measurement-factory.com>) id 1UtNaH-0003Q0-O4 for ietf-http-wg@w3.org; Sun, 30 Jun 2013 19:46:54 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) (authenticated bits=0) by measurement-factory.com (8.14.3/8.14.3) with ESMTP id r5UJkQDf062083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Jun 2013 13:46:28 -0600 (MDT) (envelope-from rousskov@measurement-factory.com)
Message-ID: <51D08B07.5020801@measurement-factory.com>
Date: Sun, 30 Jun 2013 13:46:15 -0600
From: Alex Rousskov <rousskov@measurement-factory.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
CC: IETF HTTP WG <ietf-http-wg@w3.org>
References: <D69329FD-7456-46C5-BE24-6E7EE7E48C39@mnot.net> <5180A37D.6050003@measurement-factory.com> <51B4B40B.1080800@gmx.de> <51B4CE53.5010204@measurement-factory.com> <51D06141.9090606@gmx.de>
In-Reply-To: <51D06141.9090606@gmx.de>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=209.169.10.130; envelope-from=rousskov@measurement-factory.com; helo=measurement-factory.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.495, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.008, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UtNaH-0003Q0-O4 fbd568aecea09810de744c9b15cfe4c1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #481, was: WGLC: p7 MUSTs
Archived-At: <http://www.w3.org/mid/51D08B07.5020801@measurement-factory.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18434
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 06/30/2013 10:48 AM, Julian Reschke wrote:
> On 2013-06-09 20:49, Alex Rousskov wrote:
>> If you say "server MUST NOT send X", the proxy becomes responsible for
>> not forwarding X. If you say "server MUST NOT generate X", the proxy
>> forwarding behavior is not restricted by that specific requirement. When
>> you say "request MUST NOT have X", the specs become ambiguous: some will
>> claim that a proxy forwarding X is in violation and some will claim that
>> the requirement is not applicable to proxies.

> The trouble is that what you're asking for a change in requirements, and
> that most definitively is *not* an editorial change. 

Whether polishing how these ambiguous requirements are worded actually
changes those requirements depends on whether the reader believes that
the proxy must police the given aspect of the message. Some readers may
indeed decide that your polishing is not editorial in nature, depending
on how you change the specs. The very fact that you suspect there will
be protocol changes essentially implies that the current requirements
are ambiguous and ought to be fixed.


> As such, I'm not
> too enthusiastic to make these kind of changes without feedback from the
> working group.

On the other hand, it is difficult to provide feedback without seeing
the changes.


> Do people agree that these requirements need to be rephrased? Do we have
> concrete proposals about *how* to change them?

FWIW, I do: Reword them to name the actor (client or server, usually
obvious) and use "generate" instead of "send". When that default does
not seem appropriate to you or others, let's discuss!


Thank you,

Alex.