Filling Device Labels to 32 chars is an error? - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · June 13th, 2013

Hamish is right. Because of the way the language in the standard is written, you can't "NACK" a request with a Discovery Command Class. NACK can only be used with GET and SET requests.

Also, this means that you can't NACK a request with an unknown command class.

This wasn't really the intent. The intent of the standard was to simplify discovery by requiring that a responder always handle discovery requests immediately and not be slowed down/complicated by NACK, ACK_TIMER or ACK_OVERFLOW responses. But because of the way the standard is written, it effectively means you can't NACK a corrupt discovery request. Your only valid choice is to ignore the request.

It's common to see responders that will NACK invalid discovery requests, so controllers should be able to handle that condition. But if you stick with the language as it's written in the standard, NACKs are not allowed.

June 13th, 2013	#10
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	Hamish is right. Because of the way the language in the standard is written, you can't "NACK" a request with a Discovery Command Class. NACK can only be used with GET and SET requests. Also, this means that you can't NACK a request with an unknown command class. This wasn't really the intent. The intent of the standard was to simplify discovery by requiring that a responder always handle discovery requests immediately and not be slowed down/complicated by NACK, ACK_TIMER or ACK_OVERFLOW responses. But because of the way the standard is written, it effectively means you can't NACK a corrupt discovery request. Your only valid choice is to ignore the request. It's common to see responders that will NACK invalid discovery requests, so controllers should be able to handle that condition. But if you stick with the language as it's written in the standard, NACKs are not allowed.