Migrate 3.0 format guidance to content* (3.1.1 port add-on)

Various updates ported over from 3.0.4 mention using the `format`
values `byte` or `binary`, which have been replaced by the
`contentMediaType` and `contentEncoding` keywords.  This change
updates those ported chagnes accordingly.

Author: handrews

versions/3.1.1.md

@@ -1751,17 +1751,20 @@ requestBody:
             type: object
             properties: {}
           profileImage:
-            # Content-Type for properties with type string and contentEncoding is `application/octet-stream`
+            # default Content-Type for properties with type string and a contentEncoding
+            # is `application/octet-stream`, so `image/png` must be set using contentMediaType
             type: string
             contentMediaType: image/png
             contentEncoding: base64
           children:
-            # default Content-Type for arrays is based on the _inner_ type (`text/plain` here)
+            # default Content-Type for arrays is based on the items subschema type, which
+            # is a string, producing a default of `text/plain`
             type: array
             items:
               type: string
           addresses:
-            # default Content-Type for arrays is based on the _inner_ type (object shown, so `application/json` in this example)
+            # default Content-Type for arrays is based on the items subschema type, which
+            # is an object, producing a default of `application/json`
             type: array
             items:
               type: object
@@ -1791,17 +1794,18 @@ Field Name | Type | Description
 
 This object MAY be extended with [Specification Extensions](#specificationExtensions).
 
-The default values for `contentType` are as follows, where an _n/a_ in the `format` column means that the presence or value of `format` is irrelevant:
+The default values for `contentType` are as follows, where an _n/a_ in the `contentEncoding` column means that the presence or value of `contentEncoding` is irrelevant:
 
-Property `type` | Property `format` | Default `contentType`
-------------- | --------------- | ---------------------
-`string` | `binary` | `application/octet-stream`
-`string` | _none, or any except `binary`_ | `text/plain`
+Property `type` | Property `contentEncoding` | Default `contentType`
+--------------- | -------------------------- | ---------------------
+_absent_ | _n/a_ | `application/octet-stream`
+`string` | _present_ | `application/octet-stream`
+`string` | _absent_ | `text/plain`
 `number`, `integer`, or `boolean` | _n/a_ | `text/plain`
 `object` | _n/a_ | `application/json`
-`array` | _n/a_ | according to the `type` and `format` of the `items` schema
+`array` | _n/a_ | according to the `type` of the `items` schema
 
-Determining how to handle `null` values if `nullable: true` is present depends on how `null` values are being serialized.
+Determining how to handle a `type` value of `null` depends on how `null` values are being serialized.
 If `null` values are entirely omitted, then the `contentType` is irrelevant.
 See [Appendix B](#dataTypeConversion) for a discussion of data type conversion options.
 
@@ -1830,8 +1834,8 @@ It is not currently possible to correlate schema properties with unnamed, ordere
 Note that there are significant restrictions on what headers can be used with `multipart` media types in general ([RFC2046 §5.1](https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1)) and `multi-part/form-data` in particular ([RFC7578 §4.8](https://www.rfc-editor.org/rfc/rfc7578.html#section-4.8)).
 
 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 setting `Content-Transfer-Encoding: base64`.
-If `format: byte` is used along with setting a different `Content-Transfer-Encoding` value with the `headers` field, the result is undefined.
+Using `contentEncoding` is equivalent to setting `Content-Transfer-Encoding` to the same value.
+If `contentEncoding` is used along with setting a different `Content-Transfer-Encoding` value with the `headers` field, the result is undefined.
 
 ##### Encoding Object Example
 
@@ -4200,7 +4204,7 @@ To control the serialization of numbers, booleans, and `null` (or other values R
 The resulting strings would not require any further type conversion.
 
 The `format` keyword can assist in serialization.
-Some formats (such as `date-time` or `byte`) are unambiguous, while others (such as [`decimal`](https://spec.openapis.org/registry/format/decimal.html) in the [Format Registry](https://spec.openapis.org/registry/format/)) are less clear.
+Some formats (such as `date-time`) are unambiguous, while others (such as [`decimal`](https://spec.openapis.org/registry/format/decimal.html) in the [Format Registry](https://spec.openapis.org/registry/format/)) are less clear.
 However, care must be taken with `format` to ensure that the specific formats are supported by all relevant tools as unrecognized formats are ignored.
 
 Requiring input as pre-formatted, schema-validated strings also improves round-trip interoperability as not all programming languages and environments support the same data types.
@@ -4453,8 +4457,9 @@ This will expand to the result:
 RFC6570's percent-encoding behavior is not always appropriate for `in: header` and `in: cookie` parameters.
 In many cases, it is more appropriate to use `content` with a media type such as `text/plain` and require the application to assemble the correct string.
 
-For both cookies ([RFC6265](https://www.rfc-editor.org/rfc/rfc6265)) and HTTP headers using the structured fields ([RFC8941](https://www.rfc-editor.org/rfc/rfc8941)) syntax, non-ASCII content is handled using base64 encoding (`format: byte`).
+For both cookies ([RFC6265](https://www.rfc-editor.org/rfc/rfc6265)) and HTTP headers using the structured fields ([RFC8941](https://www.rfc-editor.org/rfc/rfc8941)) syntax, non-ASCII content is handled using base64 encoding (`contentEncoding: base64`).
 Note that the standard base64 encoding alphabet includes non-URL-safe characters that are percent-encoded by RFC6570 expansion; serializing values through both encodings is NOT RECOMMENDED.
+While `contentEncoding` also supports the `base64url` encoding, which is URL-safe, the header and cookie RFCs do not mention this encoding.
 
 Most HTTP headers predate the structured field syntax, and a comprehensive assessment of their syntax and encoding rules is well beyond the scope of this specification.
 While [RFC8187](https://www.rfc-editor.org/rfc/rfc8187) recommends percent-encoding HTTP field (header or trailer) parameters, these parameters appear after a `;` character.