Re: WGLC: p1 MUSTs

Alex Rousskov <> Tue, 30 April 2013 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2CFF21F8521 for <>; Tue, 30 Apr 2013 15:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aDJawFcB-fJ2 for <>; Tue, 30 Apr 2013 15:55:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A2BAE21F8523 for <>; Tue, 30 Apr 2013 15:55:33 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UXJR3-0004sw-7j for; Tue, 30 Apr 2013 22:54:09 +0000
Resent-Date: Tue, 30 Apr 2013 22:54:09 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UXJQp-0004rP-D2 for; Tue, 30 Apr 2013 22:53:55 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1UXJQo-0006AE-FF for; Tue, 30 Apr 2013 22:53:55 +0000
Received: from [] (localhost []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id r3UMrVZL042410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Tue, 30 Apr 2013 16:53:32 -0600 (MDT) (envelope-from
Message-ID: <>
Date: Tue, 30 Apr 2013 16:53:23 -0600
From: Alex Rousskov <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Hub-Spam-Report: RP_MATCHES_RCVD=-2.509, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UXJQo-0006AE-FF 3d5fd8c5187b0ed1488a2d1060d31da6
Subject: Re: WGLC: p1 MUSTs
Archived-At: <>
X-Mailing-List: <> archive/latest/17735
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 04/30/2013 01:40 PM, Willy Tarreau wrote:

> That was quite a long mail, I think it's more efficient next time to split
> this into multiple parts to help people respond to some parts only. I've
> read it all, and for a few of them I had no opinion but I gave mine when
> possible.

I struggled with the format. The Last Call instructions say "Issues that
you believe to be editorial in nature (e.g., typos, suggested
re-phrasing) can be grouped together in a single e-mail" and that is
what I did because I believe these problems are editorial in nature.

>>> A sender MUST NOT generate protocol elements that do not match the
>>> grammar defined by the ABNF rules for those protocol elements that
>>> are applicable to the sender's role.

>> The "for those protocol elements..." part should be dropped IMO. A
>> sender MUST NOT generate invalid protocol elements even if they are not
>> applicable to the sender's role. Note that we are talking about
>> _generation_ and not forwarding here.

> The fact that you're specifically talking about
> forwarding here means that the text is clear on the subject, so probably
> we should leave it in order to avoid confusion.

Both the requirement text and I are talking specifically about
generation (MUST NOT _generate_), not forwarding. The text is clear with
regard to generation, but contains an "[applicable] elements" scope
restriction that should be dropped IMO.

>>> If chunked is applied to a payload body, the sender MUST NOT apply
>>> chunked more than once

>> The precondition is bogus: If chunked is NOT [yet?] applied to a payload
>> body, the sender still MUST NOT apply chunked more than once!

> No I think it's the wording which is wrong. The intent was to ensure that
> we never chunk more than once. It's as always the passive form which causes
> trouble because you never know if it applies to what you see or what you do.
> I'd suggest something like this :
>   If sender applies chunked encoding to a payload body, it MUST NOT apply
>   it more than once.

Yes, and you can remove the precondition from your wording as well, to
simplify: A sender MUST NOT generate messages with multiple chunked
encodings. Again, the precondition (i.e., the "if" part) does not help here.

>>> A client that pipelines requests MUST be prepared to retry those requests

>> MUST be prepared to retry but does not have to retry? Or MUST retry?

> Same as above, "must be prepared" here means that it must make valid
> choices even before facing the failure (eg: not send non-idempotent
> requests).

My point was not about valid choices before facing the failure (I think
those choices are covered by different rules) but about required actions
after the failure (i.e., retry):

- Your proxy is not compliant because it does not retry failed pipelined

- No, my proxy is compliant: You see, it was prepared to retry those
GETs as required. Trust me, it was! I checked the logs, and they say
"prepared to retry using connection X". Unfortunately, it did not retry
them when they actually failed (that backup connection X got closed
while they were being sent), but there is no requirement to retry, right?

- You are right. Time to file errata...

The "be prepared" part might be useful in an informal explanation but it
is invalidating the intended formal requirement here (to retry).

>> Please be careful with "send" and "generate" when fixing the above
>> actorless rules so that the proxies do not accidentally become
>> responsible for policing traffic where unnecessary.

> In my opinion, "send" includes "forward" and "generate", 

Yes. That is one of the reasons why I am asking to rephrase these rules
even if the right actor can sometimes be guessed. Some of the polished
rules will use "send", but some may end up using "generate" when
polished. The difference is important.

> Maybe some additional definitions are needed at the beginning to clarify
> this?

Somebody already added those definitions and adjusted many rules to use
them (thank you, somebody!). However, some requirements still need to be
polished to use the right words. Making actors explicit helps with that.

Thank you,