3 ms·
> As a client, you've got to be ready to deal with non-conformant implementations The whole point of the "MUST" vs "SHOULD" is that you can assume that you don
by shkkmo 3y ago
> As a client, you've got to be ready to deal with non-conformant implementations
The whole point of the "MUST" vs "SHOULD" is that you can assume that you don't have to handle implementations that aren't compliant (e.g. don't do the things they must do to be in compliance) but do need to worry about handling edge-cases where implementations are in compliance but not doing things the way they should.
Both tools (the vulnerability scanner and Prometheus) should make changes but I would consider the Prometheus change to be a bug report (which they can clearly choose to not fix and still be compliant) and the vulnerability scanner would be a feature request to check file contents rather than just relying on the status.
- andrewaylett 3y agoNot at all -- the point (in general) of MUST is that as a service owner, you can assume that your implementation won't work properly unless you adhere to the specification. But unless you control all of the implementations you're interacting with, you can't assume that they'll conform. You might well decide to handle non-compliance by declining to continue, but you still need to handle those cases. I don't disagree with your assessment of the changes required to Prometheus or the vulnerability scanner, but I'd rate the Prometheus bug as really low priority, and the feature request for the scanner as a blocker for adoption: it might be correctly behaving as designed, but that doesn't mean the design is useful.