Subject: Re: #481, was: WGLC: p7 MUSTs

From: Julian Reschke <[email-masked]>
Date: Wed, 10 Jul 2013 13:40:38 +0200

On 2013-06-30 22:08, Julian Reschke wrote:
> ...
>> FWIW, I do: Reword them to name the actor (client or server, usually
>> obvious) and use "generate" instead of "send". When that default does
>> not seem appropriate to you or others, let's discuss!
>
> I don't think that it's sufficient to do that. What you propose is to
> erase the current language that defines validity of the message format
> and replace it by something else. I don't think we should do that. We
> *can* discuss clarifying what that means for the various actors, though.
>
> Best regards, Julian
> ...

I haven't seen a concrete change proposal yet. Note that we *will* 
submit a new draft by next Monday.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Jul 2013 12:48:36 +0200

On 2013-05-07 06:47, Mark Nottingham wrote:
> Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/483>.

Fixed in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2319>.

---

From: Roy T. Fielding <[email-masked]>
Date: Wed, 31 Jul 2013 10:48:33 -0700

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

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 31 Jul 2013 15:07:06 -0600

> It is hard to capture in a small number of words.

Understood. The new wording you linked to below reflects the above
intent better IMO.

> However, I can rephrase it.

Well, "buffering and printing to the debugging log" if you insist on a
sequence of different actions :-).

> An origin server does not need to parse syntax that is only sent by

Sure, but the "a received protocol element is processed" precondition
already excludes those cases. Your focus here was different, and I think
the new wording is better in this aspect as well.

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

I think that change addresses the above issues.

Thank you,

Alex.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 31 Jul 2013 21:45:57 -0700

On Apr 30, 2013, at 2:10 PM, Benjamin Carlyle wrote:
> In the vein of clarifying what is meant by "process" I would also suggest dropping the "be able to" wording wherever it appears in MUST statements. Compliance can tested for what a particular actor does or does not do. It can't be tested for what the actor is capable of doing.
> 
I looked and found that "be able to" is the correct wording.  It is
possible to test for capabilities -- it is just harder to know
whether the failure is due to a lack of capability or an explicit
decision not to.  In these cases, we want to allow the implementation
to decide not to parse at all.

....Roy