[2.0.0 REVIEW] A case when both contentType and defaultContentType are missing

[postatum]

Looking at the spec, it's not clear whether contentType and defaultContentType are required.

These sections' writing makes ones assume the fields are not required, while others assume they are:

• Message Trait Object
• Message Object

The issue was brought up in this issue asyncapi/tck#26 and reported because of this comment by @fmvilas: asyncapi/tck#26 (comment)

I think you found a gap in the spec, @postatum. There should be a default value for defaultContentType or otherwise make it required (which I don't like). Can you create an issue on asyncapi/asyncapi repo?

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue.

Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[c-pius]

I also just stumbled over this topic.

messageObject makes the statement When omitted, the value MUST be the one specified on the defaultContentType field

defaultContentType makes the statement This value MUST be used by schema parsers when the contentType property is omitted. In case a message can't be encoded/decoded using this value, schema parsers MUST use their default content type.

I would actually read it like one of them MUST be present and just in case the value of defaultContentType leads to an error when parsing messages, the parser may fallback to its default.

The streetlights example also doesn't seem to have any of them which would be an error according to above reasoning.

[fmvilas]

Yeah, we should probably have a default defaultContentType value so when omitted, it would be application/json for instance.

[fmvilas]

Closing as it's a duplicate of #319