adjust as per review feedback

Author: karenetheridge

src/oas.md

@@ -1731,6 +1731,9 @@ Therefore the `array` row in this table applies only to array values inside of a
 
 When deserializing a multipart message, if a `Content-Type` header is present in the specific part, its value shall be used instead of these values. Behavior is undefined when both this header and `contentType` are defined but with different values.
 
+When deserializing a multipart message, behavior is undefined when the values of `Content-Type` header and the `contentType` field differ.  If the `contentType` field is absent but `Content-Type` is present, it is RECOMMENDED to use the value of `Content-Type`.  However, this behavior is still technically undefined 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` |
@@ -1866,8 +1869,6 @@ 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; it SHOULD match one of the media types in `contentType`, if it is present.
-
 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.