Clarification on URL and it's resolution rules

[char0n]

Hello,

In the AsyncAPI 2.2.0 spec, there are multiple fields that have description containing: MUST be in the format of a URL. These fields include:

All URL fields

• Info.termsOfService
• Contact.url
• License.url
• ExternalDocumentation.url
• OAuthFlow.authorizationUrl
• OAuthFlow.tokenUrl
• OAuthFlow.refreshUrl

Does MUST be in the format of a URL mean that these fields allow only absolute URL as defined by rfc3986 section 4.3? It looks like that from all the examples in spec and given that the only field inside spec that explicitly mentions relative URLs is Server.url field. So I'm assuming only absolute URLs are allowed here, am I right?

Server.url field

Server.url field looks like an exception to URL handling within the spec and claims that URL MAY be relative. I assume that being relative complies with rfc3986 section 4.2?

---

I'm doing a lot of assumptions here. It would be great to have this all specified explicitly so that there is not place for assumptions and different interpretations. I'm willing to issue a clarification PR after we discuss this further.

PS: why not allow all URL fields to be relative? If the URL is relative it will be resolved using one of the Server.url (after it has been resolved itself against location where the AsyncAPI document is being served) as a Base URL. If no Server Object is defined, then the Base URL is automatically resolved against the location where the AsyncAPI document is being served.

Thanks!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[derberg]

Hey, you did not come to community meeting and somehow it got lost, sorry. Stale bot to the rescue 🚀 😄

More details in JSON Schema -> URL shoudl be of uri format so RFC3986. You want it explicit in the spec markdown file too, right? IMHO it definitely makes sense, users should not be forced to check JSON Schema

[char0n]

More details in JSON Schema -> URL shoudl be of uri format so RFC3986. You want it explicit in the spec markdown file too, right?

Yep, I expect the markdown file to be the single source of truth. I've created #780 to make it explicit.

IMHO it definitely makes sense, users should not be forced to check JSON Schema

Cool, I've created a PR that remedies the unclarity.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[char0n]

Closing as #782 has been merged to master as editorial change.

[asyncapi-bot]

🎉 This issue has been resolved in version 3.0.0-next-major-spec.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[asyncapi-bot]

🎉 This issue has been resolved in version 2.5.0-next-spec.5 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[derberg]

Recent comments about the release from the bot were added by mistake. More details in #899