edit Special Considerations for multipart Content

Author: krishahn

versions/3.0.md

@@ -1413,9 +1413,9 @@ Note that in the above example, the contents in the `requestBody` MUST be string
 
 When passing complex objects in the `x-www-form-urlencoded` content type, the default serialization strategy of such properties is described in the `parameterContent` section as `form`.
 
-##### Special Considerations for `multipart` content
+##### Special Considerations for `multipart` Content
 
-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 allows complex structures as well as supporting mechanisms for multiple file uploads.
+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.
 
 When passing in `multipart` types, boundaries MAY be used to separate sections of the content being transferred — thus, the following default `Content-Type`s are defined for `multipart/*`:
 
@@ -1456,7 +1456,7 @@ requestBody:
               type: '#/components/schemas/Address'
 ```
 
-In scenarios where more control is needed over the Content-Type for `multipart` request bodies, an `encoding` attribute is introduced.  This attribute is _only_ applicable to `multipart/*` and `x-www-form-urlencoded` request bodies.
+An `encoding` attribute is introduced to give you more control than boundaries provides over the Content-Type for `multipart` request bodies.  This attribute is _only_ applicable to `multipart/*` and `x-www-form-urlencoded` request bodies.
 
 #### <a name="encodingObject"></a>Encoding Object