Command Class / Parameter ID mismatch handling

[dangeross]

What is the consensus on how a responder should handle and respond to a Command Class CC data and Parameter ID PID data mismatch. As an example if the CC data is DISCOVERY_COMMAND and the PID data is DEVICE_INFO assuming it is not a broadcast address should the responder ignore the command and do nothing or respond with a NACK and if a NACK response is called for should the NACK reason code be NR_UNKNOWN_PID meaning that the CC Command Class takes precendence over the PID Parameter ID or should the NACK reason code be NR_UNSUPPORTED_COMMAND_CLASS which would mean that the PID Parameter ID takes precedence over the CC Command Class.
I am assuming that if the address is a broadcast address that I should just ignore the packet and wait for a valid packet.

[ericthegeek]

To be strictly compliant with the example you've given, I think you have to drop the packet and not respond.

Table 6-7 explicitly dis-allows NACKs is response to a Discovery, and according to section 6.3.4:

"The response RESPONSE_TYPE_NACK_REASON shall only be used in conjunction with the
Command Classes GET_COMMAND_RESPONSE & SET_COMMAND_RESPONSE."

This has always bugged me about how NACK_REASON is defined. If you get some unknown PID, say 0x56, if you strictly follow the standard you can't respond and must drop the packet.

A controller should probably be able to handle the case where an oddball CC gets NACK'd though, just in case.

[sblair]

A good implementation of a controller should be able to handle the NACK without falling over but strictly speaking as Eric mentioned NACK's were disallowed for that CC.

It mainly had to do with the fact that if you had NACK's (or ACK_TIMER) on any of the well-defined PID's in the Discovery CC it would completely break discovery. The odd-ball PID under the wrong CC was less of a concern at the time.