Re: WGLC: p1 MUSTs

On Tue, Apr 30, 2013 at 04:53:23PM -0600, Alex Rousskov wrote:
> 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.

OK.

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

Got it now, yes I think you're right.

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

I know I'm a bit nit-picking, but it's not exactly the same. You're saying
that it must not generate such messages, not that it should not apply the
encoding multiple times. So that does not immediately translate into "do it
only once", but could as well be "drop the message" or "don't use chunked
encoding at all". Maybe this one would be better then :

  A sender MUST NOT apply chunked encoding more than once to a message body.

> >>> 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).

I get your point, but then if it's about compliance, I suspect the issue
is that the "MUST" should not be a normative one, just a "must".

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

I agree the difference is important, and from memory, this difference
started to become clear something like 1-2 years ago. I'm sure there
are some places where it's really clear yet as the intermediary will
sometimes be considered as a sender and sometimes as a receiver, and
the forwarding role might not be present (nor relevant) everywhere.
But in general, I think that quite a good cleanup was done recently.

> > 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!).

OK, I didn't have it open in front of me to check when I replied.

> However, some requirements still need to be
> polished to use the right words. Making actors explicit helps with that.

Agreed, but you might have noticed that replacing the passive forms with
active ones tends to change large amounts of text. So the temptation is
huge sometimes not to rewrite a whole paragraph to introduce roles when
a MUST becomes a SHOULD or something like this.

Cheers,
Willy

Received on Tuesday, 30 April 2013 23:15:21 UTC