Re: [apps-discuss] Proposal for a Finance Area Mailing List

[Walter <[e-mail]>]

>> This functionality includes:
>>  * Settlement and reversal / cancellation term negotiation
>>  * Exchange rate negotiation
>>  * Latency calculation / negotiation
>>  * Fee, tax and discount calculation / negotiation
>>  * Arbitrary currency / asset support
>>  * Multi-currency / asset transaction support
>>  * Quotation support
>>  * Multiple settlement path support
>>  * Optional support for in-band settlement (sometimes known as DVP)
>>  * High precision decimal value support
>>  * Arbitrary financial settlement topology support
>>  * Arbitrary communications topology support
>
> Sounds cool.

Thank you for your positive comment.

>  Anyone likely to implement it?  The IETF has a well known
> preference for running code.

(One might wonder if such conflicts with the 'come with a problem
rather than a solution' philosophy of the BOFs / mailing list
proposals @ http://tools.ietf.org/html/rfc5434#page-2 ?  Then again,
one might try to focus on avoiding bureaucratic discussion
entirely...)

Forward looking statements are always hard to juggle, but at present
it does seem that whatever we wind up deciding upon will be
implemented by Payward Inc.  At least one party with worldwide
presence has also expressed a significant and immediate interest -
even at this very early stage - in rapid implementation.  Whether we
move forward independently or on a shared implementation is not yet
known. Resulting code may be shared in whole or in part with the wider
community as open source, depending upon commercial concerns which are
not my domain and I cannot therefore comment on.

Secondly, I would note that the complexity that the above feature list
suggests should not be taken as a requirement for basic
implementation; even integrating exhaustive specifications for all
possible considerations of these features in to a document would
render it a book. The philosophy to do one thing and do it well
demands a minimalist approach; as per established protocols extensions
for precise cases (under various legal jurisdictions, when accessing
certain financial markets or networks, etc.) would presumably be
described separately. Individual implementations would be free to
leave out support for most or all extensions, advertise the subset
that they support when handshaking, then interact appropriately.
Easier said than done, but I believe an achievable goal.

In closing, perhaps you could assist with teething issues faced by
mere newcomers such as myself by flexing your apparent dummy series
authorship credentials on a humorous RFC for April; "The IETF for
Dummies"?

Regards,
Walter Stanish
Payward, Inc.