Re: #481, was: WGLC: p7 MUSTs

Julian Reschke <> Sun, 30 June 2013 16:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F19A421F9B6A for <>; Sun, 30 Jun 2013 09:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id diS2jcAuQbqo for <>; Sun, 30 Jun 2013 09:49:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 46BA421F9A06 for <>; Sun, 30 Jun 2013 09:49:41 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UtKo1-0001Ai-Ca for; Sun, 30 Jun 2013 16:48:53 +0000
Resent-Date: Sun, 30 Jun 2013 16:48:53 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UtKnl-000195-2y for; Sun, 30 Jun 2013 16:48:37 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UtKnj-0005o6-CW for; Sun, 30 Jun 2013 16:48:35 +0000
Received: from ([]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MFfRr-1Uz5y81zPx-00EgI3 for <>; Sun, 30 Jun 2013 18:48:09 +0200
Received: (qmail invoked by alias); 30 Jun 2013 16:48:09 -0000
Received: from (EHLO []) [] by (mp001) with SMTP; 30 Jun 2013 18:48:09 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19vLzwtfIxvh0AAZO2l0GQU2SaQ7Vh19a4Saldum5 l563n4DPqF3feX
Message-ID: <>
Date: Sun, 30 Jun 2013 18:48:01 +0200
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Alex Rousskov <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-3.275, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UtKnj-0005o6-CW 5015b1b56de8defadd79a21110b6de57
Subject: Re: #481, was: WGLC: p7 MUSTs
Archived-At: <>
X-Mailing-List: <> archive/latest/18431
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2013-06-09 20:49, Alex Rousskov wrote:
> On 06/09/2013 10:57 AM, Julian Reschke wrote:
>> On 2013-05-01 07:09, Alex Rousskov wrote:
>>> And here is a list of requirements that are missing an explicit actor on
>>> which the requirement is placed. Even though it is often possible to
>>> guess the actor, most of these should be easy to rephrase to place the
>>> requirement on the intended actor explicitly (e.g., "A proxy MUST"
>>> instead of "a header field MUST":
>>>> each parameter name MUST only occur once per challenge
>> That's a requirement on the validity of a challenge.
> Yes. We need to make clear which actors that requirement applies to.
>> As such it does not depend on the actor.
> It does. When I originally complained that lots of RFC 2616 MUSTs may be
> interpreted as if they apply to proxies when they should not and
> suggested a general rule to excuse proxies from policing traffic, I was
> told that a better approach is to check each and every MUST to make sure
> it is clear whether it applies to blind forwarding situations or not.
> The current HTTPbis specs use that overall approach via the introduction
> of "sends" vs "generates" difference (thank you!).
> However, to enable such checks, each MUST has to have an actor with
> "sends", "generates", or another appropriate keyword. Otherwise, it is
> not clear whether the proxy is responsible for policing things like
> challenges with duplicate parameter names. The overhead of checking and
> adjusting each requirement comes with the approach. You cannot have it
> both ways.
>>>> This response MUST include a WWW-Authenticate header
>>>> The 407 (Proxy Authentication Required) response message [...] MUST
>>>> include a Proxy-Authenticate header field
>>>> information necessary to authenticate a request MUST be provided in
>>>> the request
>>>> It MUST be included as part of a 407 (Proxy Authentication Required)
>>>> response.
>>>> It MUST be included in 401 (Unauthorized) response messages
>> Similar things can be said about these.
> Yes, the flaw is similar.
>> What you seem to ask for is information about what a proxy should do
>> when it receives a message that already violates a MUST level
>> requirement.
> No, I am not asking for that. I am asking to make it possible to
> determine whether a proxy forwarding a malformed message is in violation
> of the specs. As discussed above, each requirement has to be clear on
> that by using appropriate actors and verbs.
> 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.
> Hope this clarifies,
> Alex.

Yes, sort of.

The trouble is that what you're asking for a change in requirements, and 
that most definitively is *not* an editorial change. As such, I'm not 
too enthusiastic to make these kind of changes without feedback from the 
working group.

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

Best regards, Julian