I think this extension has a good intention, but I find it to be slightly too narrow and I think that the error code “Transfer protocol unsupported” (41) is more apt for this. 41 specifies that you use the field ‘PR’ for the protocol string that was invalid. Now, in this case (for ADC/1.0 vs ADCS/1.0), you would specify respond with “STA 41 PRADC/1.0”. Doing so has an implication: specifying that ADC/1.0 is invalid does not necessarily mean that (not-existant) “ADC/1.1” isn’t. I.e., you are saying “i don’t allow/know that” but aren’t giving a hint to what is actually allowed/you know. Therefore, I think a more general approach would be to add another field to this error code 41 for “hinted supported protocol string”, HR. To manage an ADCS requirement, you’d send “STA 41 PRADC/1.0 HRADCS/1.0”. I.e., “I don’t support ADC 1.0, but I will support ADCS 1.0”. If the HR field is supplied, I think the sending client can also include an appropriate message (or if the receiving does it) indicating to the user (if it is shown to them) that they need to turn on ADCS. Doing a generic approach to this also means we don’t need to include more and more error codes depending on protocol support.
I don’t know if another code can use the same field to have a similar effect.