View Single Post
Old December 16th, 2018   #14
Task Group Member
Join Date: Aug 2008
Posts: 369


There can be endless battles about which NACK Reason Code to use in a myriad of situations. There's no "right" answer to many of those cases. This is especially true when looking at cases like this.

Fortunately, even though there's no canonical answer, it doesn't really hurt interoperability. For most real-world situations there are only two categories of NACKs: Transient and Final (my terms, not anything that's defined in the standard). In general, it doesn't really matter which specific NACK you use, as long as you use one from the right category.

A transient NACK represents a situation where the request failed this time, but might succeed if you retry. This category includes Proxy Reject and Buffer Full. In these situations, the controller might want to retry before notifying the user of a failure.

A final NACK tells the controller that the request has definitively failed. There's no point in retrying because it will fail again. This category includes Unknown PID and Format Error. For these cases the controller will usually notify the user, and the NACK Reason code just gives the user a hint about why it failed It would be unusual for the controller to try and programmatically act on a NACK in this category.

Seen from this perspective, the NACK Reason should be selected to give the user the best understanding of what's gone wrong, and an inkling of how to correct it. With only a few codes to pick from this can be challenging, but it's all that's available.

There are obviously some grey areas here (Hardware Fault, Write Protect), but IMO it's a good way to approach NACK'ing.

In the past, there have been some requests to make NACK'ing extremely prescriptive; Each PID would have a list of ways it can fail, and an explicit requirement of which NACK to use. It's impossible to enumerate everything that can go wrong. In the end, it's up to the implementer to make sensible choices.
ericthegeek is offline   Reply With Quote