feat: make versioning optional

[juliapampus]

What this PR changes/adds

Makes versioning an optional feature. Moves existing text to new section.

Why it does that

Some dataspaces may not require connectors to expose a .well-known endpoint.

Further notes

Discussed in committer round on 08.05.2025.

Linked Issue(s)

Relates #146

Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

[jimmarino]

I made a proposal to re-word the first section to clarify that optionality concerns whether versioining metadata is offered and if it is, it should be in the following format.

I streamlined some of the wording and put normative statements in lowercase because I think that is required for PAS submission.

I also had one suggestion for clarification of the last paragraph.

[jimmarino]

Suggested change

	The adoption of versioning to implementations that comply with this specification is optional.
	Implementations may choose to support the discovery of versioning metadata. If version metadata is supported, an implementation must comply with the normative statements in this section.

[jimmarino]

Suggested change

[=Connectors=] implementing the [=Dataspace Protocol=] may operate on different versions and bindings. Such information should be discoverable reliably and unambiguously. If a [=Dataspace=] requires [=Connectors=] to expose supported versions, each [=Connector=] _MUST_ provide the version metadata endpoint using the `dspace-version` Well-Known Uniform Resource Identifier [[rfc8615]] at the top of the path hierarchy. Example: `<host>/.well-known/dspace-version`

[=Connectors=] implementing the [=Dataspace Protocol=] may support different versions and bindings. Such information should be discoverable reliably and unambiguously. If a [=Dataspace=] requires [=Connectors=] to expose supported versions, each [=Connector=] must provide the version metadata endpoint using the `dspace-version` Well-Known Uniform Resource Identifier [[rfc8615]] at the top of the path hierarchy. For example: `<host>/.well-known/dspace-version`

[jimmarino]

Suggested change

	A [=Connector=] _MUST_ respond to a respective HTTPS request by returning a [`VersionResponse`](#VersionResponse-table)
	A [=Connector=] must respond to the HTTPS request by returning a [`VersionResponse`](#VersionResponse-table)

[jimmarino]

Suggested change

	This data object _MUST_ comply to the [JSON Schema](message/schema/protocol-version-schema.json). The requesting [=Connector=] _MAY_ select from the endpoints in the response. If the [=Connector=] cannot identify a matching [=Dataspace Protocol=] version, it _MUST_ terminate the communication. The version endpoint _MUST_ be unversioned and unauthenticated.
	This data object must comply with the [JSON Schema](message/schema/protocol-version-schema.json). The requesting [=Connector=] may select from the endpoints in the response. If the [=Connector=] cannot identify a matching [=Dataspace Protocol=] version, it must terminate the communication. The version endpoint must be unversioned and unauthenticated.

[jimmarino]

Suggested change

	When using the DSP HTTPS binding, the `path` property is an absolute URL path segment to be appended to the domain for all endpoints of this version.
	When using the DSP HTTPS binding, the `path` property is a URL path segment to be appended to the domain for all endpoints of this version.

[jimmarino]

This is confusing. I think it woul be easier to read if it was in bullet form. For example:

The following example demonstrates a Connector that:

• Offers the HTTPS binding supporting version 2024-1 at...
• Offers the HTTPS binding supporting version 2025-1 at...
• .... etc

[lgblaumeiser]

Catena-X can go with this change, i.e., I do not see anything blocking left after this change.

Although imho, the usage of the Well-Known mechanism is a wrong decision for the reasons I already mentioned, it adds complexity without a real world benefit.