docs: decision record about multiple protocol versions

[wolf4ood]

What this PR changes/adds

Decision record about multiple protocol versions

Why it does that

Briefly state why the change was necessary.

Further notes

List other areas of code that have changed but are not necessarily linked to the main feature. This could be method
signature changes, package declarations, bugs that were encountered and were fixed inline, etc.

Linked Issue(s)

Closes # <-- insert Issue number if one exists

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

[ndr-brt]

just an idea... why not use the protocol field that already exist?
currently the value is always dataspace-protocol-http, it could become dataspace-protocol-http:version, that will likely simplify the work:

• no need to change CN and TP entities
• no need to change RemoteMessage interface and relative implementations
• no need to change ContractRequest and TransferRequest

all the rest looks good

wdyt?

[wolf4ood]

I also though about this, it will probably reduce the work for supporting an additional fields everywhere.
It make sense but it would require to register multiple DspHttpRemoteMessageDispatcher for different versions.
which has a downside that today we inject DspHttpRemoteMessageDispatcher and register all the message handling there

[wolf4ood]

Probably by refactoring the RemoteMessageDispatcherRegistry

@ExtensionPoint
public interface RemoteMessageDispatcherRegistry {

    /**
     * Registers a dispatcher.
     */
    void register(String protocol, RemoteMessageDispatcher dispatcher);
}

Could allow us to register the same DspHttpRemoteMessageDispatcher for different versions

[ndr-brt]

I also though about this, it will probably reduce the work for supporting an additional fields everywhere. It make sense but it would require to register multiple DspHttpRemoteMessageDispatcher for different versions. which has a downside that today we inject DspHttpRemoteMessageDispatcher and register all the message handling there

we could refactor the dispatcher registry to being able to support the version (e.g. by split the protocol field by : and detect the "name" part) so we can keep a single dispatcher implementation that will be able to discern between different versions and act properly.

otherwise also refactor the DspHttpRemoteMessageDispatcher to keep the common logic separated and make only the "delta" logic injectable so we can easily register multiple dispatcher for multiple versions with different injections/configurations.

Maybe we are getting too technical here, but it's just a matter of refactoring

[wolf4ood]

i would try to stick to a single DspHttpRemoteMessageDispatcher since basically the diff is only the transformers and the json-ld context which can be configured in different context/scope per version. the logic then is the same.

Having automatically split in the registry will work but it will always dispatch even of unsupported versions. In case we could put a check in the implementation underlying

What about the refactoring I proposed above? in case i can amend the DR :) and go with the version in the protocol field

[ndr-brt]

i would try to stick to a single DspHttpRemoteMessageDispatcher since basically the diff is only the transformers and the json-ld context which can be configured in different context/scope per version. the logic then is the same.

Having automatically split in the registry will work but it will always dispatch even of unsupported versions. In case we could put a check in the implementation underlying

What about the refactoring I proposed above? in case i can amend the DR :) and go with the version in the protocol field

looks good to me 👍