As per [ROBUST] and to avoid situation such as [ISO20022CR103], IFEX
encourages a "be liberal in what you accept, but conservative in what
you believe" philosophy. This philosophy is manifest in decisions to:
* Require only definitively essential fields.
* Build extensibility in to the base protocol.
* Mandate the avoidance of transaction failure where unrecognized
information is supplied by one of the communicating parties.
* Delegate mandated field specification to communicating parties.
Value Conceptual Simplicity
The majority of financial messaging requirements identified through the
extensive research made during the design of IFEX were relegated to the
domain of implementation through extensions; this includes market and
jurisdiction-based requirements in addition to financial transaction
metadata that may only be relevant between a small number of parties
("bespoke integrations" in UK parlance).
Whilst it may be argued under this guideline that the extensibility
notion facilitates the uncontrolled reduction of conceptual simplicity,
it is felt that since the user communities in question are the only ones
affected it is reasonable to offload to them the responsibilities of
Minimization of Dependencies
The notion of this guideline is not to blindly trust other nodes.
With regards to Pre State financial transactions, this is manifest in
the recommendation to test input given by other nodes and, where
possible, against additional nodes' reported status for the same
financial transaction. In any case, IFEX is perceived as a 'light
touch' protocol in that it does not mandate extensively local processing
algorithms and thus delegates the responsibility of correct style to
implementers: good luck, and publish your results.
With regards to subsequent state financial transactions and/or the
transition to such, the agreement of a client to provide funds for
settlement is in most cases a reasonable and potentially legally binding
justification for the expense of computational resources.
Verification Where Possible
IFEX attempts to strip out all redundancy as superfluous; see
Fee/Tax/Discount Support under Internationalization for an example.
With regards to the linear progression of transaction state class toward
Final State (SUCCESS or FAILURE), this facilitates the reduction of
impact with regards to the intermediate loss of state updates.
In addition, IFEX's communications paradigm neutral approach means that
state-loss situation may result in queries to other parties to a
transaction may reliably update state without nasty surprises, ie:
whilst current remote state COULD be incorrect, a subset of possible
remote states MUST be known at all times. Such information SHOULD be
sufficient for all parties to effect decisions regarding the financial
transaction in question; in particular, the cancellation and transition
to FAILURE of financial transactions in which financial transactions
with status falling in to the Final State category (ie: SUCCESS or
Protection of Resources
IFEX's state transition model requires that connecting parties specify a
relatively large amount of information regarding any given transaction.
In return, responding systems provide a very brief response. From a
network resource perspective, this achieves the desired affect of
removing threats of traffic multiplication at the message (application)
level, regardless of the elected transport-layer protocol.
The state transition model also requires a linear progression between
financial transaction states and their classes; thus, incorrect
behaviour is limited and MAY result in the cancellation of a transaction
(ie: the reporting via a RPT message of a financial transaction's
transition to FAILED state by the party detecting the error).
Limitation of Vulnerability Scope
... individual system can alter their perception and trust for remote
IFEX nodes based upon the state of a transaction.
... settlement terms may be negotiated to very specific
... the option for signed messages enables non-repudiation.
Provision has been made for error exposure at every stage of a
transaction, ie. in any Transaction State or within any Message Type.
In addition, to provide implementers with adequate information for the
provision of error processing .... local requirements, an hierarchical
approach has been taken to error specification. Such an approach
allowed implementers to provide varying levels of feedback and
processing activity based upon the type of error encountered.
The relationship between [IP] and [ICMP] was reviewed to better inform
the design process.