flexoffer / flexoffer-specifications

Specifications of FlexOffer
2 stars 2 forks source link

Table 1.1 line 'state' #27

Open cerne739 opened 1 year ago

cerne739 commented 1 year ago

The value 'initial' of the parameter 'state' is not in line with other values like 'offered', 'accepted', ... Since the flex-offer protocol supports the feature of the updating of the (unassigned) flex offers it should go into the another subject, i.e. 'status' = 'initial' at sending the first FO and 'status'='updated' at subsequent messages describing the same asset capacity. Since this feature is controlled via the 'id', additional description is not necessary and the value 'initial' may be removed.

DuneSe commented 1 year ago

Should remove the "initial" state as a possibility Fabio will check the presence of another parameter indicating whether the offer has been updated Gerald proposes: 'initial' might be 'in preparation, not yet offered for achieving acceptance

FabioLilliu commented 1 year ago

I found a newer document (from FEVER) with the following options for state: offered / rejected/ assigned/ executed/ invalid/ canceled. "Initial" was not there, so I guess it can be removed for the reasons reported above.

However, this refers to FO state. In the same document, there is a part describing FO schedules, which has "initial" and "accepted" as possible states in addition to the ones reported above, although I guess the issue still applies to them.

As for "parameters that indicate whether the offer has been updated", I have not found any for FO messages; however, I found some FO schedules have a parameter called "updateId", which could indicate that (unfortunately, it is not mentioned in the parameters description).

DuneSe commented 1 year ago

Keep state initial and explain that it is only until the offer is offered