Merge pull request #5391 from karenetheridge/ether/v3.3-multipart-content-type

v3.3: describe behaviour when deserializing a multipart with a Content-Type header

Author: miqui

src/oas.md

@@ -1734,6 +1734,9 @@ This table is based on the value to which the Encoding Object is being applied a
 Note that in the case of [Encoding By Name](#encoding-by-name), this value is the array item for properties of type `"array"`, and the entire value for all other types.
 Therefore the `array` row in this table applies only to array values inside of a top-level array when encoding by name.
 
+When deserializing a multipart message, if a `Content-Type` header is present in the specific part, its value SHALL be used instead of these default values. Behavior is undefined when both this header and `contentType` are defined but with different values; it is RECOMMENDED to use the value of `Content-Type`. However, this behavior may produce unexpected results due to the possibility that the `schema` is not structured for the received `Content-Type`.
+
+
 | `type` | `contentEncoding` | Default `contentType` |
 | ---- | ---- | ---- |
 | [_absent_](#working-with-binary-data) | _n/a_ | `application/octet-stream` |
@@ -1869,7 +1872,7 @@ Note that there are significant restrictions on what headers can be used with `m
 
 ##### Handling Multiple `contentType` Values
 
-When multiple values are provided for `contentType`, parsing remains straightforward as the part's actual `Content-Type` is included in the document.
+When multiple values are provided for `contentType`, deserializing remains straightforward as, per [[RFC 2046]] [Section 5.1](https://datatracker.ietf.org/doc/html/rfc2046#section-5.1) each part will include a `Content-Type` header, or can reasonably be assumed to be `text/plain; charset=US-ASCII`.  To ensure interoperability, OAD authors SHOULD ensure that all reasonably expected media types are provided in `contentType`.
 
 For encoding and serialization, implementations MUST provide a mechanism for applications to indicate which media type is intended.
 Implementations MAY choose to offer media type sniffing ([[SNIFF]]) as an alternative, but this MUST NOT be the default behavior due to the security risks inherent in the process.