Re-organize form-urlencoded guidance (3.1.1 port of 3923 4/6)

This re-organizes and streamlines the form-urlencoded guidance
that was consolidated from the Media Type Object.

It also adds an example of a base64-encoded URL query parameter.

Author: handrews

versions/3.1.1.md

@@ -1718,13 +1718,15 @@ The absence of all three of those fields is the equivalent of using `content`, b
 
 ##### Encoding the `x-www-form-urlencoded` Media Type
 
-See [Appendix E](#percentEncodingAndFormMediaTypes) for a detailed examination of percent-encoding concerns for form media types.
+To submit content using form url encoding via [RFC1866](https://tools.ietf.org/html/rfc1866), use the `application/x-www-form-urlencoded` media type in the [Media Type Object](#mediaTypeObject) under the [Request Body Object](#requestBodyObject).
+This configuration means that the request body MUST be encoded per [RFC1866](https://tools.ietf.org/html/rfc1866) when passed to the server, after any complex objects have been serialized to a string representation.
 
-To submit content using form url encoding via [RFC1866](https://tools.ietf.org/html/rfc1866), the following
-definition may be used:
+See [Appendix E](#percentEncodingAndFormMediaTypes) for a detailed examination of percent-encoding concerns for form media types.
 
 ###### Example: URL Encoded Form with JSON Values
 
+When there is no [`encoding` field](#mediaTypeEncoding), the serialization strategy is based on the Encoding Object's default values:
+
 ```yaml
 requestBody:
   content:
@@ -1741,11 +1743,7 @@ requestBody:
             properties: {}
 ```
 
-In this example, the contents in the `requestBody` MUST be encoded per [RFC1866](https://tools.ietf.org/html/rfc1866) when passed to the server.  In addition, the `address` field complex object will be serialized to a string representation prior to encoding.
-
-When passing complex objects in the `application/x-www-form-urlencoded` content type, the default serialization strategy of such properties is described in the [Encoding Object](#encodingObject)'s [`style`](#encodingStyle) property as `form`.
-
-With this example, given an `id` of `f81d4fae-7dec-11d0-a765-00a0c91e6bf6` and a US-style address (with ZIP+4) as follows:
+With this example, consider an `id` of `f81d4fae-7dec-11d0-a765-00a0c91e6bf6` and a US-style address (with ZIP+4) as follows:
 
 ```json
 {
@@ -1773,7 +1771,7 @@ id=%22f81d4fae-7dec-11d0-a765-00a0c91e6bf6%22
 
 ###### Example: URL Encoded Form with Binary Values
 
-`application/x-www-form-urlencoded` is a text format, which requires base64-encoding any binary data:
+Note that `application/x-www-form-urlencoded` is a text format, which requires base64-encoding any binary data:
 
 ```YAML
 requestBody:
@@ -1785,15 +1783,22 @@ requestBody:
           name:
             type: string
           icon:
-            # default for type string is text/plain, need to declare
-            # the appropriate contentType in the Encoding Object
+            # The default with "contentEncoding" is application/octet-stream,
+            # so we need to set image media type(s) in the Encoding Object.
             type: string
             contentEncoding: base64url
   encoding:
     icon:
       contentType: image/png, image/jpeg
 ```
 
+Given a name of `example` and a solid red 2x2-pixel PNG for `icon`, this
+would produce a request body of:
+
+```urlencoded
+name=example&icon=iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAYAAABytg0kAAAAEklEQVQIW2P8z8AARAwMjDAGACwBA/+8RVWvAAAAAElFTk
+```
+
 ##### Encoding `multipart` Media Types
 
 It is common to use `multipart/form-data` as a `Content-Type` when transferring request bodies to operations.  In contrast to 2.0, a `schema` is REQUIRED to define the input parameters to the operation when using `multipart` content.  This supports complex structures as well as supporting mechanisms for multiple file uploads.