IGM : Respondant action NEED-MORE-INFO

[venkatramanm]

A Respondent could either ask for more info or provide info to a requestor, So this enum could to be split into INFORMATION_REQUESTED and INFORMATION_PROVIDED @Rishabh-ondc

[venkatramanm]

The protocol seems to allow seeking information in either direction. Maybe the complainant action should also have INFORMATION_REQUESTED and INFORMATION_PROVIDED for the sake of symmetry.

[nitinmish]

I think adding this will add unnecessary loops. In case respondent needs info or clarification, they can respond back with information/confirmation requested. Otherwise, it can simply offer resolution. This will keep the implementation simple and clean. @venkatramanm @Rishabh-ondc @AbhiSIITR @BLR-0118

[venkatramanm]

NEED-MORE-INFO seem like requesting and symmetric enum for INFO_PROVIDED is missing.
Alternatively we could change NEED-MORE-INFO to just "INFORMATION: to mean provided or requested.

My objection is to asymmetry of the word "NEED"

Since under AdditionalInfoRequired element, there is already info_requested and info_provided, the action enums were suggested.

My take for the next version is to simply use notes with a threading capability as marked in my fork of this repo.

[nitinmish]

I agree. We can change it to just information. Basic idea is to avoid double tapping of same attribute by two entities engaged in a transaction.

[venkatramanm]

Also @nitinmish , Asking for information can be done both ways from complainant or respondent. This was also not captured in the spec while it is talked about in the seq diagrams in the API document. Hence my suggestion to add this action "INFORMATION", or ("INFORMATION_REQUESTED" and "INFORMATION_PROVIDED") under both ComplainantAction .complainant_action and RespondentAction.respondent_action

[nitinmish]

True. It is expected that once an issue is raised, there should not by any additional information transmitted unless previous transaction is responded to. Should a respondent needs additional info, they should simply restart loop with issue again. Complainant can respond to such queries. Unsolicited responses are avoidable in open APIs or else, there are possibilities of race conditions that may result in failed transactions and compromised idempotence.

[venkatramanm]

Not just unsolicited responses.

The point is, any party, complainant or respondent can Solicit and receive clarifications. This part also may need a fix. Today only respondent can ask for clarification. Complainant may also want to ask clarifications. Right? If complainant cannot seek more information, then Some of the seq diagrams is not correct in the api document. Some inconsistency needs closure. May be the complainant action should also have "information" as an allowed enum?

@nitinmish @Rishabh-ondc @BLR-0118