When locked, which comes first, NR_WRITE_PROTECT or message checking? - E1.20 RDM (Remote Device Management) Protocol Forums

shawn · November 14th, 2018

Thanks for your quick response, Scott.

My WRITE_PROTECT code is already only at the top of the part that examines SET messages (per section 3.7 of E1.37-1, where it says that LOCK plus WRITE_PROTECT is for SET_COMMAND).

I think that I'll return NR_WRITE_PROTECT before checking message format and data, but I'm still considering whether to return NR_WRITE_PROTECT before checking for UNKNOWN_PID and before UNSUPPORTED_COMMAND_CLASS.

Here's why I'm debating this. On trusted systems and setups, I don't see a problem broadcasting information about what is and isn't supported on the device. However, if someone took the trouble to lock things down (even with a minimal capability like E1.37-1's LOCK), then is it more security conscious to not leak this information? Maybe this is overthinking it too much on what isn't really a secure system anyway.

So then the other consideration is what would be "nice to have" from the controller's point of view? WRITE_PROTECT on all SET commands or WRITE_PROTECT on only supported SET commands?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Queued Message for SubDevices	sandor	RDM Interpretation Questions	7	January 23rd, 2026 08:29 AM
Status Message Markers	hamish	RDM General Implementation Discussion	4	December 9th, 2010 11:12 PM

November 14th, 2018	#3
shawn Junior Member Join Date: Nov 2018 Location: Oakland, CA, USA Posts: 23	Thanks for your quick response, Scott. My WRITE_PROTECT code is already only at the top of the part that examines SET messages (per section 3.7 of E1.37-1, where it says that LOCK plus WRITE_PROTECT is for SET_COMMAND). I think that I'll return NR_WRITE_PROTECT before checking message format and data, but I'm still considering whether to return NR_WRITE_PROTECT before checking for UNKNOWN_PID and before UNSUPPORTED_COMMAND_CLASS. Here's why I'm debating this. On trusted systems and setups, I don't see a problem broadcasting information about what is and isn't supported on the device. However, if someone took the trouble to lock things down (even with a minimal capability like E1.37-1's LOCK), then is it more security conscious to not leak this information? Maybe this is overthinking it too much on what isn't really a secure system anyway. So then the other consideration is what would be "nice to have" from the controller's point of view? WRITE_PROTECT on all SET commands or WRITE_PROTECT on only supported SET commands?