Protocol Design Considerations

   This section details considerations made during the design of IFEX in
   an attempt to explain the reasoning behind specific design decisions
   to implementing or technical audiences.

  Transport Neutrality
   Transaction protocols such as [HTTP] and [JSON-RPC] were necessarily
   avoided on account of their lack of support for arbitrary communications
   topologies.

  Message Identification
   The IFEX policy of transport and communications topology neutrality
   necessitates a broader approach to message identification than classical
   [TCP]-based transaction-oriented application level protocols.

   This is because the use of unreliable transports AND/OR
   broadcast/multicast (one-to-many) topologies MAY occur.  At the other
   extreme, an IFEX deployment MAY make use of a reliable transport with
   bandwidth and latency sensitivity and opt to exclude message
   identification overheads entirely.

  Financial Transaction ID (FTID)
  The Account of Interest Identifier (AOI) is 13 characters to facilitate
  the straightforward association of an IIBAN with a transaction; note
  however that the use of IIBAN for AOI is NOT required.  (Use of IIBAN
  relieves IIBAN-based implementations of the need to store the entire
  FTID; instead they MAY store only the subsequent (UTCSO and ISTI)
  portions against the internal transaction ledger(s) in question.)

  The second-level granularity of the temporal portion (UTC Second of 
  Origination, or UTCSO) was chosen in order to provide a reasonable
  mechanism for the immediate association of a FTID with an adequately
  specific point in time to facilitate sorting.  The day-based granularity
  alternative would reduce the overall length of a FTID significantly but
  was discounted as a probable cause of increased human error,
  particularly on numerous existing systems that MAY operate partly or
  wholly upon local timezones instead of UTC.

  The length of the Intrasecond Transaction Identifier (ISTI) was set at 5
  characters as it rounds out the overall FTID length neatly to 32 bytes
  and provides what is felt to be an adequate maximum of 60,466,176
  transactions per AOI per second.  (Implementors requiring scalability
  beyond this number of transactions per second should refer to the
  Maximum Transaction Throughput section for recommendations).

  Fee/Tax/Discount Support
  It is recognized that a frequent case is that a fee, tax or discount
  will affect all settlement paths, for instance jurisdiction-based
  taxation usually falls in to this type of situation.

  Whilst a mechanism for the description of such cases was considered at a
  disparate level to that of settlement paths in order to realize shorter
  message lengths (ie. removing the need to redundantly specify the same
  fee, tax or discount on duplicate settlement paths), this was ruled out
  on the grounds that removing a secondary location within messages for
  the specification of equivalent cases was a simplification and therefore
  desirable.  In addition, the optimization of such cases at the wire-
  level is possible to effect through alternate wire-formats (or
  'middleware' in today's enterprise parlance), and it has been previously
  noted that "Premature Optimization is the Root of All Evil".

  Transaction Types
  While other financial protocols have seen fit to categorise transactions
  in to fixed categories, IFEX avoids such a scheme due to its goal of
  maintaining a maximum breadth of deployment applicability.  This
  decision also serves to remove the frequently observed potential for
  latter accretion of redundancy in protocols where the sum total of all
  future requirements failed to be perceived at the protocol design stage.

  The need for specific deployments to include mechanisms for transaction
  categorisation is, however, acknowledged with IFEX's capacity for
  parties to establish agreed vocabularies of transaction types to suit
  deployment time requirements.  In addition to more specific and/or one-
  time vocabularies, it is anticipated that common common transaction type
  vocabularies will be established to cater to repeating industry, market
  and regulatory jurisdiction level requirements; possibly even by
  industry bodies and/or regulators themselves.

  Multiple transaction types are allowed per transaction due to this
  perceived need for multiple transaction type affinities per transaction,
  ie: local system or deployment linked, industry or market linked, and
  (possibly multiple) jurisdiction specific regulatory requirement linked
  transaction types may be associated with a single transaction.
Comments