Requirements on implementation concerning version support

[lgblaumeiser]

In section 4.3 of the current RC1, it is defined, how versions are exposed towards a client. This description indicates, that versions somehow are a part of the part as, e.g., defined in 6.1.1. In my opinion, the current section 4.3 misses some regulations on the implementation of the protocol on how to handle different versions.

I propose to get a bit more explicit here. Something, that a version specific base communication endpoint must enable to use the protocol by only applying the regulations of the corresponding spec version to that base.

[arnoweiss]

That's a good idea. There's an issue for this in the best-practices-repo [1]. If you have specific ideas or statements that should be in there, feel free to add them there. If there's nothing of normative nature that you think should be in the spec itself, I'd close this discussion as duplicate.

[1] eclipse-dataspace-protocol-base/dsp_best_practices#13

[lgblaumeiser]

Hi @arnoweiss, that is my problem, I do not have that deep insights into the mechanics of the protocol to really come up with a suitable proposal. The thing is, that in the current section 4.3, there is an implication by example, that a version is reflected by a path segment 2025-1 which even if not normative provides an idea of how versions should be handled in an implementation. There are some key aspects concerning the protocol that are relevant, if multiple versions are supported. A non-complete list are:

• The catalog service endpoints have to be identifiable concerning the version they support
• The catalog returned by this service need to provide negotiation endpoints that are version specific, i.e., an entry in a catalog received by a version 2025-1 catalog request must refer to a negotiation endpoint following the 2025-1 specification and the other way around a catalog provided by, e.g., a 2024-1 catalog request must contain only entries that can be negotiated by the 2024-1 specific protocol. The same applies then to transfer process, right?

In my opinion, that is what I expect from the spec to define the cornerstones concerning expectations a client has when talking to an implementation. That is something normative, imho. But as I said, I do not have a good enough overview over the implications on the implementation caused by the sequence of requests that need to be executed in the standard interaction.