Open pleys opened 3 years ago
You are right. Do you think that the specification should clearly mention this case?
I leave it up to you and colleagues with a more technical background to further discuss this: @georgschermann @mpuzar @kamil-olszewski-uw @vmmaSigmaaie @BavoNootaert ...
@pleys Why is this so? The receiving hei can only send an update for which it has the get request with the same id and if the receiving hei approves this LA, than it has a valid version at the time of this id, and if this version was approved by the other 2 parties, than the receiving hei has a valid approved version of the LA, no matter if there is a more recent version.
Even when the sending hei rejects the approve-update request with a concurrent modification error, I would still conisder this version at the receiving hei as valid and approved. I would find it problematic if the sending hei could "revoke" their approval by issuing a new version of an approved LA and rejecting the approval of the receiving hei.
We will handle the approved-by information on the LA like signatures, so if one has a version with all three approvals, it is an approved version, or am I missing something?
@janinamincer-daszkiewicz the documentation already is very clear on this: The client (the receiving HEI) is REQUIRED to expect these HTTP 409 (Conflict) responses, and deal with them "appropriately". Usually this means that you need to fetch the fresh data from the server and ask your user to repeat his action once again.
Given the following scenario:
=> I would suggest the following:
If the sending hei should process the lateste update request, it should mark a depreciated version of the LA as approved and add this mutual agreement in the subsequent Get responses (latest approval). This adds complexity without a morevalue as endpoints would be forced to store all versions that were not signed by the receiving HEI, to be able to listen to any update approvals for them.
In the following scenario, it is even more complex:
@LDeprez I can't see these complications here. Each proposal has its own hash sent in get response. Sending HEI correctly handles only those update requests that contain hash of newest proposal. If there is a different hash in the update (for an older proposal, for example), sending HEI will send answer 409 (conflict).
The LA may only be considered as approved by the receiving HEI if it receives a GET response with the LA in so not when the receiving HEI sends an update approval because it is possible that the receiving HEI answers on a LA that is not the latest version from the sending HEI