Unilateral approval sent for IIA v6 with IIAS-Approval v1 => still valid for iias-approval v2 if approved copy is not compliant with v7?

[LDeprez]

Given a non mutual agreed agreement Partner A has copy A1 compliant to v6 specs, but not compliant to v7 specs Partner B has copy B1 Both are mapped 1 on 1. Both use iias v6 and iias-approval v1

Partner B did approve copy A1 in its local system and partner A did call the iias-approval-1% endpoint of partner B for A1 without problems. For copy B1: case 1: Partner A did not approve yet copy B1 in its local system case 2: Partner A did approve copy B1 in its local system but did not send a iias-approval-cnr with httpsstatuscode 200 response yet case 3: Partner A did approve B1 in its local system, sent an iias-approval-cnr but partner B did not call the iias-approval-1% endpoint of partner A for B1

Then both partners switch to iias v7 and iias-approval-2%

What should be the response of partner B when it receives a iias-approval-v1 request from partner A for A1? Does it A1 remain approved? Or is the approval not valid anymore as there was no mutual agreement and as A1 does not comply to the specificatios of v7 and should partner A be forced to create a new version of their copy compliant to v7? And: is there a difference between cases 1, 2 and 3?

[janinamincer-daszkiewicz]

Is there a difference between cases 1, 2 and 3?

IIA is mutually approved if both partners keep the approval hash and the snapshot of the other partner's copy of this IIA.

A knows that this condition is fulfilled on their side. A can only claim that the condition is fulfilled on B's side after B retrieves the approval from A (after the succesful IIA Approval request).

In neither of the listed cases (1, 2, 3) this request has been made.

What should be the response of partner B when it receives a iias-approval-v1 request from partner A for A1?

After the network switches from v6 to v7, B does not expose IIA Approval API in version 1.

Does it A1 remain approved?

Yes, there is no way to un-approve IIA which has once been approved

Or is the approval not valid any more as there was no mutual agreement and as A1 does not comply to the specifications of v7 and should partner A be forced to create a new version of their copy compliant to v7?

A1 remains approved however it cannot be exposed in a network if it is not mutually approved and is not compliant with V7. A has to modify it before sending it via the network.

This is because specification defines not-yet-defined in the following way:

If given MUST be set to "true". Flags an element value as not yet defined and MAY be set only for mutually approved agreements that have been approved in the old IIA API version and have not been modified since, and MUST NOT be set otherwise.

[LDeprez]

OK, clear, but additional question: Partner B's approval of A1 remains, but partner A is obligued to make a new version of his copy.

What if partner A approves B1 without making a new copy A2 ? -scenario 1- A1 has missing required fields => v7 response will be rejected, but same iia-hash is already approved by partner A -scenario 2- A1 has not-yet-defined fields while there is no mutual agreement yet (in the perspective of partner B) -scenario 3- new version of A1 is not ready yet and A1 is not exposed in the network => partner B considers A1 as deleted and partner A has to create a new local copy with another iia-id.

Can partner B consider the agreement as mutual agreed in scenario's 1 and 2 ? Or must partner B get A1 in v7 and check if 'valid-for-approval' = true (for scenario 1) and check if the not-yet-defined is not used incorrectly (for scenario 2)? I assume partner B can consider the agreement as mutual agreed as it is the responsibility of partner A to be compliant with the specifications and to create a new A2 before approving B1?

[janinamincer-daszkiewicz]

I assume that we are in the situation when the network has been switched to v7. As I have already written in the previous post:

A1 remains approved however it cannot be exposed in a network if it is not mutually approved and is not compliant with V7. A has to modify it before sending it via the network.

That means that B is not able to get A1 from A - any IIA get for A1 should generate an error. A1 cannot disappear from the network as that would mean deletion.

B1 is probably also not compliant with v7 - the same argument applies which means that A will not be able to approve B1.

The only correct scenario is that each partner makes changes to own copy before switch or responses to IIA get with error after switch (USOS generates 500).