[BUG] Server Object field "url" description is inaccurate

[gibson042]

Describe the bug
The AsyncAPI specification says about the Server Object url field that it contains a URL and "MAY be relative", but then uses as an example value "development.gigantic-server.com". This is not an (absolute) URL because it lacks a colon-terminated scheme such as "https", but if interpreted as a relative reference then the result will be something like "https://example.com/example-service/asyncapi.json/../development.gigantic-server.com" (specifically because "a relative reference that does not begin with a slash character is termed a relative-path reference" and inherits the authority component and path prefix of its base URI, cf. RFC 3986 section 4.2 and section 5.2.3).

To Reproduce
Steps to reproduce the behavior:

1. Navigate to https://www.asyncapi.com/docs/specifications/2.0.0/#serverObject or https://www.asyncapi.com/docs/specifications/1.2.0/#serverObject, or their respective git snapshots (2.0.0, 1.2.0).
2. Observe that url is a URL and "MAY be relative", but the absence of text allowing it to be a bare host name (or IP address, for that matter) despite the use of an example value that looks like one.

Expected behavior
Presumably the intent is to interpret values matching the RFC 1034 section 3.5 preferred name syntax as updated by RFC 1123 section 2.1 (i.e., non-address strings matching the regular expression pattern ^[a-zA-Z0-9]+(-+[a-zA-Z0-9]+)*(\.[a-zA-Z0-9]+(-+[a-zA-Z0-9]+)*)*$) as the host component of a URL with default scheme and path (e.g., "https://{value}/") and use the relative reference treatment only as a fallback. If so, the description should be updated accordingly.

And if there is also a desire to allow not just host names but also IP addresses, that should be documented as well.

Sample document
n/a

Screenshots
n/a

Additional context
n/a

[fmvilas]

Hey @gibson042! Thanks for reporting the bug. I think the problem is actually with the example. It should probably use tcp:// or kafka:// (not sure this one is valid). I don't think we should specify that IP addresses are allowed. They are because they can be part of a URL. I agree we could probably add an example using an IP address.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gibson042]

This is still relevant, it just lacks a clear path to resolution.

[nickspacek]

My suggestions to resolve:

1. Update all examples to use URLs that include scheme.
2. Add an additional example to illustrate how the server URL is determined when relative URLs are used and consider clarifying the language here.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jonaslagoni]

Is there any of you who wants to champion this? 🙂 Or can we consider this issue as needs champion? 🤔

[dalelane]

Can we say that this one is superseded by #547 ?

[derberg]

@dalelane definitely we can accept both 😄 I think you are right and better to just continue with #547

[fmvilas]

Yeah, I should have been clear on #547 that it's actually a proposal to fix this issue. Updating it. Thanks!

[fmvilas]

The proposal now moved to RFC 1 stage: #888. Have a look!