Is It possible "un-approve" a IIA?

[skishk]

Dear Colleagues,

is it possible to send an approval and then, without any change of the IIA, partner send an empty response of the approval? different providers are using to do that in production. is that written in the specification? if not we have to manage it as an un-approval?

Thank you

[mkurzydlowski]

is it possible to send an approval and then, without any change of the IIA, partner send an empty response of the approval?

I'm not able to understand that sentence. Can you provide an example scenario?

[JoelBlancoCloserIdeas]

is it possible to send an approval and then, without any change of the IIA, partner send an empty response of the approval?

If the IIA is not mutually approved, the partner can remove the approval (return empty response in IIA GET Approval API). They could even send an IIA Approval CNR and return an empty response in IIA GET Approval API (they could remove it just after they the CNR is sent).

[umesh-qs]

is it possible to send an approval and then, without any change of the IIA, partner send an empty response of the approval?

If the IIA is not mutually approved, the partner can remove the approval (return empty response in IIA GET Approval API). They could even send an IIA Approval CNR and return an empty response in IIA GET Approval API (they could remove it just after they the CNR is sent).

And what does it mean when IIA is mutually approved and still one of the partner sends empty response?

[skishk]

If the IIA is not mutually approved

where is written? because i didn't find it. thank you

[skishk]

Can you provide an example scenario?

scenario is: 1) i received approval(not empty) with a condition hash. 2) then after some time i received an empty approval.

the IIA id is the same and the condition hash is the same.

[skishk]

If the IIA is not mutually approved, the partner can remove the approval (return empty response in IIA GET Approval API). They could even send an IIA Approval CNR and return an empty response in IIA GET Approval API (they could remove it just after they the CNR is sent).

starting from mutually approved that not exist as specification and it's just a way to say we have in the same time the 2 IIA approved, where is written that we have to manage this scenario as un-approval? is it allowed? how every one must manage it?

what i understood in the past is: if you approve something you can't un-approve it.

[umesh-qs]

If the IIA is not mutually approved, the partner can remove the approval (return empty response in IIA GET Approval API). They could even send an IIA Approval CNR and return an empty response in IIA GET Approval API (they could remove it just after they the CNR is sent).

starting from mutually approved that not exist as specification and it's just a way to say we have in the same time the 2 IIA approved, where is written that we have to manage this scenario as un-approval? is it allowed? how every one must manage it?

what i understood in the past is: if you approve something you can't un-approve it.

I don't think it is entirely true. If my partner has approved my IIA with hash1, and I change my IIA to change the hash to hash2. It is implicit that the previous approval has no meaning and most likely my partner will not send a valid response to my IIA approval GET request.

[skishk]

I don't think it is entirely true. If my partner has approved my IIA with hash1, and I change my IIA to change the hash to hash2. It is implicit that the previous approval has no meaning and most likely my partner will not send a valid response to my IIA approval GET request.

the scenario is: https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/issues/15#issuecomment-1886831235

and if the hash is changed (from hash1 to hash2) and in the approval you still return hash1 is more correct then empty in my opinion because you say the approved version is still hash1. i can check the hash1 is not equals to hash2 so my IIA hash2 is still not approved.

but in the scenario: https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/issues/15#issuecomment-1886831235 how have we(all the network) manage it?

[umesh-qs]

I don't think it is entirely true. If my partner has approved my IIA with hash1, and I change my IIA to change the hash to hash2. It is implicit that the previous approval has no meaning and most likely my partner will not send a valid response to my IIA approval GET request.

the scenario is: #15 (comment)

and if the hash is changed (from hash1 to hash2) and in the approval you still return hash1 is more correct then empty in my opinion because you say the approved version is still hash1. i can check the hash1 is not equals to hash2 so my IIA hash2 is still not approved.

scenario: https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/issues/15#issuecomment-1886831235 is similar. Whether hash changes or hash doesn't. If my partner sees that I have changed the IIA or the partner itself changes their linked IIA, partner would reset the approval for both IIA and would probably send empty response in approval request.

but in the scenario: #15 (comment) how have we(all the network) manage it?

[demilatof]

If the IIA is not mutually approved, the partner can remove the approval (return empty response in IIA GET Approval API).

Currently, in EWP you cannot unapprove anything. From the API Summary:

This API allows HEIs to approve agreements sent by their partners in the Interinstitutional Agreements API.

And it was so even starting with version 0.2.1

[umesh-qs]

If the IIA is not mutually approved, the partner can remove the approval (return empty response in IIA GET Approval API).

Currently, in EWP you cannot unapprove anything. From the API Summary:

This API allows HEIs to approve agreements sent by their partners in the Interinstitutional Agreements API.

And it was so even starting with version 0.2.1

Yes if response is proper. Empty response means no approval.

[demilatof]

Yes if response is proper. Empty response means no approval.

What do you mean with "proper"?

[demilatof]

scenario: #15 (comment) is similar. Whether hash changes or hash doesn't. If my partner sees that I have changed the IIA or the partner itself changes their linked IIA, partner would reset the approval for both IIA and would probably send empty response in approval request.

In my opinion, once you approved you have always to return the last approval you give, and you clarify this fact to the partner with the hash code. If the partner has changed his IIA and you haven't approved it again, you keep on returning the same IIA ID and the old hash code. Your partner can realize in this way that you're not approving the last version.

[janinamincer-daszkiewicz]

In my opinion, once you approved you have always to return the last approval you give, and you clarify this fact to the partner with the hash code.

I agree.

[umesh-qs]

Yes if response is proper. Empty response means no approval.

What do you mean with "proper"?

Response as per example https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/blob/stable-v2/response-example.xml.

[umesh-qs]

scenario: #15 (comment) is similar. Whether hash changes or hash doesn't. If my partner sees that I have changed the IIA or the partner itself changes their linked IIA, partner would reset the approval for both IIA and would probably send empty response in approval request.

In my opinion, once you approved you have always to return the last approval you give, and you clarify this fact to the partner with the hash code. If the partner has changed his IIA and you haven't approved it again, you keep on returning the same IIA ID and the old hash code. Your partner can realize in this way that you're not approving the last version.

There is no such requirement. What you are now introducing is providers store past partial approvals, even when the IIA has changed. This is unnecessary.

[skishk]

There is no such requirement. What you are now introducing is providers store past partial approvals, even when the IIA has changed. This is unnecessary.

i think not past approval... it is last approval. if you approved a version of my IIA you return it even the IIA is changed and you still didn't approved the new one. if you never approved mine IIA so the response is empty, ok.

@janinamincer-daszkiewicz i come back to my question: is it possible or not to unapprove a IIA? just to know if i have to manage them in my system as unapproved or not. and if we have to report all these cases... but i hope it will be a clarification in the IF forum for all providers how to manage the approval and how to not manage the unapproval.

[umesh-qs]

There is no such requirement. What you are now introducing is providers store past partial approvals, even when the IIA has changed. This is unnecessary.

i think not past approval... it is last approval. if you approved a version of my IIA you return it even the IIA is changed and you still didn't approved the new one. if you never approved mine IIA so the response is empty, ok.

Why is that needed. If this has to be implemented like what you are suggesting, then what to do when an empty response is received after the approval? Should that be an error to be reported? On one hand you are saying last approval must be sent and on the other hand you are asking Janina what to do when empty response is sent on approved IIA.

@janinamincer-daszkiewicz i come back to my question: is it possible or not to unapprove a IIA? just to know if i have to manage them in my system as unapproved or not. and if we have to report all these cases... but i hope it will be a clarification in the IF forum for all providers how to manage the approval and how to not manage the unapproval.

[demilatof]

In my opinion, once you approved you have always to return the last approval you give, and you clarify this fact to the partner with the hash code. If the partner has changed his IIA and you haven't approved it again, you keep on returning the same IIA ID and the old hash code. Your partner can realize in this way that you're not approving the last version.

There is no such requirement. What you are now introducing is providers store past partial approvals, even when the IIA has changed. This is unnecessary.

I'm introducing nothing, I'm just applying the specification that says:

Each partner should behave in the same way and independently:

• Get partner’s copy of the agreement, check the hash, send notification about an approval of this version to the partner and store the partner hash as the proof;
• Get the partner's approval to its own copy and store the response (iia_id and hash) locally as the proof that the partner has approved a particular version of the agreement;

The above points are the core of the approval meaning (from ever):

• You send notification about an approval of this version, they never say "or about a not approval"; this means that if you don't want to approve, you don't send any notification. But if you don't send any notification, this means that the only approval item that can be fetched is the last one, the previous hash. And since your partner can invoke your Approval API any time, you have to keep on returning the previous hash (i.e. the previous version approved)
• You have to store the hash as a proof
• You have to never overwrite it with the last hash (otherwise you lost the proof, as remembered by the specification: the proof that the partner has approved a particular version of the agreement)

I think that if you don't store the approved hashes you should have to reconsider your system

P.S: what makes confusion about the approval is the need to delete it in the deletion scenario, because it introduces the concept of an empty approval, as @skishk noticed, that was never considered by the specifications. And I have always stressed this, even during the infrastructure forums.

There is no need to "delete" an approval, I cannot send a new Approval CNR if I do an IIA-Get before and I don't find any IIA. And if I cannot approve the new IIA, the only thing I can do is returning always the last approved version, if I have one. But I cannot push it, it is the partner that has to pull it. And at this point:

• Why has he to ask me for the approval of a deleted IIA?
• What kind of problem I make him if I say that I've approved a particular version of the IIA? The IIA is deleted, he can ignore any answer

[umesh-qs]

In my opinion, once you approved you have always to return the last approval you give, and you clarify this fact to the partner with the hash code. If the partner has changed his IIA and you haven't approved it again, you keep on returning the same IIA ID and the old hash code. Your partner can realize in this way that you're not approving the last version.

There is no such requirement. What you are now introducing is providers store past partial approvals, even when the IIA has changed. This is unnecessary.

I'm introducing nothing, I'm just applying the specification that says:

Each partner should behave in the same way and independently:

• Get partner’s copy of the agreement, check the hash, send notification about an approval of this version to the partner and store the partner hash as the proof;
• Get the partner's approval to its own copy and store the response (iia_id and hash) locally as the proof that the partner has approved a particular version of the agreement;

The above points are the core of the approval meaning (from ever):

• You send notification about an approval of this version, they never say "or about a not approval"; this means that if you don't want to approve, you don't send any notification. But if you don't send any notification, this means that the only approval item that can be fetched is the last one, the previous hash. And since your partner can invoke your Approval API any time, you have to keep on returning the previous hash (i.e. the previous version approved)
• You have to store the hash as a proof
• You have to never overwrite it with the last hash (otherwise you lost the proof, as remembered by the specification: the proof that the partner has approved a particular version of the agreement)

I think that if you don't store the approved hashes you should have to reconsider your system

P.S: what makes confusion about the approval is the need to delete it in the deletion scenario, because it introduces the concept of an empty approval, as @skishk noticed, that was never considered by the specifications. And I have always stressed this, even during the infrastructure forums.

There is no need to "delete" an approval, I cannot send a new Approval CNR if I do an IIA-Get before and I don't find any IIA. And if I cannot approve the new IIA, the only thing I can do is returning always the last approved version, if I have one. But I cannot push it, it is the partner that has to pull it. And at this point:

• Why has he to ask me for the approval of a deleted IIA?
• What kind of problem I make him if I say that I've approved a particular version of the IIA? The IIA is deleted, he can ignore any answer

You are conveniently interpreting the specification as "IIA approval response must contain a hash if the IIA was approved at-least once in a lifetime, otherwise the response should be empty". How can you force a provider to keep an outdated approval that is never going to be used. Are you suggesting that if my partner has reverted back to the previous state (hash), it will be considered auto-approved? There is no need for me to keep any proof of something that is useless. Only if the agreement is mutually approved I need to keep the hash/xml as proof.

[demilatof]

You are conveniently interpreting the specification as "IIA approval response must contain a hash if the IIA was approved at-least once in a lifetime, otherwise the response should be empty". How can you force a provider to keep an outdated approval that is never going to be used.

I don't interpret anything, these are the specification, as confirmed by @janinamincer-daszkiewicz I cannot force anyone, but it the specification says that "_store the response (iiaid and hash) locally as the proof that the partner has approved a particular version" he has to do. The proof is something that you have to preserve, not necessary to use.

Are you suggesting that if my partner has reverted back to the previous state (hash), it will be considered auto-approved?

If you haven't approved a new version in the meantime, yes. Do you want that I approve again your IIA if:

1. I approved the IIA with 5 places
2. You change it to 3
3. I ignore the change
4. You revert to 5

I already told you that 5 places are ok! Instead, if I have approved you for 3 and you revert to 5, I've to approve your IIA again.

There is no need for me to keep any proof of something that is useless. Only if the agreement is mutually approved I need to keep the hash/xml as proof.

If I call your approval several times, how can you answer me if you don't keep at least the last proof? Storing the oldest ones is a matter of good practice in your Country. In Italy, we have to do.

[umesh-qs]

You are conveniently interpreting the specification as "IIA approval response must contain a hash if the IIA was approved at-least once in a lifetime, otherwise the response should be empty". How can you force a provider to keep an outdated approval that is never going to be used.

I don't interpret anything, these are the specification, as confirmed by @janinamincer-daszkiewicz I cannot force anyone, but it the specification says that "_store the response (iiaid and hash) locally as the proof that the partner has approved a particular version" he has to do. The proof is something that you have to preserve, not necessary to use.

Are you suggesting that if my partner has reverted back to the previous state (hash), it will be considered auto-approved?

If you haven't approved a new version in the meantime, yes. Do you want that I approve again your IIA if:

1. I approved the IIA with 5 places
2. You change it to 3
3. I ignore the change
4. You revert to 5

I already told you that 5 places are ok! Instead, if I have approved you for 3 and you revert to 5, I've to approve your IIA again.

There is no need for me to keep any proof of something that is useless. Only if the agreement is mutually approved I need to keep the hash/xml as proof.

If I call your approval several times, how can you answer me if you don't keep at least the last proof? Storing the oldest ones is a matter of good practice in your Country. In Italy, we have to do.

That is your interpretation. Specs do not say that once approved, the response must always contain the last approved hash. In fact specs say that if there is no approval, empty response must be sent.

[demilatof]

That is your interpretation. Specs do not day that once approved, the response must always contain the last approved hash. In fact specs say that if there is no approval, empty response must be sent.

This is your wrong interpretation, that could be even dangerous after the mutual approval. It seems to me that you forget this part of the XSD

This element represents a single IIA approval.
For each of the iia_id values passed in the API call, server will produce one such element if and only if the corresponding agreement (more precisely: partner's copy of the agreement) is approved by him.

If you give me an empty response, you mean that you haven't approved my IIA, that is wrong. You haven't (yet) approved my current IIA, but my IIA has been previously approved. This is why we specify the hash code.

[umesh-qs]

That is your interpretation. Specs do not day that once approved, the response must always contain the last approved hash. In fact specs say that if there is no approval, empty response must be sent.

This is your wrong interpretation, that could be even dangerous after the mutual approval. It seems to me that you forget this part of the XSD

This element represents a single IIA approval. For each of the iia_id values passed in the API call, server will produce one such element if and only if the corresponding agreement (more precisely: partner's copy of the agreement) is approved by him.

If you give me an empty response, you mean that you haven't approved my IIA, that is wrong. You haven't (yet) approved my current IIA, but my IIA has been previously approved. This is why we specify the hash code.

There is no difference between getting a approval for old copy of IIA vs empty response. What difference does it create when processing in your system? In-fact if you are treating it differently, then you are writing more logic to compare the new and old hash. Also if empty response is sent then probably treat it as an error and report to monitoring API. All this is unnecessary.

[demilatof]

If you give me an empty response, you mean that you haven't approved my IIA, that is wrong. You haven't (yet) approved my current IIA, but my IIA has been previously approved. This is why we specify the hash code.

There is no difference between getting a approval for old copy of IIA vs empty response. What difference does it create when processing in your system? In-fact if you are treating it differently, then you are writing more logic to compare the new and old hash. Also if empty response is sent then probably treat it as an error and report to monitoring API. All this is unnecessary.

There is a huge difference and I don't understand how can someone have any doubt:

• Old Copy: the IIA has been approved at a given time
• empty response: the IIA has never been approved

[demilatof]

One more thing: I can call your Approval API several times. You have approved my IIA, with hash XX. When you decide to start answering me with an empty approval?

[umesh-qs]

If you give me an empty response, you mean that you haven't approved my IIA, that is wrong. You haven't (yet) approved my current IIA, but my IIA has been previously approved. This is why we specify the hash code.

There is no difference between getting a approval for old copy of IIA vs empty response. What difference does it create when processing in your system? In-fact if you are treating it differently, then you are writing more logic to compare the new and old hash. Also if empty response is sent then probably treat it as an error and report to monitoring API. All this is unnecessary.

There is a huge difference and I don't understand how can someone have any doubt:

• Old Copy: the IIA has been approved at a given time
• empty response: the IIA has never been approved

I asked the difference in terms of how you process it? If your system gets a response that has old approved hash vs gets a response that is empty. What is it that you do in your system? Happy to get my doubts cleared.

[skishk]

@umesh-qs tell me how you manage this scenario:

1) i received approval(not empty) with a condition hash. 2) then after some time i received an empty approval with nothing is changed.

and i just asked how it must managed by the network. to have the same situation in every system and not that one interpret it as unapproved and other one still approved.

[demilatof]

I asked the difference in terms of how you process it? If your system gets a response that has old approved hash vs gets a response that is empty. What is it that you do in your system? Happy to get my doubts cleared.

I think it should be quite clear:

• if I receive the approval for an old hash it means that nothing has changed and the IIA is still approved in its previous version
• if I receive an empty approval, it means that the IIA is no more approved at all

[janinamincer-daszkiewicz]

Let me remind you about the document 2023-10-28-DeleteSummary.pdf, Part II (to be find at https://esci-sd.atlassian.net/wiki/spaces/ITSC/pages/113999873/Infrastructure+Forum+and+technical+workshops) which formulates some recommendations on the effect of IIA Delete on IIA Approval.

In case IIA is not deleted (although may be it has been modified) there is no reason to delete existing approvals. There is nothing like un-approval.

[demilatof]

In case IIA is not deleted (although may be it has been modified) there is no reason to delete existing approvals. There is nothing like un-approval.

Unluckily "there is no reason" doesn't mean that it is forbidden or not. I agree that there is nothing like un-approval, but it would be better if the specification states something like that:

"Once you have approved your partner's IIA, you cannot un-approve it and you Approval response MUST always return the last hash code you have approved for that IIA. The only exception is when an IIA is deleted, in this case the approval SHOULD be removed from the network and the approval MUST return an empty response"

[umesh-qs]

I asked the difference in terms of how you process it? If your system gets a response that has old approved hash vs gets a response that is empty. What is it that you do in your system? Happy to get my doubts cleared.

I think it should be quite clear:

• if I receive the approval for an old hash it means that nothing has changed and the IIA is still approved in its previous version
• if I receive an empty approval, it means that the IIA is no more approved at all

I understand the meaning on paper. You still have not mentioned how you are handling the response.

1. If the old hash is received in response, previous version is approved. But what changes do you make in your system. Do you show your clients that last version is approved but current version is not approved?
2. If you receive empty response for an IIA that was approved earlier, what do you do. Ignore it? Or report an error to monitoring API?

[janinamincer-daszkiewicz]

it would be better if the specification states ...

I agree, however as it is said in the referenced document:

After intensive consultations, the ESCI consortium and DG EAC decided that in order to avoid imposing additional requirements on developers to handle the impact of IIA deletion on IIA Approval, no changes will be made to the specification. In practical terms, this means that implementers have a free hand in this respect.

Anyway, I note all such conclusions hoping that there will be another window for changes. For now I can say that this is strongly recommended.

[demilatof]

I understand the meaning on paper. You still have not mentioned how you are handling the response.

1. If the old hash is received in response, previous version is approved. But what changes do you make in your system. Do you show your clients that last version is approved but current version is not approved?

2. If you receive empty response for an IIA that was approved earlier, what do you do. Ignore it? Or report an error to monitoring API?

1. Yes, of course. I show:

• The current version to manage a new approval, if they want so
• The fact that there is a version previously approved
• The timestamp of the previous approval
• The link to view the snapshot (the previous approval)

2. I'm still implementing the report toward the monitoring API, but most probably yes. If my partner has already approved my IIA, he cannot send me an empty response (except for deleting, but only before a mutual approval). It's exactly what I have objected to Dashboard while we were testing 6.3.0 and they send me an empty approval. And after they asked @janinamincer-daszkiewicz they fixed their response

Instead, what are you showing to your IROs?

[demilatof]

I agree, however as it is said in the referenced document:

After intensive consultations, the ESCI consortium and DG EAC decided that in order to avoid imposing additional requirements on developers to handle the impact of IIA deletion on IIA Approval, no changes will be made to the specification. In practical terms, this means that implementers have a free hand in this respect.

But the evidenced part is limited to the IIA deletion, whilst we need a strong specification to remove these ambiguities even when there is no deletion. If we keep only the following bold part, we didn't change the Approval Specification due to the IIA deletion and we have a huge improvement anyway:

"Once you have approved your partner's IIA, you cannot un-approve it and you Approval response MUST always return the last hash code you have approved for that IIA. The only exception is when an IIA is deleted, in this case the approval SHOULD be removed from the network and the approval MUST return an empty response"

[umesh-qs]

I understand the meaning on paper. You still have not mentioned how you are handling the response.

1. If the old hash is received in response, previous version is approved. But what changes do you make in your system. Do you show your clients that last version is approved but current version is not approved?

2. If you receive empty response for an IIA that was approved earlier, what do you do. Ignore it? Or report an error to monitoring API?

1. Yes, of course. I show:

• The current version to manage a new approval, if they want so
• The fact that there is a version previously approved
• The timestamp of the previous approval
• The link to view the snapshot (the previous approval)

And what changes for your client, in-case the response is empty after it was approved?

2. I'm still implementing the report toward the monitoring API, but most probably yes. If my partner has already approved my IIA, he cannot send me an empty response (except for deleting, but only before a mutual approval). It's exactly what I have objected to Dashboard while we were testing 6.3.0 and they send me an empty approval. And after they asked @janinamincer-daszkiewicz they fixed their response

I do not see this restriction anywhere in the specification. Please point me to the specification that says "empty approval response is allowed only until the IIA is never approved"

Instead, what are you showing to your IROs?

As soon as we change our IIA, and we know hash has changed and we show the IIA as unapproved. It really doesn't matters what my partner responds, because I know that IIA is no more approved. Our client can always see the history of changes to the IIA including any previous approvals. What you are and probably Janina are trying to imply is that the response of your partner, has more value on your copy of IIA, even when you already know it is no more approved.

[demilatof]

And what changes for your client, in-case the response is empty after it was approved?

Nothing because I check if it is a valid answer before using it and I trash away the response. Do you want to flood the network with a nonsense answer? It's a dangerous game.

Otherwise, I should tell my IROs that the IIA is no more valid, and it would be wrong and dangerous.

I do not see this restriction anywhere in the specification. Please point me to the specification that says "empty approval response is allowed only until the IIA is never approved"

I'm sorry that you don't pay attention to the specification, even if they are written here and there:

From the XSD:

This element represents a single IIA approval. For each of the iia_id values passed in the API call, server will produce one such element if and only if the corresponding agreement (more precisely: partner's copy of the agreement) is approved by him.

From the Approval API page

This API allows HEIs to approve agreements sent by their partners in the Interinstitutional Agreements API.

If you first approve and then you send an empty approval, this means that the IIA is not approved (from XSD). But if it is not approved, and before it was, you are doing an un-approval, infringing the specification that says "This API allows HEIs to approve agreements". It doesn't say that allow HEIs to un-approve. And this close any discussion.

As soon as we change our IIA, and we know hash has changed and we show the IIA as unapproved. It really doesn't matters what my partner responds, because I know that IIA is no more approved. Our client can always see the history of changes to the IIA including any previous approvals. What you are and probably Janina are trying to imply is that the response of your partner, has more value on your copy of IIA, even when you already know it is no more approved.

You're mixing what happens in your IIA and what you have to provide to your partner with the Approval API. When you change your IIA, you need a new approval, but the old one is still valid, mostly if you and your partner reached a mutual approval. But until you don't approve a new version of your partner's IIA, you cannot change your mind and tell him that his IIA is no more approved, because a mutual approval still exists and the proof is that the mobilities are valid and the students are exchanged.

@janinamincer-daszkiewicz this is why I think we need sooner a more accurate sentence in the specification. As I showed above, I think that the specification already imposes this behavior, but rewriting it could be more useful and it would not be against the ESCI consortium and DG EAC because it would add nothing new (for who have correctly read the specification)

[janinamincer-daszkiewicz]

If that could be considered as 'clarification', we can try to add it. We definitely want to avoid changes which would negatively influence the current process of implementation. Exactly, what change do you suggest?

[demilatof]

If that could be considered as 'clarification', we can try to add it. We definitely want to avoid changes which would negatively influence the current process of implementation.

For me it could be a clarification, but maybe not for anyone else, who has implemented something different. The problem is that the current process of implementation is seriously compromised if anyone can implement a deeply different solution (empty approval vs. not empty approval). So the clarification is needed at any cost.

Exactly, what change do you suggest?

As I said, it could be useful adding the following sentence at this point and/or in the XSD:

Once you have approved your partner's IIA, even if with a different hash code, you cannot un-approve it and you Approval response MUST always return the last hash code you have approved for that IIA. In other words, your response cannot be again empty if at least one time it was not.

It could be even useful adding the following clarification, but doing so we are touching even the deletion part, the one that DG EAC doesn't want to modify.

The only exception is when an IIA is deleted; in this case the approval SHOULD be removed from the network and the approval MUST return an empty response

In my opinion, this is not a great problem anyway, because the scenarios allow the developers both to delete the approval (empty response) and to keep it (not empty approval).

I think it is useful to listen @skishk's opinion, since he opened the issue.

[umesh-qs]

And what changes for your client, in-case the response is empty after it was approved?

Nothing because I check if it is a valid answer before using it and I trash away the response. Do you want to flood the network with a nonsense answer? It's a dangerous game.

Otherwise, I should tell my IROs that the IIA is no more valid, and it would be wrong and dangerous.

I do not see this restriction anywhere in the specification. Please point me to the specification that says "empty approval response is allowed only until the IIA is never approved"

I'm sorry that you don't pay attention to the specification, even if they are written here and there:

From the XSD:

This element represents a single IIA approval. For each of the iia_id values passed in the API call, server will produce one such element if and only if the corresponding agreement (more precisely: partner's copy of the agreement) is approved by him.

You are reading this as per your convenience. I have to send only if I am still approving the IIA. Current version of the IIA is not approved.

From the Approval API page

This API allows HEIs to approve agreements sent by their partners in the Interinstitutional Agreements API.

If you first approve and then you send an empty approval, this means that the IIA is not approved (from XSD). But if it is not approved, and before it was, you are doing an un-approval, infringing the specification that says "This API allows HEIs to approve agreements". It doesn't say that allow HEIs to un-approve. And this close any discussion.

Does it says it does not allow to un-approve?

As soon as we change our IIA, and we know hash has changed and we show the IIA as unapproved. It really doesn't matters what my partner responds, because I know that IIA is no more approved. Our client can always see the history of changes to the IIA including any previous approvals. What you are and probably Janina are trying to imply is that the response of your partner, has more value on your copy of IIA, even when you already know it is no more approved.

You're mixing what happens in your IIA and what you have to provide to your partner with the Approval API. When you change your IIA, you need a new approval, but the old one is still valid, mostly if you and your partner reached a mutual approval. But until you don't approve a new version of your partner's IIA, you cannot change your mind and tell him that his IIA is no more approved, because a mutual approval still exists and the proof is that the mobilities are valid and the students are exchanged.

You can store any proof in your system. If partner is sending an empty response, do you consider that as a proof of something that you have in your system.

@janinamincer-daszkiewicz this is why I think we need sooner a more accurate sentence in the specification. As I showed above, I think that the specification already imposes this behavior, but rewriting it could be more useful and it would not be against the ESCI consortium and DG EAC because it would add nothing new (for who have correctly read the specification)

This is your interpretation. Any changes in specification now that fulfills your interpretation, must go through a vote. You cannot determine how this is interpreted currently by everyone. In fact you yourself are saying that it might not be interpreted and implemented the way you are explaining and need to put clarification.

[umesh-qs]

If that could be considered as 'clarification', we can try to add it. We definitely want to avoid changes which would negatively influence the current process of implementation.

For me it could be a clarification, but maybe not for anyone else, who has implemented something different. The problem is that the current process of implementation is seriously compromised if anyone can implement a deeply different solution (empty approval vs. not empty approval). So the clarification is needed at any cost.

You are just exaggerating. There is no compromise. You may just ignore the empty response if you want or do whatever you have been doing until now. No changes are needed in the specification at this moment.

Exactly, what change do you suggest?

As I said, it could be useful adding the following sentence at this point and/or in the XSD:

Once you have approved your partner's IIA, even if with a different hash code, you cannot un-approve it and you Approval response MUST always return the last hash code you have approved for that IIA. In other words, your response cannot be again empty if at least one time it was not.

It could be even useful adding the following clarification, but doing so we are touching even the deletion part, the one that DG EAC doesn't want to modify.

The only exception is when an IIA is deleted; in this case the approval SHOULD be removed from the network and the approval MUST return an empty response

In my opinion, this is not a great problem anyway, because the scenarios allow the developers both to delete the approval (empty response) and to keep it (not empty approval).

I think it is useful to listen @skishk's opinion, since he opened the issue.

[skishk]

I just asked what is the correct behavior in this scenario because in production we saw differente response from different partners for the same scenario... so i understood that is not interpreted in the same way from each one so i raised the question. for us it is not difficult to change in a way or in the other one... what i like to know is the way for everyone in the network to manage this scenario correctly and in the same way. this is a basic scenario, with API v7(IIA) and v2(approval) there are a lot of scenarios more complicated then this so i think we need a strong specification to manage Approvals.

as we seen in the previous comments everyone is interpreting it differently this confirm what we seen in production now and what it will be after new version of the APIs, so in conclusion i think it's really needed a strong specification about that.

thank you for the brainstorming and the evidence that raised

[demilatof]

If that could be considered as 'clarification', we can try to add it. We definitely want to avoid changes which would negatively influence the current process of implementation.

For me it could be a clarification, but maybe not for anyone else, who has implemented something different. The problem is that the current process of implementation is seriously compromised if anyone can implement a deeply different solution (empty approval vs. not empty approval). So the clarification is needed at any cost.

You are just exaggerating. There is no compromise. You may just ignore the empty response if you want or do whatever you have been doing until now. No changes are needed in the specification at this moment.

No, I can't, because for someone the empty response may be a "un-approve" and then I cannot ignore it. If I ignored it, I could arrange the application form for students, make the nomination and the partner finally tells me that there is no mutual agreement because he has removed the approval and now he doesn't want to accept my students anymore.

I do not see this restriction anywhere in the specification. Please point me to the specification that says "empty approval response is allowed only until the IIA is never approved"

Here you are:

Values of iia_id that are not known by the server as covered HEI agreements or not approved (yet or at all) MUST be ignored.

1. Is my iia_id unknown? No
2. Is my iia_id not yet approved? No, you have approved it before
3. Could be my iia_id not approved at all? No, you have approved it before

If you send me an empty response you fall into one of the three options above, and this means that for you my IIA is unknown or not yet approved (or not at all), arising doubt about our previous mutual approval and about your intentions. This must be avoided.

[umesh-qs]

If that could be considered as 'clarification', we can try to add it. We definitely want to avoid changes which would negatively influence the current process of implementation.

For me it could be a clarification, but maybe not for anyone else, who has implemented something different. The problem is that the current process of implementation is seriously compromised if anyone can implement a deeply different solution (empty approval vs. not empty approval). So the clarification is needed at any cost.

You are just exaggerating. There is no compromise. You may just ignore the empty response if you want or do whatever you have been doing until now. No changes are needed in the specification at this moment.

No, I can't, because for someone the empty response may be a "un-approve" and then I cannot ignore it. If I ignored it, I could arrange the application form for students, make the nomination and the partner finally tells me that there is no mutual agreement because he has removed the approval and now he doesn't want to accept my students anymore.

I do not see this restriction anywhere in the specification. Please point me to the specification that says "empty approval response is allowed only until the IIA is never approved"

Here you are:

Values of iia_id that are not known by the server as covered HEI agreements or not approved (yet or at all) MUST be ignored.

1. Is my iia_id unknown? No

Is your IIA ID unknown if it was never approved? No, but the empty response is still allowed and accepted. Where does it says the empty response means IIA was never approved?

2. Is my iia_id not yet approved? No, you have approved it before

It is not approved in current form. You are bringing the concept of never approved vs approved at least once which you must handle internally.

3. Could be my iia_id not approved at all? No, you have approved it before

It is not approved in current form. You are bringing the concept of never approved vs approved at least once which you must handle internally.

If you send me an empty response you fall into one of the three options above, and this means that for you my IIA is unknown or not yet approved (or not at all), arising doubt about our previous mutual approval and about your intentions. This must be avoided.

You can ignore it as you would do when empty response is sent when IIA is never approved. You can continue to show your client the last approved history. Why do you want network level changes to something internal to your system.

[demilatof]

1. Is my iia_id unknown? No

Is your IIA ID unknown if it was never approved? No, but the empty response is still allowed and accepted. Where does it says the empty response means IIA was never approved?

2. Is my iia_id not yet approved? No, you have approved it before

It is not approved in current form. You are bringing the concept of never approved vs approved at least once which you must handle internally.

3. Could be my iia_id not approved at all? No, you have approved it before

It is not approved in current form. You are bringing the concept of never approved vs approved at least once which you must handle internally.

If you send me an empty response you fall into one of the three options above, and this means that for you my IIA is unknown or not yet approved (or not at all), arising doubt about our previous mutual approval and about your intentions. This must be avoided.

You can ignore it as you would do when empty response is sent when IIA is never approved. You can continue to show your client the last approved history. Why do you want network level changes to something internal to your system.

You cannot read specification piece by piece, they are a whole, the fact that the IIA is not approved in the current form is clarified by the hash code together with the IIA ID, but you find convenient to ignore this point.

There is no need to tell you that an empty response means IIA was never approved, as there is no need to tell you that IIA-Get is not to put an IIA; it's enough the fact that they say that "_Values of iiaid that are not known by the server as covered HEI agreements or not approved (yet or at all) MUST be ignored".

For whatever reason, I could have missed your approval response and in the meantime I could have made a little change, but at the same time I need to know if you have approved any versions of my IIA before.

The network is asynchronous and you cannot model your system suggesting the partner to ignore or not something at your convenience. You don't allow me to know at whatever moment if you have ever approved me an IIA, therefore, who is putting in a mess the network is you, not me.

For me, it's enough that @janinamincer-daszkiewicz has confirmed that it's correct to send always the last hash code approved, but now it must be written down in the specifications to close the question.

If you have to change your code, I'm sorry, but you will have to do.

[umesh-qs]

1. Is my iia_id unknown? No

Is your IIA ID unknown if it was never approved? No, but the empty response is still allowed and accepted. Where does it says the empty response means IIA was never approved?

2. Is my iia_id not yet approved? No, you have approved it before

It is not approved in current form. You are bringing the concept of never approved vs approved at least once which you must handle internally.

3. Could be my iia_id not approved at all? No, you have approved it before

It is not approved in current form. You are bringing the concept of never approved vs approved at least once which you must handle internally.

If you send me an empty response you fall into one of the three options above, and this means that for you my IIA is unknown or not yet approved (or not at all), arising doubt about our previous mutual approval and about your intentions. This must be avoided.

You can ignore it as you would do when empty response is sent when IIA is never approved. You can continue to show your client the last approved history. Why do you want network level changes to something internal to your system.

You cannot read specification piece by piece, they are a whole, the fact that the IIA is not approved in the current form is clarified by the hash code together with the IIA ID, but you find convenient to ignore this point.

There is no need to tell you that an empty response means IIA was never approved, as there is no need to tell you that IIA-Get is not to put an IIA; it's enough the fact that they say that "_Values of iiaid that are not known by the server as covered HEI agreements or not approved (yet or at all) MUST be ignored".

For whatever reason, I could have missed your approval response and in the meantime I could have made a little change, but at the same time I need to know if you have approved any versions of my IIA before.

The network is asynchronous and you cannot model your system suggesting the partner to ignore or not something at your convenience. You don't allow me to know at whatever moment if you have ever approved me an IIA, therefore, who is putting in a mess the network is you, not me.

This is not true. When you already have previous approval, why do you want it from the partner. Also what you are saying is that, if I send a approval CNR and then you don't find approval in my response then it is an error. You, wanting partner to send the last approval is in-fact complicating the implementation. A simple statement that says that if approval response is empty just ignore it in all cases is sufficient including the case of IIA delete. What you want is to have a special case for deleted IIA vs non-deleted IIA.

For me, it's enough that @janinamincer-daszkiewicz has confirmed that it's correct to send always the last hash code approved, but now it must be written down in the specifications to close the question.

If you have to change your code, I'm sorry, but you will have to do.

With all due respect, we go by what is there in the specification. If DG EAC is ready to change it and put a statement that serves your implementation then we are ready to do that. But then where do we get the the last approval hash for current setup, incase a provider never stored it?

[umesh-qs]

@demilatof you are quoting statement "Values of iia_id that are not known by the server as covered HEI agreements or not approved (yet or at all) MUST be ignored". It is asking server to send empty response in approval response for IIAs that meet the criteria. Where does it restrict sending empty response, otherwise?

[demilatof]

This is not true. When you already have previous approval, why do you want it from the partner. Also what you are saying is that, if I send a approval CNR and then you don't find approval in my response then it is an error. You, wanting partner to send the last approval is in-fact complicating the implementation. A simple statement that says that if approval response is empty just ignore it in all cases is sufficient including the case of IIA delete. What you want is to have a special case for deleted IIA vs non-deleted IIA.

This is your opinion, I can call your approval API any time, where is written I cannot? May be that what I'm asking is complicating your implementation, but it's full specification compliant. The difference between two different behaviors for the same empty response cannot rely on a partner's deduction.

When do you think to send me an approval CNR to tell me that from that moment your approval is empty?

With all due respect, we go by what is there in the specification. If DG EAC is ready to change it and put a statement that serves your implementation then we are ready to do that. But then where do we get the the last approval hash for current setup, incase a provider never stored it?

As I showed you, it's already in the specification. If you think that a provider could have never stored the approval hash, then you haven't even read this part of the specification, that has been published for almost three years

@demilatof you are quoting statement "Values of iia_id that are not known by the server as covered HEI agreements or not approved (yet or at all) MUST be ignored". It is asking server to send empty response in approval response for IIAs that meet the criteria. Where does it restrict sending empty response, otherwise?

In the following sign, where is written that a man cannot enter? Therefore you enter; this is your approach to the specifications.

[umesh-qs]

This is not true. When you already have previous approval, why do you want it from the partner. Also what you are saying is that, if I send a approval CNR and then you don't find approval in my response then it is an error. You, wanting partner to send the last approval is in-fact complicating the implementation. A simple statement that says that if approval response is empty just ignore it in all cases is sufficient including the case of IIA delete. What you want is to have a special case for deleted IIA vs non-deleted IIA.

This is your opinion, I can call your approval API any time, where is written I cannot? May be that what I'm asking is complicating your implementation, but it's full specification compliant. The difference between two different behaviors for the same empty response cannot rely on a partner's deduction.

When do you think to send me an approval CNR to tell me that from that moment your approval is empty? Backoffice user approves the IIA by mistake and immediately corrects it. Question is what would you do in this case. Report error to monitoring API or ignore it?

With all due respect, we go by what is there in the specification. If DG EAC is ready to change it and put a statement that serves your implementation then we are ready to do that. But then where do we get the the last approval hash for current setup, incase a provider never stored it?

As I showed you, it's already in the specification. If you think that a provider could have never stored the approval hash, then you haven't even read this part of the specification, that has been published for almost three years

You are again looking at positive scenario. It says store IIA hash as a proof of what I approved. But when the hash has changed why do I need to keep the old hash. IIA will go for re-approval. All you arguments are based on the assumption that hash needs to be kept even if the IIA is no more approved. There was no concept of reverting to old approval 3 years back. Do not mix todays requirement with requirement that was 3 years back.

@demilatof you are quoting statement "Values of iia_id that are not known by the server as covered HEI agreements or not approved (yet or at all) MUST be ignored". It is asking server to send empty response in approval response for IIAs that meet the criteria. Where does it restrict sending empty response, otherwise?

In the following sign, where is written that a man cannot enter? Therefore you enter; this is your approach to the specifications.

Please argue logically and show any statement that says servers cannot send empty response after first approval. These are API specifications and must clearly state what is allowed and what is not. You analogy does not hold good here. Read the statement again and entire EWP specs. MUST on a certain criteria does not mean that it MUST be applied in all cases.

[skishk]

But when the hash has changed why do I need to keep the old hash. IIA will go for re-approval. All you arguments are based on the assumption that hash needs to be kept even if the IIA is no more approved. There was no concept of reverting to old approval 3 years back. Do not mix todays requirement with requirement that was 3 years back.

do you mean in IIA API v7 and Approval API v2 you will return always last hash approved?!