On Tue, Dec 15, 2020 at 5:46 PM Richard Levitte <[email protected]> wrote:
> Of course, checking the gettable and settable tables beforehand works > as well. They were originally never meant to be mandatory, but I > guess we're moving that way... > The only one who knows whether or not a given parameter is critically important to have been used is the application. The gettable and settable interfaces provide the ability to check that. For forward and backward compatibility it makes no sense to wire in a requirement for complete knowledge of everything that is provided. You need to be able to provide extra optional parameters that some implementations want to consume and are entirely irrelevant to other implementations to have extensibility wired into the APIs and that was one of the purposes of the new plumbing - to be able to handle things going forward. If you change things at this late stage to basically say everything has to know everything then we lose that ability. In practical terms too, we need to be able to have later releases of applications able to work with earlier releases of providers (specifically but not limited to the FIPS provider) and it would practically mean you could never reach that interchangeable provider context that is there for a stable ABI - wiring in a requirement to be aware of all parameters will simply lead to provider implementations needing to ignore things to achieve the necessary outcome. If you want to know if a specific implementation is aware of something, the interface is already there. In short - I don't see an issue as there is a way to check, and the interface is designed for forward and backward compatibility and that is more important than the various items raised here so far IMHO. Tim
