Subject: [pcp] a question about the UNPROCESSED option

From: Francis Dupont <[email-masked]>
Date: Sun, 04 Sep 2011 17:14:16 +0200

Still about conformance testing, I have no good idea about what to do
with an UNPROCESSED option included in a PCP request:
 - the only clear thing is this MUST raise an error
 - there are 3 candidates:
  * UNSUPP_OPTION but according to my previous message the next one
   is better
  * MALFORMED_OPTION seems to be the best candidate but perhaps the
   next one is even better
  * MALFORMED_REQUEST which means the request is plain wrong
 - should we add an UNPROCESSED option? IMHO it should not add
  an UNPROCESSED option for this reason, i.e., if there can be one
  because and only because of another bad option

Thanks

[email-masked]

PS: of course this is at lowest priority...

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Sep 2011 09:30:49 -0400

>   * MALFORMED_REQUEST which means the request is plain wrong

I think it should be UNSUPP_OPTION for two reasons:

1. It might be useful to include UNPROCESSED in a request in a future
PCP extension. (I have no use case in mind.) Using UNSUPP_OPTION makes
extensibility possible.

2. UNSUPP_OPTION is more precise because it includes an UNPROCESSED
option in the response which points at the UNPROCESSED option in the
request. This tells the client exactly where the problem is.
MALFORMED_{OPTION,REQUEST} are generic and can identify tons of other
problems.

>   because and only because of another bad option

I don't see why UNPROCESSED should be treated differently. Adding
UNPROCESSED in the response also allows #2 above.

> PS: of course this is at lowest priority...

Of course! Please publish ASAP!

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Francis Dupont <[email-masked]>
Date: Mon, 12 Sep 2011 16:33:56 +0200

In your previous mail you wrote:

   
   
=> I can't see the reasoning?!

   request.

=> it doesn't because the UNPROCESSED option code can't be distinguished
from padding (i.e., both are zero).

   This tells the client exactly where the problem is.
   MALFORMED_{OPTION,REQUEST} are generic and can identify tons of other
   problems.
   
=> it is the case of most error codes in PCP (:-)...

   >   because and only because of another bad option
   
   I don't see why UNPROCESSED should be treated differently.

=> option code == 0

=> the editor is Dan

Thanks

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Sep 2011 10:37:50 -0400

> from padding (i.e., both are zero).

Ah, right. *sigh*

Then I don't care anymore about this.

Simon