Reword as discussed in TSC meeting today

Author: mikekistler

versions/3.0.4.md

@@ -1755,7 +1755,7 @@ Note that there are significant restrictions on what headers can be used with `m
 Note also that `Content-Transfer-Encoding` is deprecated for `multipart/form-data` ([RFC7578 §4.7](https://www.rfc-editor.org/rfc/rfc7578.html#section-4.7)) where binary data is supported, as it is in HTTP.
 
 Using `format: byte` for a multipart field is equivalent to specifying an `encoding` object with a `headers` field containing `Content-Transfer-Encoding: { schema: { enum: [base64] } }`.
-If `format: byte` is used for a multipart field that has an encoding object with a `headers` field containing `Content-Transfer-Encoding` with a schema that permits values other than "base64", the result is undefined.
+If `format: byte` is used for a multipart field that has an encoding object with a `headers` field containing `Content-Transfer-Encoding` with a schema that disallows "base64", the result is undefined for serialization and parsing.
 
 Per the JSON Schema specification, `contentMediaType` without `contentEncoding` present is treated as if `contentEncoding: identity` were present.  While useful for embedding text documents such as `text/html` into JSON strings, it is not useful for a `multipart/form-data` part, as it just causes the document to be treated as `text/plain` instead of its actual media type.  Use the Encoding Object without `contentMediaType` if no `contentEncoding` is required.