Deleting IIAs which have not been approved by both partners

[janinamincer-daszkiewicz]

Infrastructure Forum meeting 2022-12-14.

Functionality to delete IIA which have not been approved by both partners and share information about deletion with a partner has been voted with the following results:

• Yes, let's vote: 4 providers
• No, don't vote, need more time: 13 providers

(the results of voting are summarised in an Excel file uploaded to the IF shared drive).

We will continue the discussion in this issue to reach a final solution no later than January 18, 2023 (the next IF meeting).

[janinamincer-daszkiewicz]

In other GitHub issues some providers were strongly against the option to delete IIA without keeping information about deletion, because that would be confusing for the partners and would not allow us to distinguish a deliberate deletion of an object from an error.

Under this assumption the following delete functionality has been proposed during the meeting:

• One can only delete IIA which has not yet been approved by both partners.
• Partner sends IIA CNR after deleting IIA.
• Partners should keep iia-ids of deleted IIAs „for ever” (to be decided what that means in practice, may be the end of the current Erasmus+ programme).
• In response to IIA get we send the existing IIAs (may be none) and the list of ids of deleted IIAs (if not empty).
• In response to IIA index we send the ids of existing IIAs (may be empty) and the list of ids of deleted IIAs (if not empty).
• List of ids of deleted iias is optional.
• We add parameter to IIA index and IIA get requests: include-deleted (optional) default YES; if given and value is NO, then the server should not send deleted IIAs.

Examples:

<iias-index-response>
<iia-id>0f7a5682-faf7-49a7-9cc7-ec486c49a281</iia-id>
<iia-id>238de7f9-c887-45ae-9853-eb0c82506e5b</iia-id>
<iia-deleted-ids>
<iia-id>36bb0e3f-39ad-4f26-b2cb-41f707e7e297</iia-id>
<iia-id>2674e93f-28cd-4f26-c8bc-2137x8e7i296</iia-id>
</iia-deleted-ids>
</iias-index-response>

<iias-get-response>
<iia>IIA_1</iia-id>
<iia>IIA_2</iia-id>
<iia-deleted-ids>
<iia-id>36bb0e3f-39ad-4f26-b2cb-41f707e7e297</iia-id>
<iia-id>2674e93f-28cd-4f26-b2cb-41f707e7e297</iia-id>
</iia-deleted-ids>
</iias-get-response>

Pros: no need to keep deleted IIA in any form, just IIA-id. If we would decide to keep a deletion flag, the object with a flag would have to be stored.
Cons: IIA-ids of deleted object should be stored „for ever”.

[janinamincer-daszkiewicz]

Mandatory business requirements: "It should be possible to delete an agreement that was never approved by both parties and to notify the partner about it."

That means that we have two options:

1. Simpler, but may be misleading: A deletes IIA, A sends IIA CNR to B, B gets IIA, but there is already no IIA with that id (it has been permanently removed).
2. More complex but situation is fully clear: A can delete IIA, but A has to keep ids of deleted IIAs 'forever', as described in Deleting IIAs which have not been approved by both partners #98 (comment).

If we choose (1), we cannot agree to 'hiding' described in #100.

[umesh-qs]

@janinamincer-daszkiewicz
Not sure why we are changing the IIA specs, when this can be handled in a more easier way using IIA Approval API
#97

[janinamincer-daszkiewicz]

Not sure why we are changing the IIA specs, when this can be handled in a more easier way using IIA Approval API
#97

You suggest to use Approval to inform partner about deletion? Deletion is on a level of IIA, not on a level of approval.

[umesh-qs]

Not sure why we are changing the IIA specs, when this can be handled in a more easier way using IIA Approval API
#97

You suggest to use Approval to inform partner about deletion? Deletion is on a level of IIA, not on a level of approval.

Yes, modify that API to include optional status flag that will say that IIA is deleted. Also add optional comments field. This will be faster to implement and will cover all the cases.

[janinamincer-daszkiewicz]

I do not see there clear support for the comments.

Anyway, I was told that we have to first wait for the opinion of BPOs/DEG EAC and other bodies to decide if the users want/need comments. When we have their opinion, we will eventually come back to discussion on a technical solution.

[umesh-qs]

I do not see there clear support for the comments.

Anyway, I was told that we have to first wait for the opinion of BPOs/DEG EAC and other bodies to decide if the users want/need comments. When we have their opinion, we will eventually come back to discussion on a technical solution.

may be not many see it. But this can be proposed in the IF meeting next week

[janinamincer-daszkiewicz]

Please, describe here how the deletion scenario will look like. Step by step.

[umesh-qs]

[Belenchusky]

I´m sorry but I dont understand this:

"In response to IIA get we send the existing IIAs (may be none) and the list of ids of deleted IIAs (if not empty)."

If I want to remove an IIA, I send a CNR and when the partner does a GET to see the changes, I don't understand that the response involves more IIAs than requested. The partner only needs a valid response to know that the IIA has been deleted, for example status ='deleted' or somtehing like that.

[janinamincer-daszkiewicz]

Please, show the whole scenario, i.e. the sequence of steps. Let's start from HEI A which wants to delete the Agreement idA.

[janinamincer-daszkiewicz]

"In response to IIA get we send the existing IIAs (may be none) and the list of ids of deleted IIAs (if not empty)."

In IIA get you may ask for more than one, the more general case is descibed here.
Also in Index you send more than one.

[Belenchusky]

Sorry , I didn´t know. Then, I get it.

[umesh-qs]

Please, show the whole scenario, i.e. the sequence of steps. Let's start from HEI A which wants to delete the Agreement idA.

[skishk]

Hello to everyone.

I'm so sorry but I didn't understand why we need to explicit Deleted IIA if they are not approved?!

Example of scenario:

1. HEI A and B see each other IIA , no one approved the partner IIA.
2. HEI B decide to delete his IIA for any reason.
3. HEI A before approve MUST call IIA-GET, and in the response there is no IIA. HEI A flag this IIA ad deleted or not more exposed, or HEI can delete the copy of IIA of HEI B. if HEI B expose a new IIA , HEI A can GET the new IIA.

some one can explain to me why is that not applicable? no one approved the IIA of the other partner... so I can't understand where is the problem to delete IIA!? i'm sorry but probably it is my limit.

thanks in advance

[umesh-qs]

Hi @skishk
Point 3 when the IIA is deleted does not tell that the IIA is deleted or there is any other problem because of which IIA is not returned. We need a non ambiguous way to find deleted IIAs.

[skishk]

Hi @skishk Point 3 when the IIA is deleted does not tell that the IIA is deleted or there is any other problem because of which IIA is not returned. We need a non ambiguous way to find deleted IIAs.

Thank you @umesh-qs ! 👍

ok so it's just to be sure that is deleted.

but which difference do we have if it is deleted or the partner system have a temporary issue (no response, http500 response or 400 etc)? in both situation we can not approve it ☺️ .

if it is only a temporary issue when you will try again to approve it, and we call IIA-GET before approving, we will receive a good response so we can approve it.

if the partner deleted it i think he will have 2 way:

1. deleted it because he does't want to have an agreement with me (and i think he will comunicate that in advance by email);
2. partner will expose a new agreement instead of the one deleted.

last option is the the partner wrongly deleted it, and like every not clear situation he will send an email ☺️ .

comunicate in the approval that we deleted an IIA is not the right suitable because the approval API is made (like the name say) to approve not to comunicate other things about IIA.

in the same way having a history of all deleted IIA i think is not useful and we must think that communication (in any way) of deleted IIA can fail for any reason so we do not solve the situation that we "want" to know if it is deleted.

Hope I was helpful

[umesh-qs]

Hi @skishk
Delete and approval are 2 separate process. I was only suggesting use the same API for both the processes for technical ease of implementation.

Sending explicit delete flag in the API response will tell if the IIA is deleted. Why do you think it will not solve the delete problem?

[skishk]

Hi @skishk Delete and approval are 2 separate process. I was only suggesting use the same API for both the processes for technical ease of implementation.

Sending explicit delete flag in the API response will tell if the IIA is deleted. Why do you think it will not solve the delete problem?

I agree with you that are 2 separate process but one depend from the other, if I understand well, I can't delete my IIA if partner approved it (so i need to call APPROVAL API GET to be sure it is not approved) and the other way before approving IIA i need to call IIA-GET to be sure that already exist and not changed(checking contidionHash, but some Partner/Provider don't check all these things 😅 ).

probably better way is to add a flag in IIA API response : true/false that could contain only thin information for IIA requested because probably there are providers that execute a hard delete and not only logical.

I think we must solve all problems that we have already in production and then with a stable situation adding secondary process like deleting. this is just my opinion 😄

thanks @umesh-qs for comparison 😄

[umesh-qs]

@skishk
In my proposal above approval and deletion are not linked. I am approving partners IIA with original spec.
Also I am able to delete my IIA with comments and communicate to my partners using the same API with minor changes.

Yes individual system can check if partner is deleting their IIA even when the IIA process is completed (both partners have approved). That check should be done even if DELETE is somehow handled via IIA GET. But how will this be handled when the IIA is already hard deleted.

PS: As of now there is no such limitation on not deleting or changing approved IIA.

[janinamincer-daszkiewicz]

@umesh-qs

As I understand the given 'deletion scenario' is not 'one time shot'? HEI A needs to keep identifiers of the deleted IIAs and share them in future IIA get and IIA index? So why do we need IIA Approval for sharing this information?

[skishk]

But how will this be handled when the IIA is already hard deleted.

When it is already hard deleted and partner send to you IIA-GET you will answer with empty response because you didn’t find any IIA (with iia-id given) in your system .

PS: As of now there is no such limitation on not deleting or changing approved IIA.

i agree with you that now we have no limits on operation and process and that is not helpful.

[umesh-qs]

But how will this be handled when the IIA is already hard deleted.

When it is already hard deleted and partner send to you IIA-GET you will answer with empty response because you didn’t find any IIA (with iia-id given) in your system .

I would again insist on getting a concrete proof of delete and not based on assumption. You never know the reason for not getting the IIA details. DELETE response should not be ambiguous.

PS: As of now there is no such limitation on not deleting or changing approved IIA.

i agree with you that now we have no limits on operation and process and that is not helpful.

[umesh-qs]

@umesh-qs

As I understand the given 'deletion scenario' is not 'one time shot'? HEI A needs to keep identifiers of the deleted IIAs and share them in future IIA get and IIA index? So why do we need IIA Approval for sharing this information?

@janinamincer-daszkiewicz I am suggesting approval API (or some other name) to be made bi-directional to get status for self and partner IIA.
As of now deleted IIAs via GET API will give empty response. That is not a conclusive proof of DELETE. But if all providers are ok with this then we can treat empty IIA response as IIA being deleted.

[janinamincer-daszkiewicz]

That is not a conclusive proof of DELETE.

I would again insist on getting a concrete proof of delete and not based on assumption. You never know the reason for not getting the IIA details. DELETE response should not be ambiguous.

Isn't this contradictory?

[umesh-qs]

That is not a conclusive proof of DELETE.

I would again insist on getting a concrete proof of delete and not based on assumption. You never know the reason for not getting the IIA details. DELETE response should not be ambiguous.

Isn't this contradictory?

No it is not. Best option is to have API design that gives extract status of the IIA without any ambiguity.
But, for the sake of simplicity (so that no API change is needed), I would rather treat empty response as network problem and show it to my clients that it is currently not available in network. My clients may choose to ignore it, if it is an old IIA that is not important anymore, or may choose to contact to partner on why their IIA is not available.

[janinamincer-daszkiewicz]

In your proposal API change is needed and DELETE is not a conclusive proof. We have to response with the information about deletion in the IIA Approval response but give empty response in IIA. That would be misleading.

[umesh-qs]

If I already know that the IIA is DELETED, they why would I call IIA GET API?

[janinamincer-daszkiewicz]

It can happen anytime. Some providers still call index in a background just to get the most fresh versions of IIAs.

[skishk]

5. "If object A.iia_id is deleted by A, should B still keep the IIA Approval for A.iia_id?"
In our opinion NOT. There is no such business need.
What B does in this step is not UNAPPROVAL, B DELETEs an object "Approval of A.iia_id" because it is not needed, because A.iia_id does not exist.

thank you @janinamincer-daszkiewicz now is more clear.

but how could B send a Approval CNR of something not existing (IIA-ID of partner A who deleted his Agreement) ? and unmapped too...
as you said is not necessary for partner B so it is his own business to manage this information. Partner A has already deleted everything of his IIA. so i think no more action is needed.
i said that just to not introduce others changes to other APIs... because that means we need more time for all changes.

[janinamincer-daszkiewicz]

@skishk I understand your point, we were considering such option internally.
If we agree that the IIA Approval should be deleted, the decision to make is - what should happen next?
Because specs says that "when you delete, you should send CNR", this is what we propose.
In that way B makes it clear for A that IIA Approval for A.iia_id is also gone. May be for some reason A still keeps his copy in a local system but does not expose it in the network? May be he also keeps IIA Approval once obtained from B? By deleting and sending IIA APProval CNR B give a clear message that his previous Approval does not exist on his side.

We also want to limit changes in specs, this is why we want to discuss all possible scenarious and decide what is better from the implementation point of view.

[pargentieri]

As I understand, what needs explanation is why in Scenario 6 (Create, unilateral approval, unilateral delete (before mutual approval)) we suggest that the approval of the deleted object should also be deleted. I will try to give our arguments step by step.

1. The overarching assumption regarding CNRs is that we always have to send CNR when the object is changed.
2. In this scenario we deal with two objects: IIA and IIA Approval.
3. Partner A delets IIA, which has been earlier approved by partner B.
4. In step 19 partner B, after getting an empty response to IIA GET, knows that the object iia_id does not exist.
5. Step 20 - now the question :
   "If object A.iia_id is deleted by A, should B still keep the IIA Approval for A.iia_id?"
   In our opinion NOT. There is no such business need.
   What B does in this step is not UNAPPROVAL, B DELETEs an object "Approval of A.iia_id" because it is not needed, because A.iia_id does not exist.
   If you claim that it is not allowed by specification to send IIA Approval CNR for unmapped object (B still keeps his copy), we may add clarification to the specs that this restriction holds in case of an object existing on both sides, not an object existing on one side.
6. If B deletes IIA Approval, B must send IIA Approval CNR, because spec says that whenever you change (or delete) an object CNR must be sent.
7. A is allowed to send IIA Approval request for A.iia_id, because everybody is allowed to ask the partner for non-existing object. A is not allowed to expose A.iia_id to GET nor INDEX on HIS side, asking is not forbidden.

Hi,
I still have some doubts.You Wrote "If B deletes IIA Approval", so the DELETE of the IIA approval isn't mandatory, right?
In my opinion, removing the approval on a deleted agreement doesn't make sense. But even if you were to do it, what would be the purpose of sending a CNR to the partner who has already canceled the agreement?

[skishk]

@skishk I understand your point, we were considering such option internally. If we agree that the IIA Approval should be deleted, the decision to make is - what should happen next? Because specs says that "when you delete, you should send CNR", this is what we propose. In that way B makes it clear for A that IIA Approval for A.iia_id is also gone. May be for some reason A still keeps his copy in a local system but does not expose it in the network? May be he also keeps IIA Approval once obtained from B? By deleting and sending IIA APProval CNR B give a clear message that his previous Approval does not exist on his side.

We also want to limit changes in specs, this is why we want to discuss all possible scenarious and decide what is better from the implementation point of view.

partner A is the one is deleting IIA not B.
so if it is like that ok! that means B have not to send Approval CNR, if he wants ok but not needed.
A has already deleted his IIA and the approval and everything is linked to the IIA-ID deleted.
for partner B the IIA-ID of A now is not existing so he can't send any CNR with this deleted IIA-ID.

now is more clear , thank you @janinamincer-daszkiewicz

[janinamincer-daszkiewicz]

I still have some doubts.You Wrote "If B deletes IIA Approval", so the DELETE of the IIA approval isn't mandatory, right?

My bad English, sorry. In my opinion IIA Approval should be deleted from the network, because it would be misleading and would have no business value to keep the Approval for the object which des not exist.

In my opinion, removing the approval on a deleted agreement doesn't make sense.

Should B keep it? Forever? A is allowed to delete IIA with A.iia_id, and B is not allowed to delete IIA Approval with A.iia_id?

But even if you were to do it, what would be the purpose of sending a CNR to the partner who has already canceled the agreement?

I tried to explain above. Because when I delete the object, any object, I MUST send CNR.

[janinamincer-daszkiewicz]

partner A is the one is deleting IIA not B.

Right

so if it is like that ok! that means B have not to send Approval CNR, if he wants ok but not needed.

It depends. If we decide that B may keep IIA Approval, he need not send IIA Approval CNR.
Should we leave it for the local system if they want to keep approvals for the objects deleted by the partners?

A has already deleted his IIA and the approval and everything is linked to the IIA-ID deleted.

Right

for partner B the IIA-ID of A now is not existing so he can't send any CNR with this deleted IIA-ID.

B still keeps IIA Approval object with A.iia_id, so he can send IIA Approval CNR

[pargentieri]

I still have some doubts.You Wrote "If B deletes IIA Approval", so the DELETE of the IIA approval isn't mandatory, right?

My bad English, sorry. In my opinion IIA Approval should be deleted from the network, because it would be misleading and would have no business value to keep the Approval for the object which des not exist.

In my opinion, removing the approval on a deleted agreement doesn't make sense.

Should B keep it? Forever? A is allowed to delete IIA with A.iia_id, and B is not allowed to delete IIA Approval with A.iia_id?

But even if you were to do it, what would be the purpose of sending a CNR to the partner who has already canceled the agreement?

I tried to explain above. Because when I delete the object, any object, I MUST send CNR.

[pargentieri]

I still have some doubts.You Wrote "If B deletes IIA Approval", so the DELETE of the IIA approval isn't mandatory, right?

My bad English, sorry. In my opinion IIA Approval should be deleted from the network, because it would be misleading and would have no business value to keep the Approval for the object which des not exist.

In my opinion, removing the approval on a deleted agreement doesn't make sense.

Should B keep it? Forever? A is allowed to delete IIA with A.iia_id, and B is not allowed to delete IIA Approval with A.iia_id?

But even if you were to do it, what would be the purpose of sending a CNR to the partner who has already canceled the agreement?

I tried to explain above. Because when I delete the object, any object, I MUST send CNR.

"Should B keep it? Forever? A is allowed to delete IIA with A.iia_id, and B is not allowed to delete IIA Approval with A.iia_id?"
No, he should simply be able to do what he wants in his system. Why "B is not allowed to delete IIA Approval"? I said it's not mandatory, not that they can't do it, but simply I don't want to do it.
"In my opinion IIA Approval should be deleted from the network" Yes, in fact, if I don't delete it, it will only stay in my system.I have no intention of sharing it, so for EWP, it wouldn't exist. What is the problem?

[demilatof]

I'm not stupid, I can read; you're insisting in bending the specifications according to your needs (or to some providers' needs).
You cannot add the exception you are suggesting, there are to many infringes of the specification.

5. Step 20 - now the question :
   "If object A.iia_id is deleted by A, should B still keep the IIA Approval for A.iia_id?"
   In our opinion NOT. There is no such business need.

It's outside of A's interest; it can never reach that information, it's inside B's system.

   What B does in this step is not UNAPPROVAL, B DELETEs an object "Approval of A.iia_id" because it is not needed, because A.iia_id does not exist.

You're trying again to intrude my system; you cannot compel me to delete anything in my system.
Anyway there is no object called Approval, this is your invention.
The approval is a status that B communicates to A.
If you delete what you call "object", you unapprove.
Please, stop playing with the words

It's not possible to delete the approval (object, if you like better), it was never postulated.
Otherwise, I can delete the approval (object) after the mutual approval and then?
You have never explained the bounds of the deletion of an approval, you're opening a dangerous way.

   If you claim that it is not allowed by specification to send IIA Approval CNR for unmapped object (B still keeps his copy), we may add clarification to the specs that this restriction holds in case of an object existing on both sides, not an object existing on one side.

I don't claim anything, it's written in the specifications, I hope that you sometimes read them.
But this is not the only specification infringed: to send the CNR B MUST previously perform an IIA Get, but the delete specification forbids to use the A's IIA ID in any endpoint (not only on A side), therefore, forbids B to call A's IIA Get and therefore he cannot send Approval CNR.

6. If B deletes IIA Approval, B must send IIA Approval CNR, because spec says that whenever you change (or delete) an object CNR must be sent.

The question is: why you take care of that B deletes IIA Approval?
You force B to do something that is not interesting for A (otherwise, please explain) that can be fulfilled only infringing or bending specifications.

7. A is allowed to send IIA Approval request for A.iia_id, because everybody is allowed to ask the partner for non-existing object. A is not allowed to expose A.iia_id to GET nor INDEX on HIS side, asking is not forbidden.

No, this is not true, you're bending again the specifications.
The Approval specification says

Clients and servers MUST NOT use IIA Approval API for agreements that:

are not properly mapped (do not provide partner agreement ID)

Why you want to change even this specification?
I add that when we discussed with @umesh-qs you told me that I have to unmap because A's IIA ID cannot be present even in my IIA, now you come back to "HIS side"? Interesting.
And you, just now, are saying:

everybody is allowed to ask the partner for non-existing object.

NO! It's forbidden by the rules YOU and your partners have written:

Please stop infringing the specifications...

[demilatof]

By deleting and sending IIA APProval CNR B give a clear message that his previous Approval does not exist on his side.

You have still to explain why you want to know this fact, since that A cannot never ask B for the approval because:

• the specifications forbid it to use "IIA Approval API for agreements that are not properly mapped (do not provide partner agreement ID)"
• the specifications forbid it to re-use the deleted IIA ID: "Identifiers of the deleted objects MUST NOT be reused for new IIAs."

[demilatof]

Should B keep it? Forever? A is allowed to delete IIA with A.iia_id, and B is not allowed to delete IIA Approval with A.iia_id?

Who said that?
There is a huge difference between "B can delete the IIA Approval with A.iia_id, if it wants" and "B MUST delete..."

[janinamincer-daszkiewicz]

"In my opinion IIA Approval should be deleted from the network" Yes, in fact, if I don't delete it, it will only stay in my system.I have no intention of sharing it, so for EWP, it wouldn't exist. What is the problem?

It will stay in your system, OK.
Will it be visible in the Network?
If no, that it means that you delete it from the network, and in that case you should send CNR.
If yes, the we come back to my question "Should we leave it for the local system if they want to keep approvals for the objects deleted by the partners?"

[demilatof]

B still keeps IIA Approval object with A.iia_id, so he can send IIA Approval CNR

No, he cannot, please read the specifications: before sending IIA Approval CNR, B MUST call IIA Get, he receives nothing, and this prevents him from sending IIA Approval CNR.
If he sends it anyway, he infringes the rules at this point.

[janinamincer-daszkiewicz]

but the delete specification forbids to use the A's IIA ID in any endpoint (not only on A side),

That's not true.

[demilatof]

t will stay in your system, OK.
Will it be visible in the Network?
If no, that it means that you delete it from the network, and in that case you should send CNR.

No, you don't catch the point: it's not visible in the network because no one has anymore title to ask for it, but it exists.
A cannot call the IIA Approval, B cannot send the IIA Approval CNR.
But the approval is still there.

If yes, the we come back to my question "Should we leave it for the local system if they want to keep approvals for the objects deleted by the partners?"

Of course, because it's up to B deleting it or not; and even if B deletes it, he has not to send the Approval CNR, because the specifications (read them, please) already state this exception:

• This API allows HEIs to approve agreements sent by their partners in the Interinstitutional Agreements API
• Clients and servers MUST NOT use IIA Approval CNR API for agreements that are not properly mapped (do not provide partner agreement ID

The approval is to approve, not to remove an approve.
If a condition is not satisfied (agreements that are not properly mapped) I can, better, I MUST not send the CNR.

[demilatof]

but the delete specification forbids to use the A's IIA ID in any endpoint (not only on A side),

That's not true.

Please show me the point that limits the sentence to "HIS side".

Once I realized that A's IIA Id has been deleted (the first time I call IIA Get) I must never use it.
But even if I use it, I don't receive any IIA and then I cannot send an IIA CNR.

[skishk]

B still keeps IIA Approval object with A.iia_id, so he can send IIA Approval CNR

you assume it.

B could delete everything in his system so have no ID of partner A, who know? it is his business.

but ok we assume B has it in his system... send to A an APPROVE CNR with the IIA-ID of Deleted Agreement of A, how A could find his agreement and set it as not approved?! that is the strangest thing in my opinion. Partner A deleted the agreement... the approval and everything is linked to it.
for him is an error because he will not find any agreement with that ID.

in conclusion i just to think well in all these changes if they are really needed or not because it is already possibile to manage all this scenario in production, so why adding all these steps for something very simple?

hope it could be helpful for the network

[janinamincer-daszkiewicz]

@skishk Let's look on it from the slightly different angle. Providers decided that B should remove mapping, so B will not keep A.iia_id with his copy.
Let's assume that after some time A sends IIA Approval request with A.iia_id (he is a client, not a server exposing forbidden identifier). What will B send in response?

[skishk]

@skishk Let's look on it from the slightly different angle. Providers decided that B should remove mapping, so B will not keep A.iia_id with his copy.
Let's assume that after some time A sends IIA Approval request with A.iia_id (he is a client, not a server exposing forbidden identifier). What will B send in response?

empty response because IIA-ID of partner A not exist. (he deleted it)

but how Partner A (who deleted his Agreement) could send IIA Approval request of something deleted? i missing this point i'm sorry my fault...

[demilatof]

Let's assume that after some time A sends IIA Approval request with A.iia_id (he is a client, not a server exposing forbidden identifier).

Again?
A is against the rules!
You should not take care of the B behavior, but of A behavior!

If A's IIA is deleted, it cannot have any mapping, therefore A is forbidden by specification to send IIA Approval request!

[janinamincer-daszkiewicz]

If A's IIA is deleted, it cannot have any mapping, therefore A is forbidden by specification to send IIA Approval request!

B is not allowed to send IIA Approval CNR for the object which is not properly mapped. Asking questions is allowed.

[janinamincer-daszkiewicz]

but how Partner A (who deleted his Agreement) could send IIA Approval request of something deleted? i missing this point i'm sorry my fault...

Because anybody can ask about any non-existing object and should get an empty response in such case.

[demilatof]

B is not allowed to send IIA Approval CNR for the object which is not properly mapped. Asking questions is allowed.

No, please read the specification: "Client and Server"!!
Who asks is the client, it was as you say, the specifications would not use the term "client".

And it is fully reasonable: as @skishk said, why some should overload my system with useless request?
Would you be happy if I started a loop:

for (int iiaId=0; iiaId<1000000000000000; iiaId++) sendApprovalRequestToVarsavia(iiaId);

I fully know that I have nothing to be approved, I must not bother the partner with an IIA Approval request

[demilatof]

Because anybody can ask about any non-existing object and should get an empty response in such case.

Even if I accept your request (against the specification), because you said that "anybody can ask about any non-existing object", as a server I'm forbidden by the specification to use the IIA Approval for IIAs that "are not properly mapped (do not provide partner agreement ID)",
Then I cannot use the Approval API because your IIA, that I know has been deleted, is no properly mapped.

Therefore, your request falls under the General error handling rules:

If the client it authenticated, but doesn't have access to the resource, then servers MUST respond with the HTTP 4xx status (HTTP 403 preferred), and the response SHOULD contain an XML content with the root element, as defined in the common-types.xsd file

This means that if someone hopes to use my system to trigger the cleaning in its system, could not find any help in calling my Approval API.
I'll never tell him that his own deleted IIA has been approved or not, neither I'll ever delete my previous approval.
I'll tell him that he doesn't have access to the resource because the IIA he is asking for is not properly mapped.

[skishk]

Because anybody can ask about any non-existing object and should get an empty response in such case.

so anybody could leave any non-existing ID in his mapping 😆 i'm joking.

i'm just afraid of the way we are taking for the new specification...

[mkurzydlowski]

@demilatof, the fragment you are quoting was introduced to force partners to create the mapping before approving IIAs and I believe that you know it.

It wasn't meant to block the client from sending a request to the Approval API after an approval has already been created.

Should removing a mapping from an IIA block the partner from accessing an already published approval? That would be absurd.

Let's not forget what the intentions were, because that leads to discussions going the wrong direction. What we should do is to correct the specification so it meets the intentions that we had when introducing such rules. That way we make the specification more bulletproof without changing what we already agreed on.

[demilatof]

@demilatof, the fragment you are quoting was introduced to force partners to create the mapping before approving IIAs and I believe that you know it.

It wasn't meant to block the client from sending a request to the Approval API after an approval has already been created.

It doesn't matter what I know. What matters is what is written, so that whoever will join the project, at any time, can have a specification that describes what he/she has to do to obtain the same result of the others.
Therefore, your interpretation is a nonsense

You're mixing the API with its response, or you're not able to write specifications.
In both of the cases we have a serious problem because if you and @janinamincer-daszkiewicz insist to read specifications in this way, we have to review the whole EWP project.

If you write:

Clients and servers MUST NOT use IIA Approval API for agreements that are not properly mapped (do not provide partner agreement ID),

You mean that the API cannot be used; it extremely clear and simple.
If you want that it can be called in anytime, you have to write something different:

Servers cannot consider as approved, agreements that are not properly mapped (do not provide partner agreement ID)

The above sentence means that I can receive an Approval API at any time and ignore an IIA ID if the corresponding IIA has not a correct mapping.
But now it's late to change this point.

Should removing a mapping from an IIA block the partner from accessing an already published approval? That would be absurd.

Please explain

Let's not forget what the intentions were, because that leads to discussions going the wrong direction. What we should do is to correct the specification so it meets the intentions that we had when introducing such rules. That way we make the specification more bulletproof without changing what we already agreed on.

No, you're putting in a mess the whole project, be careful!
If we accept that an approval can be retired, we have several issues:

1. When? Always, before mutual approvals?
2. What happens? All approvals are voided or only the last one?
3. If only the last one, how can I specify what is the last one for the server side?
4. If all, what happens to a mutually approved IIAs?

Please remember that never, and I stress NEVER, has been considered as possibly the removal of an approval.
Even when we discussed about the un-mapping we said that "Change of the mapping is treated as any other change" and this means that there is no need to remove an approval.

[mkurzydlowski]

It doesn't matter what I know. What matters is what is written, so that whoever will join the project, at any time, can have a specification that describes what he/she has to do to obtain the same result of the others.
Therefore, your interpretation is a nonsense

That's why we need to correct this sentence. I'm just reminding what we agreed on and what was the purpose of this rule. There is no need to be aggressive. I'm not stating that there is no place for corrections.

Please explain

Allowing people to block others to be able to send a request to an endpoint by unmapping an IIA is not what was proposed or agreed on. We just wanted to block people from creating an approval and sending a CNR before an IIA is mapped. We will correct this rule so this is clear.

If we accept that an approval can be retired, we have several issues

On the technical level any EWP entity may go away and this needs to be handled by the client. On the business level entity removal should take place only in particular cases and needs to obey rules like:
https://github.com/erasmus-without-paper/ewp-specs-architecture#referential-integrity

We are not saying that an approval may be removed at any moment. We are discussing if on a business level we expect it to be removed when an IIA is removed.

[demilatof]

You forget that once I approved, I approved and I cannot remove the approval.
Never.
This is why the approval response has the hash-code: I say that I approved your particular version.
Have you changed it (different hash code) or have you it no more (no hash code)?
It's up to you to do what do you want in your system, I cannot attest the false; the previous version was approved by me.

What your trying to introduce is useful only for someone

[janinamincer-daszkiewicz]

Let's continue in #139.