Not needed `callbackAddress` in `ContractAgreementMessage`

[wolf4ood]

Bug Report

Describe the Bug

The spec states here

that the ContractAgreementMessage should have a required property callbackAddress.
But since the callbackAddress is already present in ContractRequestMessage or in ContractOfferMessage,
it should be removed from ContractAgreementMessage as it seems redundant

Type: normative / non-normative <-- please specify the affected scope

Expected Behavior

A clear and concise description of what you expected to happen.

Observed Behavior

A clear and concise description of what happened instead.

Detailed Description

If applicable, add some context information to help explain your problem.

Possible Implementation

You already know the root cause of the erroneous state and how to fix it? Feel free to share your thoughts.

[juliapampus]

Each message should be processed independently of other messages without requiring contextual information (context in this case means the negotiation process). This allows for different architectures and processing by different systems. Anything else would impose technical requirements on DSP implementations, such as storing process information. Therefore, in my opinion, every message that has potential follow-up messages according to the state machine should contain a mandatory callbackAddress.

[wolf4ood]

It make sense but If so then the issue is in the other way around

Currently the callbackAddress is missing on

• ContractNegotiationEventMessage
• ContractAgreementVerificationMessage

which they have a potential follow-up

[juliapampus]

I've taken a look at this issue again. We indeed have inconsistencies regarding the callbackAddress property.

Assumptions

@arnoweiss @jimmarino @mkollenstart

First, we agreed on using the callbackAddress for consumer-sent messages, right? The provider has no callback path.

Second, did we agree on option a) or option b)?

a) Every message that is sent by the consumer must provide a callback address.
b) The first message that is sent by the consumer must provide a callback address.

Current status

Negotiation process

• ContractRequestMessage --> sent by C --> mandatory callbackAddress
• ContractOfferMessage --> sent by P --> mandatory callbackAddress
• ContractNegotiationEventMessage --> sent by C or P --> no callbackAddress
• ContractAgreementMessage --> sent by P --> mandatory callbackAddress
• ContractAgreementVerificationMessage --> terminal status --> no callbackAddress
• ContractNegotiationTerminationMessage --> terminal status --> no callbackAddress

Transfer process

• TransferRequestMessage --> sent by C --> mandatory callbackAddress
• TransferStartMessage --> sent by P --> no callbackAddress
• TransferSuspensionMessage --> sent by P or C --> no callbackAddress
• TransferCompletionMessage --> terminal status --> no callbackAddress
• TransferTerminationMessage --> terminal status --> no callbackAddress

Required fixes

Fix No. 1

ContractOfferMessage and ContractAgreementMessage are sent by the provider. Thus, they do not require a callbackAddress. Should be removed.

Fix No. 2

If we go with option a) (callbackAddress on every consumer message), we would need to make the following changes:

• Add optional callbackAddress to ContractNegotiationEventMessage
• Add optional callbackAddress to TransferSuspensionMessage

If we go with option b) (callbackAddress on first consumer message), we would not need to make any further changes.

[mkollenstart]

Given that a provider can initiate a negotiation process, I would be in favor of having a callbackAddress in that scenario. As it would otherwise require the consumer to first do the discovery of the relevant endpoint. The only drawback is that when a provider sends a counter offer, the consumer already knows the address it should use.

Having a callback adress on all messages that expect an answer would make things easier to implement. Although it may be redundant information. And it also might introduce issues when the callback address changes within one process and the remote party has to decide whether it uses the first callback address or the last one.

I'm leaning towards Fix no. 1, with the addition that for a ContractOfferMessage the callback address should be optional. Or that either consumerPid (i.e. a counter offer) or callbackAddress (i.e. a provider initiated CN) must be provided.

[jimmarino]

I think we agreed on both options in the sense that the first message sent by a consumer must have a CBA and each subsequent request as well:

a) Every message that is sent by the consumer must provide a callback address.
b) The first message that is sent by the consumer must provide a callback address.

We also said the provider should use the most recent CBA.

I'm for Fix 1:

• ContractRequestMessage --> sent by C --> mandatory callbackAddress
• ContractOfferMessage --> sent by P --> mandatory callbackAddress, used as the provider address
• TransferRequestMessage --> sent by C --> mandatory callbackAddress
• Every other message, no callback

Doing this would restrict dynamicity, but in practice, it may not be an issue. For example, in the current approach, a consumer can migrate its endpoint address only when there are no outstanding provider responses. That is a very small window, if one at all. In the end, there may not be much difference with pinning the cba to the first consumer request message. A consumer must honor all CBAs until the associated processes are completed. To get true dynamicity, we would need to provide a way for a party to update its CBA. I don't think we need this complexity.

I don't think pinning the CBA would make implementation more difficult because CBAs need to be persisted anyway. Pinning in this way would also eliminate questions such as whether the provider needs to provide a CBA for messages other than contract offers, as each party has a single address for the duration of the process.

[juliapampus]

Resolved with #155