typo: paramter

Author: ralfhandl

versions/3.0.4.md

@@ -1697,7 +1697,7 @@ An `encoding` attribute is introduced to give you control over the serialization
 A single encoding definition applied to a single schema property.
 See [Appendix B](#dataTypeConversion) for a discussion of converting values of various types to string representations.
 
-Properties are correlated with `multipart` parts using the `name` parameter to `Content-Disposition: form-data`, and with `application/x-www-form-urlencoded` using the query string paramter names.
+Properties are correlated with `multipart` parts using the `name` parameter to `Content-Disposition: form-data`, and with `application/x-www-form-urlencoded` using the query string parameter names.
 In both cases, their order is implementation-defined.
 
 See [Appendix E](#percentEncodingAndFormMediaTypes) for a detailed examination of percent-encoding concerns for form media types.
@@ -2326,7 +2326,7 @@ Because of the potential for name clashes, the `operationRef` syntax is preferre
 for multi-document OpenAPI descriptions.
 
 Note that it is not possible to provide a constant value to `parameters` that matches the syntax of a runtime expression.
-It is possible to have ambiguous parameter names, e.g. `name: id, in: path` and `name: path.id, in: query`; this is NOT RECOMMENDED and the behavior is implementation-defined, however implementations SHOULD prefer the qualified interpretation (`path.id` as a path parameter), as the names can always be qualified to disambiguate them (e.g. using `query.path.id` for the query paramter).
+It is possible to have ambiguous parameter names, e.g. `name: id, in: path` and `name: path.id, in: query`; this is NOT RECOMMENDED and the behavior is implementation-defined, however implementations SHOULD prefer the qualified interpretation (`path.id` as a path parameter), as the names can always be qualified to disambiguate them (e.g. using `query.path.id` for the query parameter).
 
 ##### Examples