Proposal: a new parameter in IIA-Get request to retrieve the IIA snapshot

[demilatof]

During the last IF @janinamincer-daszkiewicz told me that she doesn't see the necessity do add a new option in IIA-Get to fetch the last approved version instead of the current one, that may be under review (we were talking about the modification of a mutual approved IIA). And she told me to open a GitHub issue if this point is important for me. So this is what I'm doing and I'm sorry that she doesn't see such a necessity.

There are several reasons to justify the need to fetch from the partner the last IIA version we have approved, getting it straightly from the partner's system and not from our one. But to be short, the main reason is contained in Outgoing Mobility Get endpoint. https://github.com/erasmus-without-paper/ewp-specs-api-omobilities/blob/stable-v2/endpoints/get-response.xsd

In the response of Outgoing Mobility Get endpoint we have the sending and receiving IIA-IDs; the get-response.xsd says: "clients can fetch more information on this agreement from IIAs API served on the sending (or receiving) HEI's servers". What do you think to provides when these clients call the IIA-Get API? The last approved IIA or the under review IIA? I think that only an approved IIA can rule a mobility, and this involves that IIA-Get must provide the way to ask for the approved version by means of an optional new parameter.

Therefore, again, I strongly suggest to modify IIA-Get adding the optional request parameter last_approved_version with the following explanation:

_Boolean, default false. The value false means, that the client is not interested in receiving last approved version of the agreements specified with iia_id or iiacode parameters. Therefore, if the parameter is set to false or not provided at all, the partner returns the most update version of the requested IIAs. If the parameter is provided and set to true, the response will contain the IIAs' snapshots taken when they have been approved (if they have been ever approved). If an IIA has never been approved, the relative IIA-ID is ignored and no value is returned.

Am I the only that feels the necessity to provide the current IIA or the last approved IIA depending on the client or the use?

[milsorm]

I definitely vote for this. We are still considering validity due to existence of two approval versions, one on each side.

[mkurzydlowski]

We would like to propose serving last approved partner's IIA in the IIA Approval API. Wouldn't it be enough if both partner's served what exactly they approved?

[demilatof]

May you provide an example? I'm afraid that this could over complicate the IIA Approval API (and perhaps the management of the snapshot), whilst the IIA Get is the natural way to provide an IIA

[skishk]

We would like to propose serving last approved partner's IIA in the IIA Approval API. Wouldn't it be enough if both partner's served what exactly they approved?

yeah it could be enough, but if someone lost for example the last partner's IIA approved? and he want to GET it? he must insert in the IIA-GET the condition hash that he wants to download. If condition hash is like the version of what is approved it is necessary to add it in the IIA-GET-REQUEST i think.

[demilatof]

Moreover it could be ambiguous: when I invoke your approval API, I only want to know if you approved my copy. In @mkurzydlowski 's proposal you add your snapshot to the approval, but this is not what I asked for. With IIA-Get I ask explicitly for your copy (approved or not, depending on the parameter).

[mkurzydlowski]

In @mkurzydlowski 's proposal you add your snapshot to the approval

No, you should add a snapshot of what you approve (the partner's IIA).

It's needed also to prove (without the need to verify the hash) what has been approved. So there are multiple reasons to add it.

As for an example, imagine an endpoint returning the exact XML as was produced by the partner the moment it was approved.

[skishk]

so we need to add condition hash (optional) in the IIA-GET-REQUEST (probably in the IIA-CNR too) and IIA-GET-APPROVAL (probably in the IIA-CNR-APPROVAL too) . if condition hash is not set so we return the last version.

could be have sense?

[demilatof]

In @mkurzydlowski 's proposal you add your snapshot to the approval

No, you should add a snapshot of what you approve (the partner's IIA).

It's needed also to prove (without the need to verify the hash) what has been approved. So there are multiple reasons to add it.

As for an example, imagine an endpoint returning the exact XML as was produced by the partner the moment it was approved.

In some way this breaks the master master model: I provide my copy, you yours. If you save the wrong snapshot, what should we do? I've already my copy and, indeed, I may keep your snapshot. But doing so there is even no need to ask for the approved IIA. And there is the problem of Outgoing Mobility Get endpoint: to retrieve the IIA we should use IIA-Get, IIA Approval is not appropriate and in your model I should ask B partner to fetch A's IIA and A partner to fetch B's IIA. Too chaotic.

[skishk]

In some way this breaks the master master model: I provide my copy, you yours.

this is not respected by many in production :sweat_smile: :sweat_smile: :sweat_smile: it's one of the major problem in production that we are facing unfortunately... hope it will be solved soon

[demilatof]

so we need to add condition hash (optional) in the IIA-GET-REQUEST (probably in the IIA-CNR too) and IIA-GET-APPROVAL (probably in the IIA-CNR-APPROVAL too) . if condition hash is not set so we return the last version.

could be have sense?

I'm wrong, or this solution may fail if you keep a more complete historical list than what I do? For example, you may ask for a hash code of an IIA approved 3 times ago, but I have only the current and last approved version and I cannot say anything about it

[skishk]

I'm wrong, or this solution may fail if you keep a more complete historical list than what I do? For example, you may ask for a hash code of an IIA approved 3 times ago, but I have only the current and last approved version and I cannot say anything about it

yeah you are right, depends by the new specification, the best thing is to have all the approved versions i think, but i can't decide it :sweat_smile:

[janinamincer-daszkiewicz]

As I understand Michał's proposal you always answer with the latest approved version. You may keep the history, but the latest approved suffices.

[demilatof]

As I understand Michał's proposal you always answer with the latest approved version. You may keep the history, but the latest approved suffices.

I understand that Michał propose to answer with the latest approved version, but my version, not his one. That is, for the first time in EWP we see that a partner provides no more his copy, but the other partner's copy

[janinamincer-daszkiewicz]

We are talking about the IIA Approval. Up to now in response to IIA Approval get we were sending just hash of the partners copy (the one we approved). We propose to add also XML of this IIA. Which means that we would always keep XML with IIA (and hash) and would send it in the response (to confirm that this is what in our opinion we approved). The version (name space) would not matter. We can change the major number (namespace) and we do not have to re-approve the mutually approved IIAs because we keep the latest approved version and send it upon request.

[skishk]

We propose to add also XML of this IIA

do you mean in the IIA-APPROVAL-RESPONSE ? or by IIA-GET?

[janinamincer-daszkiewicz]

I will try to write more details and the idea behind.

1. We increase the major number of the IIA and IIA Approval.
2. We don't want to have to re-approve already mutually approved IIAs.
3. The whole network will switch to new versions on the same day (e.g. January 1st, 2024).
4. In response to IIA get we will start sending IIA in the new format (with a new hash).
5. In response to IIA Approval get we will start sending IIA Approval in the new format. Part of it will be XML (+ hash) of the latest mutually approved IIA of the partner. The one we stored when we did the approval in the past. Most probaably with the old name space. We keep the whole approval evidence and we share it with the partner upon request.

[demilatof]

We are talking about the IIA Approval. Up to now in response to IIA Approval get we were sending just hash of the partners copy (the one we approved). We propose to add also XML of this IIA.

I don't understand: it's Michal's proposal or your?

Which means that we would always keep XML with IIA (and hash) and would send it in the response (to confirm that this is what in our opinion we approved). The version (name space) would not matter.

This is outside the scope of my proposal; my proposal is to fetch your last approved version, not mine. And without the namespace it could be useless: how can retrieve each single field if I don't know the version?

We can change the major number (namespace) and we do not have to re-approve the mutually approved IIAs because we keep the latest approved verison and send it upon request.

I don't understand: already now if we change the major number we don't have to re-approve the mutually approved version. The problem is to retrieve all data inside the last approved version.

[janinamincer-daszkiewicz]

I don't understand: it's Michal's proposal or your?

We discussed it internally so I can say that it is our proposal.

This is outside the scope of my proposal; my proposal is to fetch your last approved version, not mine.

I remember. This is a counter proposal, the more proper place for this discussion is probably https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/109 but both issues are inter-related.

And without the namespace it could be useless: how can retrieve each single field if I don't know the version?

I am not suggesting to get rid of namespace.

[demilatof]

I remember. This is a counter proposal, the more proper place for this discussion is probably #109 but both issues are inter-related.

And how you resolve the problem of Outgoing Mobility Get endpoint? Until now the EWP model requires that I provide my data, you yours data

[janinamincer-daszkiewicz]

Is there an issue with the approval concerning Outgoing Mobility get?

[demilatof]

Is there an issue with the approval concerning Outgoing Mobility get?

Of course, as concern the IIA-ID inside the sending-hei the specification says: "Clients can fetch more information on this agreement from IIAs API served on the sending HEI's servers"

That is, the specification refers to IIA API, not Approval API. And it says "on the sending HEI's servers" not "on the receiving HEI's servers"; because with your proposal the IIA of sending HEI would be served by the receiving HEI.

In my opinion, your proposal is not compliant with the current specifications of Outgoing Mobility get. I don't understand why we have to over complicate the APIs. Moreover, we may have to upgrade the major version of Approval API.

Could you provide an example of the IIA inside the Approval to understand how could we preserve the namespace?

Anyway, your proposal doesn't solve the initial problem, because at a given time there are two versions for the same IIA-ID:

1. the IIA under review
2. the IIA Approved

I need to know what is your last approved IIA; if you think that's enough my snapshot, I don't need to ask you. Maybe that the IIA in the approval API could be useful for other issues, but not for the one I described above. As a matter of fact, I don't even understand what utility could provide your proposal (and the hash code in Approval API could become useless)

[janinamincer-daszkiewicz]

Of course, as concern the IIA-ID inside the sending-hei the specification says: "Clients can fetch more information on this agreement from IIAs API served on the sending HEI's servers"

That is, the specification refers to IIA API, not Approval API. And it says "on the sending HEI's servers" not "on the receiving HEI's servers"; because with your proposal the IIA of sending HEI would be served by the receiving HEI.

You will still call IIA API get to get the most current version of the IIA. Still all the changes in the IIAs will be handle by the IIA API.

In my opinion, your proposal is not compliant with the current specifications of Outgoing Mobility get. I don't understand why we have to over complicate the APIs. Moreover, we may have to upgrade the major version of Approval API.

Yes. we will have to upgrade the major version anyway. And I see an added value in it. It will be easier, on an organizational level, to switch the network at the same moment in time.

In our opinion it is the easiest way we can solve the problem of changing the major number and not having to re-approve already mutually approved IIAs.

Could you provide an example of the IIA inside the Approval to understand how could we preserve the namespace?

Michał will prepare an example on Monday

Anyway, your proposal doesn't solve the initial problem, because at a given time there are two versions for the same IIA-ID: the IIA under review, the IIA Approved

I need to know what is your last approved IIA; if you think that's enough my snapshot, I don't need to ask you.

The last approved is the one returned by the IIA Approval API. The last under negotiation is the one returned by IIA API.

Maybe that the IIA in the approval API could be useful for other issues, but not for the one I described above. As a matter of fact, I don't even understand what utility could provide your proposal (and the hash code in Approval API could become useless)

I agree the the hash becomes useless and we could as well get rid of it in the same round of changes.

[demilatof]

Of course, as concern the IIA-ID inside the sending-hei the specification says: "Clients can fetch more information on this agreement from IIAs API served on the sending HEI's servers"

That is, the specification refers to IIA API, not Approval API. And it says "on the sending HEI's servers" not "on the receiving HEI's servers"; because with your proposal the IIA of sending HEI would be served by the receiving HEI.

You will still call IIA API get to get the most current version of the IIA. Still all the changes in the IIAs will be handle by the IIA API.

No, you cannot! The most current version may contain huge errors! A mobility is ruled by the approved version of IIA, not by the most current version. For the mobility we need to fetch from the sending HEI the last approved copy of its IIA These are the basis ;-)

In my opinion, your proposal is not compliant with the current specifications of Outgoing Mobility get. I don't understand why we have to over complicate the APIs. Moreover, we may have to upgrade the major version of Approval API.

Yes. we will have to upgrade the major version anyway. And I see an added value in it. It will be easier, on an organizational level, to switch the network at the same moment in time.

Could you explain? If we don't touch the Approval API, we haven't to upgrade its version. How can this change makes easier to switch the network at the same moment in time? The timing on every single node keep on depending of the single development team

In our opinion it is the easiest way we can solve the problem of changing the major number and not having to re-approve already mutually approved IIAs.

I don't see this problem, may you explain? After a few years, this is the first time that I hear that there is the need to re-approve already mutually approved IIA because of a version upgrade of the namespace. Are you saying that thousands of IIAs that are currently approved, as you have shown in stats, should be approved again with the current implementation after the upgrading of the IIA namespace to version 7? I don't know if the providers know this problem. If this need was true, it could mean a poor design of the EWP model.

Indeed, when IIAs are mutually approved, they are approved forever; they have no need to be re-approved because something external is changed. Are they approved with namespace 6? If not modified, they remain approved with version 6, there is no need to re-approve them. It they are modified, they switch to version 7 and everything goes on in the normal way. There is only the need to keep on exchanging them with the version they were formed when approved.

I need to know what is your last approved IIA; if you think that's enough my snapshot, I don't need to ask you.

The last approved is the one returned by the IIA Approval API. The last under negotiation is the one returned by IIA API.

I think that you and @mkurzydlowski should clear what is your proposal, because what you're saying is something different from what Michal said: "No, you should add a snapshot of what you approve (the partner's IIA) " My needs are that the partner returns its copy of its IIA, whilst Michal is saying that the partner would return my copy of the IIA, that is useless for me (I already have my snapshot). The solution proposed by Michal doesn't resolve my problem, your above interpretation might resolve the issue, but is a dangerous mix between IIA-Get and IIA-Approval:

• IIA-Get is to fetch partner's copy of the IIA
• IIA-Approval is to ask the partner if it approved my copy, not to fetch its last approved copy

I agree the the hash becomes useless and we could as well get rid of it in the same round of changes.

It is useless if Approval API provides my copy of the IIA, not if Approval API provides your copy of the IIA. Do you want to add this new feature? Ok, but we still need that the IIA-Get can provide your current IIA Version or the last version you keep and that was approved by me.

[janinamincer-daszkiewicz]

We must be prepared to change the version number of IIA. Better to do it now than later. The changes to the IIA that we are designing will come into force (probably) on January 1, 2024 and they are to serve us for a long time, preferably until the end of the current Erasmus+ programme. We have changes waiting to increase this number, so it's better to release them now. This is also the recommendation of DG EAC.

If so, we can afford changes that are not backward compatible. It is important, however, that they are not too laborious for providers whose implementations are already active in the network.

The purpose of the IIA API is to exchange information about the latest version of IIA. Sometimes it will be a mutually approved version, sometimes a terminated version, sometimes a version under negotiation. Each partner keeps its copy of IIA (live object), creates XML from it in the current format (version, namespace) on request and sends in IIA get response. On a daily basis, in a local system, mobilities are handled on the basis of the latest mutually approved version (if any). Everyone has it, you don't have to ask your partner for it (although you can). Basically, we will ask the partner when the CNR comes or when we suspect that something might have changed on the partner's side. We will also not make changes in our copy that we do not want to have and approve in the future.

The IIA Approval API is a mechanism whose purpose is to obtain proof that the partner has agreed to our copy of IIA. So far, the partner has sent us this consent in the form of a hash. However, this is not enough in the face of changing versions/namespaces, because the hash changes too. Therefore, to have a complete proof, we need to keep the original XML with (embedded) hash. This XML is in the form in which we got it, it can be treated as a string. It is not intended to serve us in the ongoing service of IIAs or mobilities, it only serves as a (static) proof. Since we only care about the most recently mutually approved IIA, we only need to keep proof of that revision (of course, local systems can keep the full history).

The specification states that the partner is required to keep this evidence and submit it to us upon request in the IIA Approval response. But what if he removes it? It is safe to keep it with us locally. If this XML was also signed, we would have non-repudiation. Then the hash would be redundant and it would be enough to keep this signed XML instead of other data certifying that this XML was actually sent to us by the partner.

If I described something inaccurately, Michał will correct it, but only on Monday.

[demilatof]

I think that you're complicating the model without solving the real issues, your explanation is generic and no one of the listed issued seems to me a real problem. Every system may have two versions of the same object at the same time (approved and under review), and therefore it must be able to provide one or the other on request. Doesn't matter if we currently doesn't know why, it's simply a good practice. The Outgoing Mobility get that you're still ignoring is a clear example.

The problem you're describing for approval doesn't exist, you're simply trying to introduce the XML signing. When I send an Approval CNR, I save locally the IIA-ID together with the hash code and the XML of your IIA. If you call later, much later, my Approval API, I will answer you with the saved hash code, independently from the name space. When you receive it, you should already have your IIA stored as XML, and compare its hash code with the one you have received from me. There is no need to calculate in again, eventually with a different namespace version. This solution already exists, you should know.

I try to simplify:

1. If I'm used to store the XML of my IIA, the hash code I receive with the approval is enough (current Approval API)
2. If I'm not used to store the XML of my IIA, how can your solution help me? You provide a full copy of my IIA that I cannot compare with anything else. What prove could it be? In the meantime, the actual data may be changed. For me, you might also have invented some of the conditions it contains... And what should I do? Should I trust in the copy you assert is mine, and change my data according to yours?

The full copy is not a proof, no more than the actual hash code. All depends on how the internal systems are organized, but you don't want to specify anything about this management.

Anyway, if this is your proposal, I think you should open a new topic on GiHub because it is out of the scope of the current thread. But about

The purpose of the IIA API is to exchange information about the latest version of IIA. Sometimes it will be a mutually approved version, sometimes a terminated version, sometimes a version under negotiation.

it's simply a wrong vision because a system is the owner of its version of the IIA and it must be able to provide this data according to client scope. If the client needs to know the cooperation conditions of an IIA to represent a stable situation (for mobilities or whatever we may need in the future), the system must be able to provide the last approved version, not the most recent proposal. No more to say; if we don't accept this point, we have a poor global vision of the possibility to expand the use case of EWP.

[mkurzydlowski]

Could you provide a use-case where you need to request the last approved version from the partner?

You should already have this version as an XML (partners IIA get response) that represent what you approved. A hash is not enough to have a proof if you store it without the full document.

If you need to revert to the last approved version of the IIA you must do it based on a data "snapshot" (structured - not an XML) that you made before modifying your IIA. But this is your data, not something that you should be asking your partner.

[demilatof]

Could you provide a use-case where you need to request the last approved version from the partner?

Here you are: https://github.com/erasmus-without-paper/ewp-specs-api-omobilities/blob/stable-v2/endpoints/get-response.xsd We have "iia-id" for both sending and receiving HEI. I refer to one case (sending), but the other is similar:

Optional ID of the Institutional Agreement based on which the student is being nominated/sent.

That is, not the current IIA, but the one on which the student is being nominated/sent (for me, this means approved).

This ID should be provided by the server ONLY if it implements EWP's Interinstitutional Agreements API. Clients can fetch more information on this agreement from IIAs API served on the sending HEI's servers

And this means that we need this information from the partner, not from the local copy. But, anyway, it's a good practice to allow to fetch the approved copy, if the current one may be different and eventually not approved.

You should already have this version as an XML (partners IIA get response) that represent what you approved. A hash is not enough to have a proof if you store it without the full document.

I don't understand: is this a question for me? Or a specification? I already have a copy of the partner XML, the one I approved; but I don't remember that specifications state that I have to save it. But, in any case, this is not what the api-omobilities requires. And even if I have a local copy, I could have lost it, for any reason, and I want to retrieve it again from the partner. Or simply, since it was not digitally signed, my copy has less validity that the partner's copy.

If you need to revert to the last approved version of the IIA you must do it based on a data "snapshot" (structured - not an XML) that you made before modifying your IIA. But this is your data, not something that you should be asking your partner.

No, I don't need the last approved version for this. There are a lot of use cases that may require the last approved version, but not this. For example, two IROs don't agree with the new version, and they want to revert to the original one, but again they don't agree with the recovered version: one claims that its copy states something, the other one claims that its copy states something different. The possibility to download the partner's approved copy should be clear the misunderstanding (hoping that no one has modified fraudulently the approved version).

I add a point, that is underlying my vision, that I realized today not to be completely true:

If we add as a new specification that in case of performing an IIA-GET with the new last-approved-version set to true, the partner's server doesn't return the last approved IIA building it from its structured data, but serving the XML it has stored when it received the approval (ignoring the current API version), we resolve the great approval problem that we have whenever we have a namespace version upgrade.

When we fetch the XML saved by the partner (and not built from structured data) we may read the version number and know the API version to use to parse it (we should already have that version, we used it to approve...). We have the XML, the hash code and the associated version. The approved data don't generate anymore a new hash code due to the namespace version upgrade (as it could happen if they were represented by the new version of the IIA-Get API). If they need to be changed, they would be exposed with the new IIA-Get and approved again (in this case, the new data are saved with the new XML version, replacing the previous one).

What is not completely true in my vision? That presently EWP doesn't allow even this little document management without a digital signature. But it could be a great step over with a minimal effort.

Do we really want to approve again every IIA when we have a namespace version upgrade?

[mkurzydlowski]

Optional ID of the Institutional Agreement based on which the student is being nominated/sent.

That is, not the current IIA, but the one on which the student is being nominated/sent (for me, this means approved).

The ID is the same.

This ID should be provided by the server ONLY if it implements EWP's Interinstitutional Agreements API. Clients can fetch more information on this agreement from IIAs API served on the sending HEI's servers

And this means that we need this information from the partner, not from the local copy.

True but that still doesn't mean that we the partner shouldn't just server the current version - even if not yet approved.

You should already have this version as an XML (partners IIA get response) that represent what you approved. A hash is not enough to have a proof if you store it without the full document.

I already have a copy of the partner XML, the one I approved; but I don't remember that specifications state that I have to save it.

Saving it seems to currently be the only way to have a proof without relying on the partner.

And even if I have a local copy, I could have lost it, for any reason, and I want to retrieve it again from the partner. Or simply, since it was not digitally signed, my copy has less validity that the partner's copy.

You mustn't rely on your partner - you really should store the object you approve. The "copy" has validity - that's why we introduced the hash.

No, I don't need the last approved version for this. There are a lot of use cases that may require the last approved version, but not this. For example, two IROs don't agree with the new version, and they want to revert to the original one, but again they don't agree with the recovered version: one claims that its copy states something, the other one claims that its copy states something different. The possibility to download the partner's approved copy should be clear the misunderstanding (hoping that no one has modified fraudulently the approved version).

How is taking this data from the partner going to solve misunderstandings? That's too vague. It's everyone's obligation to be able to revert to their last approved version (that they stored locally). Don't complicate this by relying on one another's GET response.

If we add as a new specification that in case of performing an IIA-GET with the new last-approved-version set to true, the partner's server doesn't return the last approved IIA building it from its structured data, but serving the XML it has stored when it received the approval (ignoring the current API version), we resolve the great approval problem that we have whenever we have a namespace version upgrade.

When we fetch the XML saved by the partner (and not built from structured data) we may read the version number and know the API version to use to parse it (we should already have that version, we used it to approve...). We have the XML, the hash code and the associated version. The approved data don't generate anymore a new hash code due to the namespace version upgrade (as it could happen if they were represented by the new version of the IIA-Get API). If they need to be changed, they would be exposed with the new IIA-Get and approved again (in this case, the new data are saved with the new XML version, replacing the previous one).

What is not completely true in my vision? That presently EWP doesn't allow even this little document management without a digital signature. But it could be a great step over with a minimal effort.

Do we really want to approve again every IIA when we have a namespace version upgrade?

That vision is exactly why we suggest to serve the exact XML in the IIA approval. The only difference that you see this data as something that should be sent in IIA get and by the other party.

[demilatof]

True but that still doesn't mean that we the partner shouldn't just server the current version - even if not yet approved.

You skipped some important steps: the first sentence I quoted, but you in some way have ignored, explains that the partner shouldn't serve the current version: "Optional ID of the Institutional Agreement based on which the student is being nominated/sent. Please make me an example of some HEI that opens the nominations on a not approved version. "based on which" doesn't refer to "optional ID" but to "Institutional Agreement". A student is never nominated/sent on an IIA ID, but on an IIA.

Saving it seems to currently be the only way to have a proof without relying on the partner.

If this is the official interpretation, then it should be specified officially. Instead, the official flow chart states something different: "and store the partner hash as the proof" As a matter of fact, this is not a great proof without a digital signature and without the possibility to compare the version that the partner considers approved. For example, I may be sure that this is a proof of some data whilst the partner is convinced of something different. Only comparing the two version I may think that it is a some kind of proof.

And even if I have a local copy, I could have lost it, for any reason, and I want to retrieve it again from the partner. Or simply, since it was not digitally signed, my copy has less validity that the partner's copy.

You mustn't rely on your partner - you really should store the object you approve. The "copy" has validity - that's why we introduced the hash.

Really? Do you think that a copy has validity because it has a well formed hash code? We are far away from any legal meaning of validity... In a master-master model we can have a minimal proof until I can check that what I suppose it's the same you are supposing. And the hash you have introduced is not only useless to give a kind of proof, no more than a random number, but it's even a source of problems in namespace upgrade.

How is taking this data from the partner going to solve misunderstandings? That's too vague. It's everyone's obligation to be able to revert to their last approved version (that they stored locally). Don't complicate this by relying on one another's GET response.

For example, I can see if your IIA, the one you consider approved, is the same I saved as approved. May be one of our systems, or both of them, has made a mistake. Otherwise, we have to ask the partner to share its screen (in Teams, for example). I don't complicate nothing by relying on one another's GET response, is your master-master model that compels me to find a solution to common problems: "None of these HEIs is the "master" of the IIA, all HEIs are "equal". HEI A can access all IIAs related to HEI A stored on HEI B's servers." "HEI A can access all IIAs related to HEI A" means that A can access ALL the IIAs on HEI B's server; and HEI B may have two versions for the same IIA-ID: approved and under review. Nevertheless, they are two different IIAs, and HEI A can access both of them because "HEI A can access all IIAs...".

That vision is exactly why we suggest to serve the exact XML in the IIA approval. The only difference that you see this data as something that should be sent in IIA get and by the other party.

But I think that your approach doesn't solve the problem: the IIA approval API is to approve, you may provide me MY copy of the IIA, the one you've stored as approved. And then? Are you that have to decide if you have to send me a new Approval CNR.

This is a scenario after the namespace upgrade: I retrieve your version with an IIA-Get, I discover that the hash code I tied to the approval I gave you is changed (due to the namespace version upgrade); therefore I may think that I have to send you a new Approval CNR, even if the IIA is the same. This is what triggers the necessity to re-approve all the IIAs over the EWP network.

If I can get your "last approved version" as a snapshot of the XML (old namespace), I could see that the last approved version is still valid (the hash code is the same I saved). I need to receive your IIA-CNR to restart the approval process. A step over could be adding into the IIA a new element with the date of the last IIA-CNR sent, so if I retrieve it with a straight IIA-GET I can distinguish if you have asked me to fetch a new version or not (the hash code may mislead me), even if I missed the IIA CNR.

How can your solution avoid approving again all the IIAs? I think that as a minimum, you should think to include both of the IIAs in the approval API (if they are available).

(doing so we'll soon discover that at some point I have approved your N-version whilst until you will not approve my N-version, you still stuck with my N-1 version: the same IIA-ID is mutually approved, but no more the same IIA: data are different)

[mkurzydlowski]

But which approved IIA version should a mobility be linked to? There is no way of knowing if it changed after the mobility has been created. The most we can do is link it by IIA id, as it is currently. Adding the ability to ask the partner for his last approved version doesn't change things.

The hash is a proof as one can verify that it corresponds to the IIA XML that is kept with it.

But I think that your approach doesn't solve the problem: the IIA approval API is to approve, you may provide me MY copy of the IIA, the one you've stored as approved. And then? Are you that have to decide if you have to send me a new Approval CNR.

I don't understand your objections. There is no need to resend the Approval CNR. Storing the IIA XML enables us to be independent of any IIA version changes.

The benefit of storing the IIA XML in the approval is that we are one step from signing such IIA and getting rid of hash if people ever decide to go that way.

[mkurzydlowski]

I retrieve your version with an IIA-Get, I discover that the hash code I tied to the approval I gave you is changed (due to the namespace version upgrade); therefore I may think that I have to send you a new Approval CNR, even if the IIA is the same. This is what triggers the necessity to re-approve all the IIAs over the EWP network.

You shouldn't be taking action if you didn't receive an IIA CNR and you shouldn't receive one after version update.

But if you do ask IIA GET without receiving a CNR then you should not compare the hash with anything you might have saved locally if IIA version changed.

[demilatof]

But which approved IIA version should a mobility be linked to? There is no way of knowing if it changed after the mobility has been created. The most we can do is link it by IIA id, as it is currently. Adding the ability to ask the partner for his last approved version doesn't change things.

Really? You should know it... Why do you think that the European Inter-institutional agreement templates 2021-2027 states that "in case of changes in the mobility data by no later than the end of January in the preceding academic year"? Just to make us waste time?

Any approved version is good, because the mobility is linked to that, since it cannot be changed after the applications and nomination started. And if it was too late, a partner can deny the approval of changes anyway. This is the reason I strongly suggested to implement the modify to split the cooperation conditions: any further IIA doesn't touch the previous academic years, and therefore the mobility is always linked to the IIA version on which the student is being nominated/sent (the under review version may still contain mistakes in this step). As you can see, the ability to ask the partner for his last approved version makes the difference!

The hash is a proof as one can verify that it corresponds to the IIA XML that is kept with it.

But I think that your approach doesn't solve the problem: the IIA approval API is to approve, you may provide me MY copy of the IIA, the one you've stored as approved. And then? Are you that have to decide if you have to send me a new Approval CNR.

I don't understand your objections. There is no need to resend the Approval CNR. Storing the IIA XML enables us to be independent of any IIA version changes.

Again, really? I fetch your IIA and I discover that its hash code is changed (due to the namespace upgrade). Obviously I have to resend the Approval CNR, why shouldn't I? Because I call for your approval and you provide me my copy? And your copy of my IIA what has to deal with your IIA? Should I use my local copy of your IIA to check field by field if your IIA (with new hash code) is still the same?

The benefit of storing the IIA XML in the approval is that we are one step from signing such IIA and getting rid of hash if people ever decide to go that way.

May be, but we are far away from that moment and at this point I'm afraid of where could lead us a global digital signing. In any case, at that moment we could get rid of the hash, but not of the last approved version (see above, unless you change the specifications of the Outgoing Mobility Get endpoint). Currently the hash triggers the approval and if you only serve my copy of XML with Approval API you don't avoid this need. Please describe a scenario to make an example to support your solution.

You shouldn't be taking action if you didn't receive an IIA CNR and you shouldn't receive one after version update.

Again: really? Where is written? Not here, by sure. You know, we can miss IIA CNR, and we can retrieve IIAs thanks to the IIA Index API. We cannot know if we missed the IIA CNR or it was not sent due to there was not need to send it. What we can see is that there is a new IIA version because it has a different hash code. If we don't do so, how can we know that we have to send a new Approval CNR?

But if you do ask IIA GET without receiving a CNR then you should not compare the hash with anything you might have saved locally if IIA version changed.

And therefore it is a new IIA for me and I have to approve it again. Do you realize this? Or in your implementation, you ignore that I need a new approval, if I made a change after the version upgrade and you missed my IIA CNR? And here can play a role my proposal to add <last-CNR-sent-on-date> in the general section of the IIA, may be under the first partner section.

I think that after years you should inspect how other providers have implemented the EWP logic, because I suspect that our implementation, needs and controls are not as you imagine. We may have different solutions, but I'm quite sure that we share some similar assumptions that are a bit different from what you think.

[mkurzydlowski]

I fetch your IIA and I discover that its hash code is changed (due to the namespace upgrade). Obviously I have to resend the Approval CNR, why shouldn't I? Because I call for your approval and you provide me my copy? And your copy of my IIA what has to deal with your IIA? Should I use my local copy of your IIA to check field by field if your IIA (with new hash code) is still the same?

Currently the hash triggers the approval and if you only serve my copy of XML with Approval API you don't avoid this need. Please describe a scenario to make an example to support your solution.

What we can see is that there is a new IIA version because it has a different hash code. If we don't do so, how can we know that we have to send a new Approval CNR?

If someone asks for IIA by himself (for example when he believes that an IIA CNR might be lost) and notices a change in the IIA version then he should indeed compare the IIA with what he has stored. No need to approve it if we don't detect a change. I don't see how your solution might make this less painful.

Or in your implementation, you ignore that I need a new approval, if I made a change after the version upgrade and you missed my IIA CNR?

If you made a change while upgrading then it will be detected in that comparison.

[demilatof]

If someone asks for IIA by himself (for example when he believes that an IIA CNR might be lost) and notices a change in the IIA version then he should indeed compare the IIA with what he has stored. No need to approve it if we don't detect a change. I don't see how your solution might make this less painful.

So you're telling me that I have to compare the IIA with what I have stored? And how do you do? If I'm not wrong @milsorm was asking for an ID in every single cooperation conditions. It may be useful, but without that ID you cannot compare automatically two IIA, they may be the same but with different orders in cooperation conditions. Have you implemented such a solution? May you explain deeper?

Anyway, the hash code was introduced right to detect a change in the IIA:

However HEI B needs some proof that this agreement has not been changed by HEI A after HEI B has last seen it. To reference and approve a particular version (copy) of the partner’s agreement, HEIs attach to each agreement a digest (hash) of the cooperating conditions of this agreement (see here for details)

I hope that the solutions you propose be compliant to the specifications you wrote

[mkurzydlowski]

So you're telling me that I have to compare the IIA with what I have stored? And how do you do? If I'm not wrong @milsorm was asking for an ID in every single cooperation conditions. It may be useful, but without that ID you cannot compare automatically two IIA, they may be the same but with different orders in cooperation conditions.

If the IIA version changed then there is no other way to tell the difference.

Why would the partner change the order of cooperation conditions? If he did then he should theoretically also send an IIA CNR. But how does this impact this discussion?

Anyway, the hash code was introduced right to detect a change in the IIA.

It was introduced to enable IIA approval with a proof. It can also be used to detect change as stated but this is limited to a single IIA version.

[demilatof]

If the IIA version changed then there is no other way to tell the difference.

Do you think? Instead, there are, for example adding e new element to the general section of the IIA. This integrates your assumption that an IIA needs to be re-approved if we receive an IIA-CNR (that we could miss). If the IIA reminds us when an IIA-CNR was sent, we can compare this date with the one we saved when we sent the Approval CNR (we have to save the approval date). It the IIA-CNR date is more recent than our Approval CNR date, most probably a new approval is required.

Why would the partner change the order of cooperation conditions? If he did then he should theoretically also send an IIA CNR.

Simply because it can, being that is not forbidden by the specifications. You talk about an IIA CNR that, again, we can have missed. But anyway it is not true that theoretically the partner has to send an IIA CNR, because the data is not changed, the IIA is not changed and only the order is changed when he creates the XML (e.g. the partner found more comfortable changing the order)

But how does this impact this discussion?

In the sense that the actual XML structure and specifications cannot allow you to compare a saved version with a fresh one with the possibility to be 100% sure that there is a real change.

Anyway, the hash code was introduced right to detect a change in the IIA.

It was introduced to enable IIA approval with a proof. It can also be used to detect change as stated but this is limited to a single IIA version.

Yes, we are realizing that this is true, but it is not written anywhere. Therefore, it could be used always.

I'm still waiting a suggestion on how implementing a comparison from two XML of different version and being sure that they are the same and there is no need for a new approval.

[janinamincer-daszkiewicz]

I agree that this issue is about the extra parameter for the IIA get, to obtain the last approved version. I do not see any strong support for this idea from the other providers. The issue is open and anybody can contribute.

Saying that I come back to https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/109 for the more important discussion on how to make sure that nobody will have a problem with the change of the name space and nobody will trigger re-approvals due to such a technical change.

[umesh-qs]

Does it means we have to keep 2 versions of the IIA. one draft and on last approved? Do we really need to keep 2 versions? Mobility process should stop if you are negotiating the approved IIA that is linked to the mobility

[janinamincer-daszkiewicz]

Does it means we have to keep 2 versions of the IIA. one draft and on last approved? Do we really need to keep 2 versions? Mobility process should stop if you are negotiating the approved IIA that is linked to the mobility

This question is rather business than technically oriented. @pleys @kamil-olszewski-uw please comment.

I personally think that the mobility process can not stop, that changes are most probably related to the future academic years.

[umesh-qs]

If there a need of the latest approved copy all the time, then there is no other way but to keep 2 versions. This will be against what was decided earlier (which we do not prefer) that there should not be any drafts in the system and IIAs cannot be hidden. So in that sense it is also technically linked.

[janinamincer-daszkiewicz]

If there a need of the latest approved copy all the time, then there is no other way but to keep 2 versions. This will be against what was decided earlier (which we do not prefer) that there should not be any drafts in the system and IIAs cannot be hidden. So in that sense it is also technically linked.

What you call 'draft' is a version under negotiation and it should not be hidden. You want/should to show it to the partner. It wouldn't be hidden it it would be the first version. This is the consequence of the decision that once approved version can be modified.

[umesh-qs]

@janinamincer-daszkiewicz this is not new. Approved versions were always allowed to be modified. So let's not try to portray this as something new.

[kamil-olszewski-uw]

Does it means we have to keep 2 versions of the IIA. one draft and on last approved? Do we really need to keep 2 versions? Mobility process should stop if you are negotiating the approved IIA that is linked to the mobility

This question is rather business than technically oriented. @pleys @kamil-olszewski-uw please comment.

I personally think that the mobility process can not stop, that changes are most probably related to the future academic years.

It would be best if @pleys answered us, but it seems obvious to me that whatever decision is made here, related workflows and technical aspects must not interfere with business matters in the form of a temporary stop of the mobility process.

[umesh-qs]

Does it means we have to keep 2 versions of the IIA. one draft and on last approved? Do we really need to keep 2 versions? Mobility process should stop if you are negotiating the approved IIA that is linked to the mobility

This question is rather business than technically oriented. @pleys @kamil-olszewski-uw please comment. I personally think that the mobility process can not stop, that changes are most probably related to the future academic years.

It would be best if @pleys answered us, but it seems obvious to me that whatever decision is made here, related workflows and technical aspects must not interfere with business matters in the form of a temporary stop of the mobility process.

How can you start a new mobility, if your contract is under re-negotiation?

[demilatof]

How can you start a new mobility, if your contract is under re-negotiation?

You may change only the mobilities after a given date, the previous should remain still valid (the cooperation conditions may change exceptionally at any moment only it there is a mutual agreement). In this way, we can start applications and nominations using the approved mobilities, that are not under review

This is why I think it could be useful:

1. Split cooperation condition to modify a given mobility
2. Have the possibility to fetch the last approved version from the partner (I may have a snapshot, but I want to be sure, in every moment, that it is the same the partner considers approved)

[demilatof]

From the presentation for the IF meeting on the coming Wednesday:

"If the partners do not reach the conclusion they should revert back to the last mutually approved version" If we have the possibility to retrieve the snapshot with a new parameter in IIA-Get, we can forget this point and the partners can take their time.

Otherwise: how long they must wait before reverting back to the last mutually approved version?