Ambiguity in section 4.3 concerning the .well-known/dspace-version endpoint

[lgblaumeiser]

Current formulation is:

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: /.well-known/dspace-version.

This sentence can only be fulfilled under specific assumptions and not in a general case. In a general case, the endpoint that follows rfc8615 can be outside of the path tree that is under control of the Connector. Even if it is possible to redirect an endpoint within the service to that endpoint, the coordination of multiple Connectors operated under the same address cannot be done by each Connector, at least not without all relevant Connectors knowing each other and implementing a coordination protocol to aggregate the content of the endpoint.

And is this really intended, that independent of the DSP protocol binding, it is required to provide an HTTP endpoint?

This concept adds a lot of operational complexity to a dataspace which might not need exactly this mechanism for providing the information to its participants. In my opinion, this does not solve a problem, as an abstract description of the semantics of an arbitrary dataspace is not a use case that will happen at all in real dataspace applications. I would strongly recommend to remove this as a normative MUST. As the responsible for providing the connector functionality within Catena-X I would prefer to not have to tell people to spend the effort for nothing.

[arnoweiss]

Regarding the .well-known discussion and the suitability for the DSP-protocol-endpoints, the committers on April 3rd judged the current solution to be suitable for the requirements at hand. If there's new scenarios challenging the status quo, it'll be brought up again.

For the multi-binding case (which is hypothetical still) it would be necessary to have a single entry point for each connector. That's why it was reduced down to HTTP as the least common denominator.