The Response object's `default` field is confusing and inconsistently interpreted

According both 3.0 and 3.1, in theResponse object there MUST be at least one response code and it SHOULD be the response for a successful operation call. In addition the default describes “responses other than the ones declared for specific HTTP response codes”.

This means that if we had a 200 response and default, the latter would cover everything except for 200. Many seem to interpret default to mean something like response categories not covered by explicit response codes. Consider this example from the OAI org:

responses:
        '200':
          description: pet response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Pet'
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'

https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml

This implies that default covers error types when in fact it covers non-error responses as well. In fact, the consumer wouldn't necessarily know if the API might reply with another success code such as a 204. A more precise example might look like this:

responses:
        '200':
          description: pet response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Pet'
        4xx:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
        5xx:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'

I would suggest the following actions:

1. Update the example to interpret the spec more literally
2. Clarify default since this confusion is not limited to this example, but extends to APIs in the wild
3. Consider in 3.2 or 4.0 eliminating default
4. Consider in 3.2 or 4.0 adding a new named error category that means "both 4xx and 5xx". This could be used in the way that default is often misused today

Beginne mit der Durchsicht von examples/v3.0/petstore-expanded.yaml und den Definitionen des Response-Objekts für OpenAPI 3.0 und 3.1. Vergleiche die dokumentierte Bedeutung von default mit der im Beispiel vorgesehenen Fehlerbehandlung und ermittle, welche Klarstellung oder Aktualisierung des Beispiels umsetzbar ist; der Abschluss würde eine abgestimmte Änderung an der Spezifikation oder den Beispielen erfordern.