Uniqueness of IIA code

[Emkas]

According to the specification iia-code is 'not used to directly identify entities': https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/84cf84ce6c6322942cb697a95b1d64074d4dc863/endpoints/get-response.xsd#L117-L128

It seems a little bit contradictory to the description of request parameters for GET: https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/84cf84ce6c6322942cb697a95b1d64074d4dc863/endpoints/get.md?plain=1#L45-L50

If the requester provides a list of iia_code values, they are used to uniquely identify the requested IIAs.

In our implementation we do not plan to keep track of deleted IIAs. They are identified by GUIDs, we can assume that each newly generated GUID is unique. But it need not be the case for iia_code, which is human-readable. So the options are to either enforce their uniqueness or keep track of those which have been deleted. The last option - which would however effect the specification - would be to remove iia_code as an option for a GET request parameter.

Is anybody of the providers using iia_codes in IIA GET?

[demilatof]

Is anybody of the providers using iia_codes in IIA GET?

For unige.it, not yet in production, iia_code is identical to iia_id, both of them human readable. If we receive am IIA GET with iia_code, we manage it as if we have received an iia_id.

We will not behave as the EWP police service, therefore we will not check if a partner uses a new iia_id or the same that he previously deleted

[janinamincer-daszkiewicz]

we will not check if a partner uses a new iia_id or the same that he previously deleted

What about unige.it? All iia_codes will be unique, never reused?

[janinamincer-daszkiewicz]

What about unige.it? All iia_codes will be unique, never reused?

I guess so, otherwise you could not have iia_id=iia_code.

[demilatof]

What about unige.it? All iia_codes will be unique, never reused?

As I said, all iia_codes are identical to the iia_ids and iia_ids are our key in the database, therefore all the iia_codes are unique and consequently never reused.

iia_id=iia_code=IIA

If this is what you asked me.

Are these iia_codes generated automatically or entered by a user?

For us, they are automatically generated (since the iia_ids are automatically generated)

[janinamincer-daszkiewicz]

So you don't have a problem described by Emil.

[demilatof]

So you don't have a problem described by Emil.

I was answering to his last question: Is anybody of the providers using iia_codes in IIA GET?

Anyway, I don't understand how could be an iia_code not unique, even if not explicitly stated. If it can be used to retrieve an IIA, it must be unique. If it is not, what should could happen? I receive an iia_code in IIA GET, and I return two or more IIAs?

[janinamincer-daszkiewicz]

At any moment in the local database iia_code is unique. The system can easily enforce that. However when IIA is deleted, iia_codes cannot be reused. So they have to be generated automatically (as in unige.it), or - in case they are entered by the end user - the system has to remember the ones removed to enforce (universal) uniqueness.

[demilatof]

in case they are entered by the end user - the system has to remember the ones removed to enforce (universal) uniqueness

An iia_code entered by the end user is prone to duplication anyway; they have to check that it is unique, always. From our point of view, we invoke IIA GET by IIA ID and use it as a key for partner's IIA. The iia_code is shown in the IRO's GUI; if it is duplicated or reused by the partner, it doesn't put us in trouble

[janinamincer-daszkiewicz]

An iia_code entered by the end user is prone to duplication anyway; they have to check that it is unique, always.

As I said, enforcing uniqueness in any particular moment is not a problem - system checks against other objects stored in the database. Reusing would also not be a problem if iia_codes would not be used in GET.

The iia_code is shown in the IRO's GUI; if it is duplicated or reused by the partner, it doesn't put us in trouble

Not quite. If it is reused by the partner and by an accident you missed CNR from the partner informing you about deletion, the user from your system may use the partner's iia_code having the deleted object in mind while it now identifies the new object.

[demilatof]

Not quite. If it is reused by the partner and by an accident you missed CNR from the partner informing you about deletion, the user from your system may use the partner's iia_code having the deleted object in mind while it now identifies the new object.

It depends on the implementation; we will ignore anyway the CNR about a deletion. If we don't find the IIA, we mark it as unavailable in the local system. Our IROs never search an IIA by the IIA id or code; they chose the IIA from a list based on IIA IDs. If there are multiple identical IIA codes they have no problem; if talking to the partner they discover that the partner has some IIA active with the same code, the problem belongs to the partner, that has to correct them.

I add a consideration about the deletion; the actual implementation, that has been voted, can force unwanted deletion. I try to be schematic:

1. I modify my IIA and I send you an IIA CNR
2. Your response is 200, but your system fetches the IIA every hour, for example
3. In the meantime I have a trouble/maintenance/whatever else in my system, and I can't serve any IIA
4. Your system performs an IIA GET to my API, that can't find nothing in my DB and my API returns nothing
5. By specification you have to consider my previous CNR as a deletion CNR, because my answer is empty
6. You delete your IIA associated to mine and send me an IIA CNR
7. In the meantime my DB is back again, I receive your IIA CNR and immediately after, I get your IIA, it's empty and I delete my IIA

The two IIAs are gone, but none of us wanted that. And we cannot recover, because the IIA ids cannot be reused; we have to start over to enter again the same information, with a new IIA Ids. And this could make problems in our system, because the IDs are tied to other internal process.

This is why we will never delete anything, and if we don't find an IIA (point 5) we will simply consider it as unavailable without going through step 6 and 7.

[umesh-qs]

Not quite. If it is reused by the partner and by an accident you missed CNR from the partner informing you about deletion, the user from your system may use the partner's iia_code having the deleted object in mind while it now identifies the new object.

It depends on the implementation; we will ignore anyway the CNR about a deletion. If we don't find the IIA, we mark it as unavailable in the local system. Our IROs never search an IIA by the IIA id or code; they chose the IIA from a list based on IIA IDs. If there are multiple identical IIA codes they have no problem; if talking to the partner they discover that the partner has some IIA active with the same code, the problem belongs to the partner, that has to correct them.

I add a consideration about the deletion; the actual implementation, that has been voted, can force unwanted deletion. I try to be schematic:

1. I modify my IIA and I send you an IIA CNR
2. Your response is 200, but your system fetches the IIA every hour, for example
3. In the meantime I have a trouble/maintenance/whatever else in my system, and I can't serve any IIA
4. Your system performs an IIA GET to my API, that can't find nothing in my DB and my API returns nothing
5. By specification you have to consider my previous CNR as a deletion CNR, because my answer is empty
6. You delete your IIA associated to mine and send me an IIA CNR
7. In the meantime my DB is back again, I receive your IIA CNR and immediately after, I get your IIA, it's empty and I delete my IIA

The two IIAs are gone, but none of us wanted that. And we cannot recover, because the IIA ids cannot be reused; we have to start over to enter again the same information, with a new IIA Ids. And this could make problems in our system, because the IDs are tied to other internal process.

This is why we will never delete anything, and if we don't find an IIA (point 5) we will simply consider it as unavailable without going through step 6 and 7.

@demilatof all this is already discussed. I wonder why there is still a confusion. Everyone voted for permanent DELETE except for us. And now you are mentioning the same scenarios that someone in the IF call labelled are artificial scenario(s) and no one objected at that time. How can you have your own interpretation of DELETE? Deleted IIAs (IIA ID or Code) must never be re-used.

[demilatof]

@demilatof all this is already discussed. I wonder why there is still a confusion. Everyone voted for permanent DELETE except for us. And now you are mentioning the same scenarios that someone in the IF call labelled are artificial scenario(s) and no one objected at that time. How can you have your own interpretation of DELETE? Deleted IIAs (IIA ID or Code) must never be re-used.

There is not confusion; I will always recall this problem, because it's the reason of our choice. I haven't my interpretation of DELETE, I have my own strategy for useless IIAs. Could you or someone else compel me to delete an IIA I'm no more interested in? Could you or someone else compel me to flag, in my system, as deleted and not unavailable an IIA that I cannot find anymore on the network?

If I keep on exposing all of my IIAs to EWP network, I simply implement a workaround to an unpleasant delete specification.

The deletion is represented to BPO (ad IROs) as a great solution to clean up the database; when I explain that we can have a deletion in another way and I describe this scenario, they don't enjoy so much this solution. Anyway, this is it, but not in my name: wink:

[umesh-qs]

@demilatof all this is already discussed. I wonder why there is still a confusion. Everyone voted for permanent DELETE except for us. And now you are mentioning the same scenarios that someone in the IF call labelled are artificial scenario(s) and no one objected at that time. How can you have your own interpretation of DELETE? Deleted IIAs (IIA ID or Code) must never be re-used.

There is not confusion; I will always recall this problem, because it's the reason of our choice. I haven't my interpretation of DELETE, I have my own strategy for useless IIAs. Could you or someone else compel me to delete an IIA I'm no more interested in? Could you or someone else compel me to flag, in my system, as deleted and not unavailable an IIA that I cannot find anymore on the network?

If I keep on exposing all of my IIAs to EWP network, I simply implement a workaround to an unpleasant delete specification.

The deletion is represented to BPO (ad IROs) as a great solution to clean up the database; when I explain that we can have a deletion in another way and I describe this scenario, they don't enjoy so much this solution. Anyway, this is it, but not in my name: wink:

The way you described, it seems that there is a possibility in your system of marking something unavailable for some time and the allow reuse of the same IIA ID/Code. If you have trouble in your system and you send 200 empty response in IIA GET. You cannot reuse those IIA IDs/Code. So as long as your local changes are not impacting the network, you can do whatever you want within your system.

[demilatof]

The way you described, it seems that there is a possibility in your system of marking something unavailable for some time and the allow reuse of the same IIA ID/Code. If you have trouble in your system and you send 200 empty response in IIA GET. You cannot reuse those IIA IDs/Code. So as long as your local changes are not impacting the network, you can do whatever you want within your system.

Exactly, you catch the point: from the EWP perspective you keep on seeing all my IIAs as always. From my IRO point of view, some out IIA may be "parked" and hidden, but they are always available to EWP world. You can bind them to yours and approve them, but until we don't approve your IIAs, they worth nothing.

If you notify us (CNR) that you have deleted something, we thank you, but for us it is simply unavailable. We'll never delete or copy of your IIA or our IIA bound to you due to your missing IIA.

[umesh-qs]

The way you described, it seems that there is a possibility in your system of marking something unavailable for some time and the allow reuse of the same IIA ID/Code. If you have trouble in your system and you send 200 empty response in IIA GET. You cannot reuse those IIA IDs/Code. So as long as your local changes are not impacting the network, you can do whatever you want within your system.

Exactly, you catch the point: from the EWP perspective you keep on seeing all my IIAs as always. From my IRO point of view, some out IIA may be "parked" and hidden, but they are always available to EWP world. You can bind them to yours and approve them, but until we don't approve your IIAs, they worth nothing.

And what happens when partner of your client pulls the hidden IIA and maps it with their IIA and sends you the CNR. You will make that IIA visible to your client?

If you notify us (CNR) that you have deleted something, we thank you, but for us it is simply unavailable. We'll never delete or copy of your IIA or our IIA bound to you due to your missing IIA.

This means that if I delete an IIA and re-use it you will allow you clients to re-use it?

[demilatof]

And what happens when partner of your client pulls the hidden IIA and maps it with their IIA and sends you the CNR. You will make that IIA visible to your client?

I don't think they want to map our hidden IIA... If it's hidden, we will serve it almost empty even if internally we still save it with all the information. We may send a CNR to inform that it has been emptied, but in any case we can revert whenever we want.

If you notify us (CNR) that you have deleted something, we thank you, but for us it is simply unavailable. We'll never delete or copy of your IIA or our IIA bound to you due to your missing IIA.

This means that if I delete an IIA and re-use it you will allow you clients to re-use it?

Of course, I'm not the investigating service of EWP; you can do whatever you want with your IIA ids, provided that:

• you don't delete a mutual approved IIA
• your recovered IIA Id is still unique among your IIAs

[umesh-qs]

And what happens when partner of your client pulls the hidden IIA and maps it with their IIA and sends you the CNR. You will make that IIA visible to your client?

I don't think they want to map our hidden IIA... If it's hidden, we will serve it almost empty even if internally we still save it with all the information. We may send a CNR to inform that it has been emptied, but in any case we can revert whenever we want.

You can revert internally. But once you have sent 200 empty response, you cannot send non empty response on the same IIA ID forever.

If you notify us (CNR) that you have deleted something, we thank you, but for us it is simply unavailable. We'll never delete or copy of your IIA or our IIA bound to you due to your missing IIA.

This means that if I delete an IIA and re-use it you will allow you clients to re-use it?

Of course, I'm not the investigating service of EWP; you can do whatever you want with your IIA ids, provided that:

• you don't delete a mutual approved IIA
• your recovered IIA Id is still unique among your IIAs

As per the specification of DELETE, IIA ID cannot be used forever and hence cannot be recovered.

[demilatof]

And what happens when partner of your client pulls the hidden IIA and maps it with their IIA and sends you the CNR. You will make that IIA visible to your client?

I don't think they want to map our hidden IIA... If it's hidden, we will serve it almost empty even if internally we still save it with all the information. We may send a CNR to inform that it has been emptied, but in any case we can revert whenever we want.

You can revert internally. But once you have sent 200 empty response, you cannot send non empty response on the same IIA ID forever.

Where is written the number of times I can send an empty IIA or the time of life of empty IIAs? The rules are for deleted IIAs, the rule says that I have to expose IIA ready for approval (they were so, when published first time), not that I can rewrite them later. There is no rule that says when I have to permanently delete an IIA at a given point.

If you notify us (CNR) that you have deleted something, we thank you, but for us it is simply unavailable. We'll never delete or copy of your IIA or our IIA bound to you due to your missing IIA.

This means that if I delete an IIA and re-use it you will allow you clients to re-use it?

Of course, I'm not the investigating service of EWP; you can do whatever you want with your IIA ids, provided that:

• you don't delete a mutual approved IIA
• your recovered IIA Id is still unique among your IIAs

As per the specification of DELETE, IIA ID cannot be used forever and hence cannot be recovered.

The rule is valid for a deleted IIA. I don't delete anything, my IIA Ids remain valid forever. The specification says that if you delete, you cannot recover the IIA id, not that I have to check that you're respecting the rule. I don't want to implement a useless table of deleted IIA Ids per HEI just to reject your IIA with a recovered Id.

How can I reject an IIA? The specification says nothing. I have to inform my IRO to call your IRO to complain about the reused ID? Really? And then?

Important Rules

An IIA that has not been mutually approved can be deleted by removing it from the EWP network

can, NOT MUST!

An IIA can be removed from the EWP network only if it is permanently deleted

I dont't permanently delete anything

Identifiers of the deleted objects MUST NOT be reused for new IIAs.

Where is said that I have to check who respect or not this rule?

A short recap:

• You notify me a reused IIA Id by means of the Index or the IIA CNR
• What should I do to discover that it has been reused?
• And even if I discover it, remember that I have to accept an IIA CNR and the contents of an IIA Index, I cannot object anything. Should I not fetch the IIA? And then?

If you like waste your times just to discover something that is useless for you, have a good luck.

[umesh-qs]

And what happens when partner of your client pulls the hidden IIA and maps it with their IIA and sends you the CNR. You will make that IIA visible to your client?

I don't think they want to map our hidden IIA... If it's hidden, we will serve it almost empty even if internally we still save it with all the information. We may send a CNR to inform that it has been emptied, but in any case we can revert whenever we want.

You can revert internally. But once you have sent 200 empty response, you cannot send non empty response on the same IIA ID forever.

Where is written the number of times I can send an empty IIA or the time of life of empty IIAs? The rules are for deleted IIAs, the rule says that I have to expose IIA ready for approval (they were so, when published first time), not that I can rewrite them later. There is no rule that says when I have to permanently delete an IIA at a given point.

If you notify us (CNR) that you have deleted something, we thank you, but for us it is simply unavailable. We'll never delete or copy of your IIA or our IIA bound to you due to your missing IIA.

This means that if I delete an IIA and re-use it you will allow you clients to re-use it?

Of course, I'm not the investigating service of EWP; you can do whatever you want with your IIA ids, provided that:

• you don't delete a mutual approved IIA
• your recovered IIA Id is still unique among your IIAs

As per the specification of DELETE, IIA ID cannot be used forever and hence cannot be recovered.

The rule is valid for a deleted IIA. I don't delete anything, my IIA Ids remain valid forever. The specification says that if you delete, you cannot recover the IIA id, not that I have to check that you're respecting the rule. I don't want to implement a useless table of deleted IIA Ids per HEI just to reject your IIA with a recovered Id.

How can I reject an IIA? The specification says nothing. I have to inform my IRO to call your IRO to complain about the reused ID? Really? And then?

Important Rules

An IIA that has not been mutually approved can be deleted by removing it from the EWP network

can, NOT MUST!

An IIA can be removed from the EWP network only if it is permanently deleted

I dont't permanently delete anything

Identifiers of the deleted objects MUST NOT be reused for new IIAs.

Where is said that I have to check who respect or not this rule?

A short recap:

• You notify me a reused IIA Id by means of the Index or the IIA CNR
• What should I do to discover that it has been reused?
• And even if I discover it, remember that I have to accept an IIA CNR and the contents of an IIA Index, I cannot object anything. Should I not fetch the IIA? And then?

If you like waste your times just to discover something that is useless for you, have a good luck.

@demilatof I will not get into the problems that come with how DELETE is being enforced (with blessing from you and others during voting). But, for now what you are doing or planning to do is not as per specification. If you recover an IIA that you send to us as DELETED (empty 200 response) earlier, we will report to EWP monitoring API as you will not be following the specs at that point. We will also report to EWP monitoring API if you are still using our DELETED IIA in any of your GET responses.

[demilatof]

@demilatof I will not get into the problems that come with how DELETE is being enforced (with blessing from you and others during voting). But, for now what you are doing or planning to do is not as per specification. If you recover an IIA that you send to us as DELETED (empty 200 response) earlier, we will report to EWP monitoring API as you will not be following the specs at that point. We will also report to EWP monitoring API if you are still using our DELETED IIA in any of your GET responses.

@umesh-qs please be careful in becoming ridiculous with your obsession with the rules... You pretend to be entitled to report to EWP monitoring API specification infringing that do not exist and that you have to prove.

1. You assert that what I'm planning to do is not as per specification, I show you that the specification doesn't forbid my strategy, and you have not been able to show me the contrary
2. Please read again: I'll never send you an IIA Get Response without an IIA, but with an IIA without mobilities in cooperation-conditions. If you report this as deleted, I'll report you on my turn. Are you the one who has a bad implementation in this case.
3. Again, if you will "report to the EWP monitoring API if you are still using our DELETED IIA in any of your GET response" are you the one with a bad interpretation of the rules and of the EWP communication system: no one can use partner's IIA in his get response, the only thing that he can do it's using the IIA ID of a partner's deleted IIA. But that IIA Id is forbidden to be used it for new IIAs but it's not forbidden to keep it in our old IIA as ID for the IIA you have deleted . And this is logic, because yours IIA CNR could be lost and anyway I can delay my call to your IIA-GET API until I need your (deleted) IIA. No rule imposes me time of reaction. In the mean time, you can fetch my IIA tied to your deleted IIA and you cannot report anything.

Finally, if you report my behavior of EWP monitoring system charging me with specification infringing, and you don't want that I charge you with defamation, you have to:

1. keep track of your deleted IIA IDs
2. keep track of my deleted IIA IDs
3. keep track of: your IIA CNR to notify a deleted IIA, my response to CNR, my IIA-Get and your response
4. keep track of: my IIA CNR to notify a modified IIA (I don't delete anything), tour IIA-GET and my response with IIA (and empty cooperation conditions)
5. keep track of the timestamp for any of the above operations
6. demonstrate that the reused IIA ID belongs to a deleted IIA. To prove this thing you have to show the deleted IIA as a proof, but if you can show it, it means that you have not permanently deleted it (are you infringing the rule? :thinking: )

Feel free to do all of this, but not to report me for your bad interpretations of rules; if you'll report me for this reason several times, you could be charged with stalking. :stuck_out_tongue_winking_eye:

[umesh-qs]

@demilatof I will not get into the problems that come with how DELETE is being enforced (with blessing from you and others during voting). But, for now what you are doing or planning to do is not as per specification. If you recover an IIA that you send to us as DELETED (empty 200 response) earlier, we will report to EWP monitoring API as you will not be following the specs at that point. We will also report to EWP monitoring API if you are still using our DELETED IIA in any of your GET responses.

@umesh-qs please be careful in becoming ridiculous with your obsession with the rules... You pretend to be entitled to report to EWP monitoring API specification infringing that do not exist and that you have to prove.

1. You assert that what I'm planning to do is not as per specification, I show you that the specification doesn't forbid my strategy, and you have not been able to show me the contrary
2. Please read again: I'll never send you an IIA Get Response without an IIA, but with an IIA without mobilities in cooperation-conditions. If you report this as deleted, I'll report you on my turn. Are you the one who has a bad implementation in this case.
3. Again, if you will "report to the EWP monitoring API if you are still using our DELETED IIA in any of your GET response" are you the one with a bad interpretation of the rules and of the EWP communication system: no one can use partner's IIA in his get response, the only thing that he can do it's using the IIA ID of a partner's deleted IIA. But that IIA Id is forbidden to be used it for new IIAs but it's not forbidden to keep it in our old IIA as ID for the IIA you have deleted . And this is logic, because yours IIA CNR could be lost and anyway I can delay my call to your IIA-GET API until I need your (deleted) IIA. No rule imposes me time of reaction. In the mean time, you can fetch my IIA tied to your deleted IIA and you cannot report anything.

Finally, if you report my behavior of EWP monitoring system charging me with specification infringing, and you don't want that I charge you with defamation, you have to:

1. keep track of your deleted IIA IDs
2. keep track of my deleted IIA IDs
3. keep track of: your IIA CNR to notify a deleted IIA, my response to CNR, my IIA-Get and your response
4. keep track of: my IIA CNR to notify a modified IIA (I don't delete anything), tour IIA-GET and my response with IIA (and empty cooperation conditions)
5. keep track of the timestamp for any of the above operations
6. demonstrate that the reused IIA ID belongs to a deleted IIA. To prove this thing you have to show the deleted IIA as a proof, but if you can show it, it means that you have not permanently deleted it (are you infringing the rule? 🤔 )

Feel free to do all of this, but not to report me for your bad interpretations of rules; if you'll report me for this reason several times, you could be charged with stalking. 😜

I am just following the rules which are same for all. Obsession is probably what you trying to do to prove that the process you want to follow is better (and may be it is). But you alone cannot do something that is not allowed, even if it is better. If you see my comment, I have already mentioned the scenarios that will be reported. It has nothing to do with what you do in your internal system. So you may call it stalking, you may call it defamation, but we will not get intimidated by your unwanted outburst. We will go by what was voted for and had been agreed by majority, even though we believe that the solution is problematic.

[demilatof]

I am just following the rules which are same for all.

I'm still waiting you prove me what rule I would infringe with my solution. Please stop blah blah and show me where is forbidden to keep your deleted IIA ID in my IIA and how long. Please show me where I'm compelled to delete an IIA and not to show it as empty and how long.

You're interpreting the rules on your feeling

[umesh-qs]

I am just following the rules which are same for all.

I'm still waiting you prove me what rule I would infringe with my solution. Please stop blah blah and show me where is forbidden to keep your deleted IIA ID in my IIA and how long. Please show me where I'm compelled to delete an IIA and not to show it as empty and how long.

As I already said, you can keep in you system, but not send it when I we do a get request on any of your IIA. Reporting to monitoring API is a way to get things correct. Problem is when you don't fix it. So if you fix before next weeks monitoring stats then it will not be reported.

You're interpreting the rules on your feeling

@demilatof I am being very professional in my choice of words. And I expect you to do the same. Please do not carried away in defending what you are doing. I have already mentioned the 2 scenarios where we will report. If you do not fall in those cases then you need not worry. If you think reporting on those 2 cases is not as per what was voted for, then please point out and I am willing to take it back. If not then I will rest at this, and will let others comment specially DG EAC or EWP tech representatives.

[umesh-qs]

I am just following the rules which are same for all.

I'm still waiting you prove me what rule I would infringe with my solution. Please stop blah blah and show me where is forbidden to keep your deleted IIA ID in my IIA and how long. Please show me where I'm compelled to delete an IIA and not to show it as empty and how long.

You're interpreting the rules on your feeling

Sorry forgot to mention the rule in my last comment. Please see below.

[demilatof]

As I already said, you can keep in you system, but not send it when I we do a get request on any of your IIA. Reporting to monitoring API is a way to get things correct. Problem is when you don't fix it. So if you fix before next weeks monitoring stats then it will not be reported.

@umesh-qs this is your invention, there is written no where what you're asserting; please, read again the rules you have posted

I am just following the rules which are same for all.

I'm still waiting you prove me what rule I would infringe with my solution. Please stop blah blah and show me where is forbidden to keep your deleted IIA ID in my IIA and how long. Please show me where I'm compelled to delete an IIA and not to show it as empty and how long. You're interpreting the rules on your feeling

Sorry forgot to mention the rule in my last comment. Please see below.

If read carefully understand what you have reported, you should understand that what I will do is perfectly correct and respectful of what you outlined above. Please note the differences between IIA and IIA ID: you cannot reuse an IIA Id of a deleted object for a new IIA, it's not written that I have to unbind my IIA from yours in a given time. It's the same if I use a wrong ID for your IIA; there is written nowhere that I cannot do, you simply should not approve me. It would be better if I were careful in using the correct ID, but it's not illegal.

[umesh-qs]

As I already said, you can keep in you system, but not send it when I we do a get request on any of your IIA. Reporting to monitoring API is a way to get things correct. Problem is when you don't fix it. So if you fix before next weeks monitoring stats then it will not be reported.

@umesh-qs this is your invention, there is written no where what you're asserting; please, read again the rules you have posted

@demilatof if this is my invention then I will let experts from EWP consortia correct this. I have seen lot of errors in the error monitoring that are actually not errors with our system This can happen for various reason. All we do is communicate back to those providers and they fix it. Problem can be when they don't act soon. I am not sure what is the current mechanism to address that. May be an email to EWP service desk.

I am just following the rules which are same for all.

I'm still waiting you prove me what rule I would infringe with my solution. Please stop blah blah and show me where is forbidden to keep your deleted IIA ID in my IIA and how long. Please show me where I'm compelled to delete an IIA and not to show it as empty and how long. You're interpreting the rules on your feeling

Sorry forgot to mention the rule in my last comment. Please see below.

If read carefully understand what you have reported, you should understand that what I will do is perfectly correct and respectful of what you outlined above. Please note the differences between IIA and IIA ID: you cannot reuse an IIA Id of a deleted object for a new IIA, it's not written that I have to unbind my IIA from yours in a given time. It's the same if I use a wrong ID for your IIA; there is written nowhere that I cannot do, you simply should not approve me. It would be better if I were careful in using the correct ID, but it's not illegal.

@demilatof by not removing my IIA ID that I have deleted, from your IIA and exposing in the network you are not following this statement "Such IIA MUST not be present in any of the IIA endpoints and an IIA CNR MUST be sent"

[demilatof]

@demilatof by not removing my IIA ID that I have deleted, from your IIA and exposing in the network you are not following this statement "Such IIA MUST not be present in any of the IIA endpoints and an IIA CNR MUST be sent"

Finally, we can discuss about something real. Be careful that you're mixing IIA and IIA Id and ignoring the previous statement. "Such IIA" is the IIA that you have deleted; so you are the one who has to not expose the IIA anymore in any of the endpoints. Yours endpoint can provide your deleted IIA, not mine.

The IIA is not the IIA ID; and even if we consider that they are equivalent, the endpoint is different from the data it returns. Therefore, when you recall me that "Such IIA MUST not be present in any of the IIA endpoints" you forget that my endpoints do not contain your IIA Id; your IIA Id is inside a data file served by one of my endpoints. They are two different things.

Only if I send you an IIA Approval CNR, I would put your IIA ID in one of my endpoint, but I will never do it, because I'll do an IIA-Get before, discovering that there is nothing to approve and I will stop myself from sending you an IIA Approval CNR.

[umesh-qs]

@demilatof by not removing my IIA ID that I have deleted, from your IIA and exposing in the network you are not following this statement "Such IIA MUST not be present in any of the IIA endpoints and an IIA CNR MUST be sent"

Finally, we can discuss about something real. Be careful that you're mixing IIA and IIA Id and ignoring the previous statement. "Such IIA" is the IIA that you have deleted; so you are the one who has to not expose the IIA anymore in any of the endpoints. Yours endpoint can provide your deleted IIA, not mine.

The IIA is not the IIA ID; and even if we consider that they are equivalent, the endpoint is different from the data it returns. Therefore, when you recall me that "Such IIA MUST not be present in any of the IIA endpoints" you forget that my endpoints do not contain your IIA Id; your IIA Id is inside a data file served by one of my endpoints. They are two different things.

Only if I send you an IIA Approval CNR, I would put your IIA ID in one of my endpoint, but I will never do it, because I'll do an IIA-Get before, discovering that there is nothing to approve and I will stop myself from sending you an IIA Approval CNR.

@demilatof I think you are just confusing everyone when you say IIA and IIA ID are not the same. Deleted IIA IDs cannot be included in any endpoint (doesn't matters where in the xml). But I will let others decide or comment on this. especially DG EAC. If they follow these discussions.

[demilatof]

@demilatof I think you are just confusing everyone when you say IIA and IIA ID are not the same. Deleted IIA IDs cannot be included in any endpoint (doesn't matters where in the xml). But I will let others decide or comment on this. especially DG EAC. If they follow these discussions.

@umesh-qs I think that a developer should not confuse the content with its identifier. An IIA is the same thing of a data file, the IIA ID is the file ID (e.g. the name). If an O.S. specification says that a file cannot contain a colon, it doesn't mean that the file cannot contain it. If the specifications use the term IIA, they mean the content; if they use IIA Id they mean the identifier. If the specifications are badly written, they should rewrite them.

All that said, we have another problem if you confuse an endpoint with the data it returns. The endpoint is universally accepted as the URL you invoke, not the data returned. These are the bases; among others, please read this:

API endpoints defined

An API endpoint is where an API receives requests. For most services, these endpoints are URLs, just like the ones you use to navigate to a website. (...) It allows developers to access data and functionality from other systems

Last but not least: you are the one who as to to stop immediately using the deleted IIA Id as soon as you send an IIA CNR. If I had to do the same, I would be prevented even to call your IIA Get API to discover the deletion, and this would be absurd.

[umesh-qs]

@demilatof I think you are just confusing everyone when you say IIA and IIA ID are not the same. Deleted IIA IDs cannot be included in any endpoint (doesn't matters where in the xml). But I will let others decide or comment on this. especially DG EAC. If they follow these discussions.

@umesh-qs I think that a developer should not confuse the content with its identifier. An IIA is the same thing of a data file, the IIA ID is the file ID (e.g. the name). If an O.S. specification says that a file cannot contain a colon, it doesn't mean that the file cannot contain it. If the specifications use the term IIA, they mean the content; if they use IIA Id they mean the identifier. If the specifications are badly written, they should rewrite them.

All that said, we have another problem if you confuse an endpoint with the data it returns. The endpoint is universally accepted as the URL you invoke, not the data returned. These are the bases; among others, please read this:

API endpoints defined An API endpoint is where an API receives requests. For most services, these endpoints are URLs, just like the ones you use to navigate to a website. (...) It allows developers to access data and functionality from other systems

Last but not least: you are the one who as to to stop immediately using the deleted IIA Id as soon as you send an IIA CNR. If I had to do the same, I would be prevented even to call your IIA Get API to discover the deletion, and this would be absurd.

IIAs has 1-to-1 primary/unique key mapping. If I delete IIA and send CNR to you, you must de-link my IIA from your IIA and send me CNR. You cannot keep using my deleted IIA and share it over. Now please don't ask me where it is mentioned. This is logical flow on 2 connected entities. If it is disconnected at one end (implicit on DELETE) it has to be disconnected at other end. I am sorry to say, I will have to pause here. So please excuse me if I don't reply to your next reply. I think we should wait for response from technical masters of DELETE changes or DG EAC.

[demilatof]

IIAs has 1-to-1 primary/unique key mapping. If I delete IIA and send CNR to you, you must de-link my IIA from your IIA and send me CNR. You cannot keep using my deleted IIA and share it over. Now please don't ask me where it is mentioned.

I can avoid asking you, but this is simply your dream. Your CNR doesn't impose me to do anything in a given time. And as @kkaraogl said in the past (if I remember correctly), if it it not written, I'm not compelled to do. Therefore, please stop inventing your own rules and avoid imposing me what should I write in my IIA.

It's a master master model: you think about your IIA, I think about my IIA, if I put the wrong IIA ID to identify your IIA, the only thing you can do is not to approve my IIA. No other to say.

[janinamincer-daszkiewicz]

We have an IIA between a pair of partners A and B with the pair of identifiers iia-id-A and iia-id-B. Partner B removes this IIA and sends CNR to partner A. Partner A ignores this CNR. Partner B calls the IIA index, finds iia-id-A. It calls get for iia-id-A and gets IIA with the pair of identifier iia-id-A and iia-id-B. He has no IIA with iia-id-B, so he reports an error and has every right to do so. It doesn't matter what else this IIA consists of.

One of the test scenarios will be just such a scenario and systems that, like A, deliberately use such a solution will be considered non-compliant with the specification.

P.S. Yes, it may happen that the CNR from B to A is lost or A reacts slowly and does not manage to remove this IIA yet, but thanks to the error being reported, the partners will quickly clarify the situation and A will remove the unnecessary object on his side.

If A removes iia-id-B from this IIA and leaves iia-id-A, it is formally wrong. If such behaviour is reported to monitoring and the monitoring reports show that A does so deliberately, the system will not pass acceptance tests.

I suggest that during the technical workshop in Warsaw we discuss the correct implementation of Delete, since it raises doubts. We will also discuss what test cases are worth preparing for acceptance testing.

[janinamincer-daszkiewicz]

This is an important discussion, but unrelated to the question from this thread asked by Emil. I will repeat it and ask for an answer: Is anyone of the providers using iia_codes in IIA GET?

[demilatof]

We have an IIA between a pair of partners A and B with the pair of identifiers iia-id-A and iia-id-B. Partner B removes this IIA and sends CNR to partner A. Partner A ignores this CNR. Partner B calls the IIA index, finds iia-id-A. It calls get for iia-id-A and gets IIA with the pair of identifier iia-id-A and iia-id-B. He has no IIA with iia-id-B, so he reports an error and has every right to do so

This is the first time that it is said; please, could you address me where the specification says that this is an error that needs to be reported? What is the time that EWP considers "legal" to discover that an IIA ID has been deleted? Why should be a problem for you if you get one of my IIA with an ID that you don't recognize as yours? You can ignore it and you don't approve it, it's simple I wish to recall that the specifications say: "There is no "master" of the agreement." The specifications also say: "partners will need to manually "bind" their local agreements with their remote counterparts" therefore if it is wrong the ID I use as yours, your system cannot be damaged.

Do you really think that what a partner does with it's IIA imposes the other partner to modify his own IIA? This would be against the specifications (There is no "master" of the agreement.). If this is the approach, then when I remove the mapping from my IIA, should I claim that you remove the mapping from your, otherwise it is an error that I have to report? Really?

If you want, I can be really pragmatic, but then I would report as an error a deletion that is not preceded by all of the following steps:

• Un-mapping the IIA to be deleted
• sending me an IIA CNR to notify the un-mapping
• waiting that I un-map my IIA and I send you an IIA CNR

Only then you can delete your IIA, not before. Do you want that we behave in a strict formal way? Then the above steps are essential, otherwise I can report as an error that you have deleted an IIA that is still mapped to one of my IIAs.

[demilatof]

Is anyone of the providers using iia_codes in IIA GET?

The question could even be interesting, but now we have gone too far away and I think this is not the best place to know if we can roll back or not, too few providers are participating.

The specifications, giving the maximum flexibility, fall as soon as we face the real world.

How can they say:

• If a computer program wants to find an entity, it will use the ID.
• If a user wants to find an entity, he will use the code

and at the same time allow to use the code, and not the ID, in the IIA GET? The specifications had allowed the code in IIA GET and most probably there are providers that have decided to use it, and maybe that they are not on GitHub. We cannot verify here how many users are using it, to be sure that we can forbid its use in the IIA GET.

The maximum flexibility would be to allow both IIA ID and IIA Code to be reused after a delete, but it seems to me that the maximum flexibility complicates your approach when instead it's really necessary.

Now you have to specify that even the IIA code cannot be re-used, because an IIA code can identify only an entity. If you don't, what should I think when I call a deleted IIA with it's IIA ID and I find nothing, but if I call it with its IIA Code, I find an IIA with a different IIA ID? And generally, don't you find problematic that I can call an IIA Code and time to time getting different IIAs?

[skishk]

This is an important discussion, but unrelated to the question from this thread asked by Emil. I will repeat it and ask for an answer: Is anyone of the providers using iia_codes in IIA GET?

we (unibo.it) don't use IIA_CODE in the IIA_GET request.

[ipnreddy]

MoveON also does not use IIA code when pulling IIA data.

[pabloop]

At the University of Granada (ugr.es) we do not use the iia_code in our IIA GET calls either, although internally it has meaning for us and the staff of our IRO.

[janinamincer-daszkiewicz]

Thank you. @mkurzydlowski I think we can prepare the change and forbid using iia-code as request parameters.

[jiripetrzelka]

I haven't found a single inbound request in log in which any partner would use iia_code in IIA Get and neither do we use it.

[janinamincer-daszkiewicz]

@jiripetrzelka thank you very much, that's really helpful. @kkaraogl, what about the Dashboard?

[kkaraogl]

We don't use it.

[janinamincer-daszkiewicz]

@kkaraogl have you ever seen it coming to the Dashboard?

[mkurzydlowski]

Please review this change proposal: https://github.com/erasmus-without-paper/ewp-specs-api-iias/compare/remove-iia-code