Re: #481, was: WGLC: p7 MUSTs

Alex Rousskov <> Sun, 30 June 2013 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6127A21F9C0E for <>; Sun, 30 Jun 2013 12:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ha+-D4HdXVRa for <>; Sun, 30 Jun 2013 12:47:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1860E21F9C10 for <>; Sun, 30 Jun 2013 12:47:45 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UtNaX-0005gY-P3 for; Sun, 30 Jun 2013 19:47:09 +0000
Resent-Date: Sun, 30 Jun 2013 19:47:09 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UtNaI-0005fK-QU for; Sun, 30 Jun 2013 19:46:54 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1UtNaH-0003Q0-O4 for; Sun, 30 Jun 2013 19:46:54 +0000
Received: from [] (localhost []) (authenticated bits=0) by (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
Message-ID: <>
Date: Sun, 30 Jun 2013 13:46:15 -0600
From: Alex Rousskov <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Julian Reschke <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
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: 1UtNaH-0003Q0-O4 fbd568aecea09810de744c9b15cfe4c1
Subject: Re: #481, was: WGLC: p7 MUSTs
Archived-At: <>
X-Mailing-List: <> archive/latest/18434
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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,