Problem description
/check and /retrieve-date remain mandatory — neither declares 501 or any optionality. But info.description (L16) and the /retrieve-age-band operation description both read as if a provider offering age-band could skip them too:
An API provider is not expected to support all of them: the age-band operation is an alternative to exposing the exact SIM swap date...
This operation... is not expected to be supported in addition to check and retrieve-date; support depends on the provider's available capabilities and commercial use case.
Possible evolution
Narrow both passages to scope optionality to /retrieve-age-band only, and state plainly that /check and /retrieve-date remain mandatory.
Additionally, note on /retrieve-date that latestSimChange is nullable when the provider can't return it for privacy reasons (the existing monitoredPeriod mechanism) — the operation description doesn't currently say this.
Alternative solution
Make /retrieve-date optional via 501. This is a breaking change and requires a new major version — not something to bundle into this docs pass.
Additional context
Raised during Release Management review of the r4.1 rc snapshot (#283).
Problem description
/checkand/retrieve-dateremain mandatory — neither declares501or any optionality. Butinfo.description(L16) and the/retrieve-age-bandoperation description both read as if a provider offering age-band could skip them too:Possible evolution
Narrow both passages to scope optionality to
/retrieve-age-bandonly, and state plainly that/checkand/retrieve-dateremain mandatory.Additionally, note on
/retrieve-datethatlatestSimChangeis nullable when the provider can't return it for privacy reasons (the existingmonitoredPeriodmechanism) — the operation description doesn't currently say this.Alternative solution
Make
/retrieve-dateoptional via501. This is a breaking change and requires a new major version — not something to bundle into this docs pass.Additional context
Raised during Release Management review of the r4.1 rc snapshot (#283).