MediaType RFC6838 Due diligence

[ioggstream]

I expect

some due diligence, eg. https://datatracker.ietf.org/doc/html/rfc6838#section-4.3

• Parameter names are case-insensitive and no meaning is attached to
  the order in which they appear.

we only have one parameter, so we do not mention order or upper/lower meanings.

• It is an error for a specific parameter to be specified more than once.

we do not explicitly say that the parameter should be used more than once

• There is no defined syntax for parameter values. Therefore, registrations MUST specify parameter value syntax.

See #124

[handrews]

@darrelmiller how does this bit from RFC 6838 §4.3 square with the version media type parameter for OpenAPI?

New parameters SHOULD NOT be defined as a way to introduce new
functionality in types registered in the standards tree, although new
parameters MAY be added to convey additional information that does
not otherwise change existing functionality. An example of this
would be a "revision" parameter to indicate a revision level of an
external specification such as JPEG.

[darrelmiller]

@handrews It doesn't. But the requirement is a SHOULD, not a must. I think the value of being able to CONNEG versions of OpenAPI mitigates the violation of this SHOULD, especially as it is possible to mechanically translate from different versions of OpenAPI with minimal loss in many cases.
The goal of standards is interoperability and preventing versioning CONNEG would hurt interoperability, in my opinion.

[ioggstream]

Reading above

New parameters SHOULD NOT be defined as a way to introduce new
functionality in types registered in the standards tree

Since application/openapi+* is not (yet) registered in the standard tree, I am not sure this applies in our case.