Allow using deprecated: true to tag Response Objects, Security Scheme Objects

[DavidBiesack]

Neither the Response Object or Security Scheme Object in OAS 3.2 allow them to be marked as deprecated: true.
Please update OAS so that these objects can be marked as deprecated: true.
As with other objects that can be deprecated, if the deprecated field is omitted, the default will be false.

[handrews]

The Security Scheme Object does have a deprecated field in 3.2.

What is the use case for the Response Object? The various deprecated fields are interpreted by clients as "you can do this, but you shouldn't and it might disappear." Responses come from the server, so the server can simply stop using the response, in which case why would it still be documented?

To put it another way, who would be expected to take action if a Response Object has deprecated: true, and what would that action be?

[DavidBiesack]

Thanks, @handrews -- I must have missed that for Security Scheme in 3.2!

Regarding Response Objects: As with any element that is deprecated, additional documentation will instruct consumers what the replacement is and perhaps when (what release or version) the value would no longer be used. For example, perhaps v1 of an API incorrectly used a 422 when it should use a 409, and v2 aims to corrects that for consistency with the rest of the API's operations, rather than let it exist as an inconsistency indefinitely. The accompanying description normally provides details or conditions which cause the service to return 422, and API evolution or external standards may require shifting to another response code; i.e. 409 may be a more "correct" response that matched the true meaning of the problem. Another situation may be changing a 200 response on a DELETE in v1 to return 204 in v2 instead. deprecation informs the consumer of the pending change.