Re: WGLC: p1 MUSTs

[Alex Rousskov <[e-mail]>]

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
GETs!

- 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,

Alex.