Test case "cv_fail_i2_as1_fail" has a missing cv value to check
AntiFreeze opened this issue · 2 comments
The cv values for the following three test cases are all missing, and should all be fail:
- cv_fail_i2_as1_fail
- cv_fail_i2_as2_fail
- cv_fail_i1_as_cv_fail
Is this the case? In all three of these test cases, a previous intermediary has explicitly marked the chain as failing. In this case, what is the chain's status to a future intermediary? The two options are fail or undefined. The empty cv values here are intended to specify undefined.
The answer is not 100% clear from the spec, but there is a valid practical argument for what is currently in the test suite. There are two mutually exclusive actions a signing intermediary can perform on a 'failing' chain. Capping the chain, and ignoring it, and it needs a way to distinguish these two circumstances. The defacto way of communicating chain status from verifiers to signers is via the cv= value(or lack there of) in an AR header created by the verifier, and what is in the test suite for these cases reflects this. When a signer sees no cv= value in a trusted AR, it performs no action. Leaving cv=blank in these test cases communicates to a signer that no signing action needs to take place for these test cases.
If these test cases were to be changed in the suggested fashion, then it is safe to assume that all verifiers will be stamping cv=fail in the AR headers for all chains which have been previously capped by other intermediaries. If this is the case then the burden now falls on the current signing intermediary to differentiate between the two 'failing' cases, now requiring signers to parse previous ARC sets, while as specified this is not necessary. I'm fairly certain this will require non trivial changes to existing ARC implementations.
Honestly all of this stuff should probably go into the RFC, as this is 100% outside of its scope atm. Either decision that is made here will result in the test suite making decisions that are not directly implied by the RFC. However I strongly believe the current situation is the more correct one.
In the current revision of the draft (-18), neither of these approaches is correct, so I'll close this issue and defer the correction to the results of the -08 to -18 update analysis.