ACK_TIMER Handling

[nomis52]

Scott: I agree with this view. I know Eric does as well so it looks like the majority support this.

Originally Posted by hamish

My view is that there are four categories of interpretation of the standard.

1. ERROR.
It is deviant from the standard and will cause interoperability issues, IE, this issue.

2. WARINING.
It is deveiant from the standard but should have minimal impact on operability, IE declaring a mandatory parameter.

3. ADVISORY
It is not covered by the standard but is likley to cause problems, IE a sensor temperature out side of the stated scale range.

4. COMPLIANT

On Peters proposal, an alternative ACK would be required, however, I wouldn't want to confuse that point with the issue of complinace.

As discussed at large at the last CPWG, a universal test standard has to be the way forwards. Anything that brings up a category 1 result should be declaired incompatible.

Ok, I'll go forward with my interpretation. At the moment the test framework just has ERROR & WARNINGS and I've put all deviations (no matter how minor) from the standard into the ERROR category. We can discuss this more in Dallas and I can split it out if people think it's worthwhile.

[nomis52]

Originally Posted by nomis52

At the moment the test framework just has ERROR & WARNINGS and I've put all deviations (no matter how minor) from the standard into the ERROR category. We can discuss this more in Dallas and I can split it out if people think it's worthwhile.

I've gone ahead and added ADVISORY messages. You can read more about the entire test framework here: http://opendmx.net/index.php/Writing...esponder_Tests