Re: WGLC: p1 MUSTs

On Apr 30, 2013, at 11:54 AM, Alex Rousskov wrote:

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

That isn't why it is being described. There are ABNF rules that define
various alternative syntax to be generated based on the role of the
sender (and, in some cases, based on the role of the recipient).
It is hard to capture in a small number of words.

>> If a received protocol element is processed, the recipient MUST be
>> able to parse any value that would match the ABNF rules
> 
> "processed" seems too broad because simply buffering a header may be
> called "processing". "Interpreted" may be better. Or did I miss the
> definition of "process" that clarifies this?

Actually, no, simply buffering a header is not called processing.
"Movement of data or material towards a known goal or end result,
by passing it through a series of stages or a sequence of actions."
However, I can rephrase it.

>> If a received protocol element is processed, the recipient MUST be
>> able to parse any value that would match the ABNF rules for that
>> protocol element, excluding only those rules not applicable to the
>> recipient's role.
> 
> The "excluding only those rules not applicable..." part seems to
> contradict the "processed" verb. Why would a recipient want to process
> something inapplicable? Perhaps this is related to the "process" versus
> "interpreted" issue mentioned above.

A client does not need to parse syntax that is only sent to servers.
An origin server does not need to parse syntax that is only sent by
a server. ...

> the recipient MUST be
>> able to parse any value that would match the ABNF rules for that
>> protocol element, excluding only those rules not applicable to the
>> recipient's role.
> 
> Please rephrase to avoid double negation in "excluding not applicable".
> For example: "the recipient MUST be able to parse any value matching the
> corresponding ABNF protocol element rules applicable to the recipient's
> role"

Okay.

One more attempt at describing the overall conformance requirements
has been committed to address this part of #484 (and related concerns).

http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2332

....Roy

Received on Wednesday, 31 July 2013 17:48:58 UTC