Subject: [pcp] a question about errors

From: Francis Dupont <[email-masked]>
Date: Thu, 01 Sep 2011 22:46:32 +0200

When a FILTER option is included into a PEER request I have the
choice between raising the UNSUPP_OPTION error or the MALFORMED_OPTION
error. The text says "as appropriate" which doesn't help too much.

The UNSUPP_OPTION error is easier to code as the PEER parsing has
only to deal with options it expects and looks at the highest bit of
the code of other options. So if it is not a shame to do that it seems
a reasonable "lazy" choice.

The MALFORMED_OPTION error is IMHO a bit better but needs extra code
and should not change things for the client: I don't believe users
will imagine the FILTER option (or the PREFER_FAILURE option) is
not supported...

So I have two questions:
 - is it acceptable to return UNSUPP_OPTION?
 - should the document be more accurate? Currently we had this kind of
  things only when a result code gives more useful information than
  an alternative, here it is not the case and BTW UNSUPP_OPTION covers
  few cases than MALFORMED_OPTION (:-).

Thanks

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 2 Sep 2011 08:13:56 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Thursday, September 01, 2011 1:47 PM
> To: [email-masked]
> Subject: [pcp] a question about errors
> 

FILTER is illegal with PEER, so either error seems fine -- FILTER is
unsupported with PEER (but may well be supported with MAP on that
same PCP server) so UNSUPP_OPTION is fine.  MALFORMED_OPTION is fine,
too.

Does it matter?  If it does matter, how might this be best clarified
in the doc?

-d

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

---

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

> error. The text says "as appropriate" which doesn't help too much.
   
   FILTER is illegal with PEER, so either error seems fine --

=> I agree about implementations but I am writing a conformance
testing tool and for this kind of beast it is better to have
a stricter spec (i.e., something at the SHOULD level).

   FILTER is unsupported with PEER (but may well be supported with MAP
   on that same PCP server) so UNSUPP_OPTION is fine.

=> a strict interpretation of the spec could be:
 if an option code is not supported with all opcodes then it SHOULD raise
 an UNSUPP_OPTION (i.e., it means not supported in all cases)

   MALFORMED_OPTION is fine, too.
   
=> for this one: if an option code is supported for a different opcode
than it SHOULD raise a MALFORMED_OPTION (i.e., it is used in a case
it MUST NOT)

=> IMHO it matters but at the lowest priority...
BTW I have two other funny cases where the error to raise is not clears
(i.e., there are some open choices).

Thanks