Insufficient means to reject the CIP Identity Reset from the host application

There are two situations where it makes sense to reject the CIP reset service that is received from the network

(according to CIP Volume 1, section 5A-2.4.1 "Reset Service"):

1. If a device is temporarily in a state where it cannot handle the reset.
   The proper error code would be "Device State Conflict" (0x10). This is explicitly mentioned in the specification.
2. If a device does not support the requested reset type, e.g. if the type 1 reset is not supported at all by the device.
   The proper error code, also according to the spec., would be "Service Not Supported For Specified Path" (0x2E).

With  the current implementation, if the host puts a nonzero error code into the tHead.ulSta field of the RESET_RES packet, the stack always sends the CIP reset response with "Device State Conflict" on the network. Thus, a host application cannot properly implement the specification requirements according to case 2.