Protocol Version Declaration and Negotiation Concept

[sebbader-sap]

In the (close) future, dataspace connectors must be able to announce their supported protocol version (or versions) and somehow be able to negotiate on the applied one.

Proposal:

• The protocol defines an endpoint/mechanism through which a connector can outline its supported protocol versions
• The protocol defines a mechanism how the receiver can see for each message in which version it is
• The protocol defines an error message / code in the existing error message stating "version not supported" and gives an indication which version could be processed.

[sebbader-sap]

Similar to https://github.com/International-Data-Spaces-Association/ids-specification/issues/15

[sebbader-sap]

Idea: Let's also leverage the well-known approach as also proposed in #161 , e.g. by:

.../.well-known/dspace-protocol[/connector1]

{
    "@context": "https://w3id.org/dspace/v1.0/context.json",
    "protocolVersions": [
       {
            "version": "1.0",
            "path": "/some/path/v1" 
       }
   ]
}

[sebbader-sap]

• The protocol defines a mechanism how the receiver can see for each message in which version it is
• The protocol defines an error message / code in the existing error message stating "version not supported" and gives an indication which version could be processed.

Not needed then as a request in a different message simply causes an error and it's up to the sender to figure out if he screwed up with the protocol versions.

[sebbader-sap]

Next step: Discuss proposal for #161 and mirror the explanation for this one here.

[ssteinbuss]

blocked by #172

[sebbader-sap]

PR has been approved and merged.