IIAs Dashboard Exchange Scenarios

[kkaraogl]

Added the pdf with the detailed exchange scenarios.

[kamil-olszewski-uw]

Hi,

As far as I know you received Janina's comments:

• Page 12, in IIAs database should be a.hash2 and b.hash_2, right?
• Notice (2) "B created an IIA CNR after receiving changes from Dashboard although B did not make any changes, in order to tell Dashboard about its b.hash_2." This is not true, B made changes, otherwise hash would not change.

Also, we're still a little concerned that the whole thing promotes too much the need to get a CNR to go further with the algorithm. Of course, this is the most convenient scenario, but it can be interpreted by someone as the only right solution. And yet the ability to proactively invoke IIA index request and IIA get request can be a useful addition, especially in the case of some problematic situations. This does not necessarily mean that separate scenarios should be created, but additional notifications would be useful to dispel interpretation doubts.

[kkaraogl]

Janina's comments were on the spot, as always. We corrected them.

The document basically aims to detail (detail it up to an annoying point) the scenario already published in the spec, where this concept of CNRs is present from the beginning with the same gravitational role to the whole flow: https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v6/example-scenario

Let's use these scenarios as a starting point, and we'll collaboratively further expand them, depending on the community's feedback and what we both experience from testing with other partners. But everyone should start from somewhere, and this is a really nice starting point, in my opinion.

[umesh-qs]

Janina's comments were on the spot, as always. We corrected them.

The document basically aims to detail (detail it up to an annoying point) the scenario already published in the spec, where this concept of CNRs is present from the beginning with the same gravitational role to the whole flow: https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v6/example-scenario

Let's use these scenarios as a starting point, and we'll collaboratively further expand them, depending on the community's feedback and what we both experience from testing with other partners. But everyone should start from somewhere, and this is a really nice starting point, in my opinion.

There must be changes made to these steps to mention in each step that nothing should be shared in the network without the knowledge of sharing institutions. Specially steps 1,3,6. This document is outdated.

[umesh-qs]

Also CNR is not a must to complete the process. Individual system must be able to handle this without CNR as well.

[kkaraogl]

@umesh-qs are you referring to this? https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v6/example-scenario

[umesh-qs]

@umesh-qs are you referring to this? https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v6/example-scenario

Yes

[kkaraogl]

@umesh-qs may I propose to discuss this on a separate issue, and not in this pull request?

[umesh-qs]

Well this was mention in the comments so I responded. Even for the document https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/187f98d1c1a3abef2ec225953812b7cf148b6c76/iias-dashboard-exchange-scenarios/IIAs_Exchange_Scenarios.pdf I see quite a few assumptions made

[kkaraogl]

@umesh-qs and once/if it is merged we can discuss them. Though moveon already complies with everything detailed in the pdf... But if the original scenario, that has been sitting there for months, has inconsistencies, imagine the mess this brings with newcomers.

[umesh-qs]

@kkaraogl .. I would not like to use the term compliance. We are in compliance with the EWP API specs. There is no need for us to be in complaint with how Dashboard works. And that is the reason why I mentioned that you have assumed the process at Partner B in the document.

[kkaraogl]

@umesh-qs changing compliant to in-line, then. No problem with your statement of not feeling the need to smoothly exchange with the EWP Dashboard. But I can't say this from EWP Dashboard's perspective. I will still carry on actively trying to smoothly exchange with each and every one in the network, complying to the specs, of course.

[umesh-qs]

@kkaraogl ... it is not about smooth exchange of data. It is about the assumption made in listing the scenarios. You may ideally want partner B to work as per you liking. But that may or may not be true. Each system has their own process in place that is catered to their client expectations. For ex we cannot show the daring and start exchange of data without our clients knowledge. May be you can and you are, because Dashboard being a free system, without any liabilities.

[kkaraogl]

@umesh-qs we are kind of doing circles....

We are seeing the original public scenario and we further detailed it. The same way we did for LAs exchanges. We do not mandate what the other partner should do, partners' behaviors of implementation are described already by the original scenario. How and when actions triggered on each side is a valid argument, as long as it doesn't cause problems.

And again, once/if the pdf is merged, we can continue discussing it, inviting others also to chip in.

But if you have a problem with the scenario (https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v6/example-scenario), still weird because it is there since forever, I'd still suggest to take it up on another issue.

[umesh-qs]

@kkaraogl may be it is there for some time now. But it does not mean that it is completely validated and approved/voted by everyone. I saw it now, so I am sharing my reservations on it. Also I did not get your point "How and when actions triggered on each side is a valid argument, as long as it doesn't cause problems.". What kind of problem and to whom?

[kamil-olszewski-uw]

I consulted Janina. These scenarios are helpful, so we'll merge them now. But we hope for more in the future, so that nothing raises interpretation doubts regarding the implementation.