Subject: [pcp] inconsistent options in responses

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2011 17:16:14 +0200

With the new option style all options in a PCP request are copied to the
corresponding response, so some "May appear in:" are no longer consistent
so need to be upgrade:

 - 11.1 THIRD_PARTY page 51: small improvement, i.e., replace:

      May appear in: request.  May appear in response only if it
      appeared in the associated request.

  by

      May appear in: request.  MUST appear in response if it
      appeared in the associated request.

 - 11.2 PREFER_FAILURE page 53: copy THIRD_PARTY spec, i.e., replace:

      May appear in: requests

  by

      May appear in: request.  MUST appear in response if it
      appeared in the associated request.

 - 11.3 FILTER page 55: better but I suggest the same, i.e., replace:

      May appear in: requests, and MUST appear in successfully-processed
      responses

  by

      May appear in: request.  MUST appear in response if it
      appeared in the associated request.

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Oct 2011 17:20:35 -0700

The MUST is too severe, because if an option is unprocessed, the
option shouldn't be in the response.  I think this is sufficient
for THIRD_PARTY, PREFER_FAILURE, and FILTER, and I changed 
them accordingly:

            <t>May appear in: requests, and MUST appear in
            successfully-processed responses</t>

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Wednesday, October 26, 2011 8:16 AM
> To: [email-masked]
> Subject: [pcp] inconsistent options in responses
> 

>       appeared in the associated request.

The MUST is too severe, because if it was unprocessed it shouldn't
be in the response.

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2011 17:20:33 +0200

In your previous mail you wrote:

   
=> I disagree because when the word "omit" was removed in a
previous base document version I asked for a clarification
whether it was what we wanted.
I interpret the current specification as the options in the
request are unconditionally copied to the response (in fact
the whole message is copied as it). This is why we got the
maximum length issue.

Regards

PS: I am in favor of the new rule (unconditionally copy)
because it is very simple (i.e., can you find something
simpler :-).
Perhaps it should be made more explicit?