Robustness Considerations

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
 this situation.

 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.

 Expose Errors
 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.