Clarify usage or URN for an AsyncAPI spec id

[thake]

Describe the bug

The documentation of the id property of an AsyncAPI spec currently recommends using a URN as an id (https://www.asyncapi.com/docs/specifications/v2.3.0#A2SIdString).

The RFC of URN states that a URN needs to have a registered namespace in order to be valid:

While other URI schemes may allow resource identifiers to be freely chosen and assigned, such is not the case for URNs. The syntactical correctness of a name starting with "urn:" is not sufficient to make it a URN. In order for the name to be a valid URN, the namespace identifier (NID) needs to be registered in accordance with the rules defined here, and the remaining parts of the assigned-name portion of the URN need to be generated in accordance with the rules for the registered URN namespace.

This makes it very hard to provide valid URNs for the id property, as one needs to register a URN namespace at IANA.

Possible solution

IMHO the recommendation of using a URN should be changed to using an identifier that starts with a reverse-DNS name. Doing so would still make it possible to have unique IDs for AsyncAPI specs while not having to hassle with invalid URNs. Using a reverse-DNS prefixed id is a common pattern.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[smoya]

Relates to #718 (not the same)

[smoya]

It is not very clear to me, by the RFC, that informal URN namespaces should be registered as they already have the :urn{1-7} assigned: https://datatracker.ietf.org/doc/html/rfc8141#section-5.2 and https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml#urn-namespaces-2

Are you sure about that (asking because I have no idea)?

[mike-schenk]

By RFC 8141, even the informal URN namespace identifiers (NIDs) are meant to be registered with IANA. Section 5.2 says

the registrant does not designate the NID; instead, IANA assigns the NID

And section 7.2 says

In all cases, the IANA ought to assign the appropriate NID (formal or informal) once the procedures outlined in Section 6 have been completed.

So even an informal URN would need to be registered and, using a hypothetical informal URN namespace "8", would look something like urn:urn-8:com:smartylighting:streetlights:server

For what it's worth, I suggest keeping the requirement that the id must conform to the URI format, but I suggest changing the recommendation.

I suggest recommending the tag URI scheme to get the benefit of "identify[ing] the application during long periods of time, even after it becomes unavailable or ceases to exist,"

I recognize there are several examples of URNs with unregistered NIDs in other products and systems. Those usages were created before RFC8141 obsoleted RFC2141 in 2017. RFC2141 didn't require namespace identifiers to be registered with IANA, while RFC 2611 and RFC 3406 that described the registration process were only "Best current practices" documents. But a new industry standard like AsyncAPI should follow the latest standards-track RFC for URNs and respect the registration requirement.

[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 ❤️

[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 ❤️