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

From: =JeffH <[email-masked]>
Date: Fri, 09 Mar 2012 20:51:22 -0800

> ============================================================
 >  Certain functionality required by modern financial systems is not
 >  presently available in open, legacy-free, adequately globalized
 >  protocols.
 >
 >  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
 >
 >  Given this situation, it makes sense to propose a legacy-free,
 >  adequately extensible protocol for internet-based financial exchange.
 > ============================================================

All of the above are application-specific, and can be conveyed IMHO over 
existing specified protocols.

So it isn't clear that the above /needs/ to be specified in the IETF. It can be 
done "anywhere".  (and I've been directly involved in efforts that were defined 
"elsewhere" and were layered over IETF protocols)

Again, the crux is whether you can get a critical mass of subject matter 
experts to convene wherever you decide to attempt to address the subject matter 
that concerns you.

You ought to go ask them if they're interested in working in the IETF context 
to address the above. Perhaps allocating an IETF mailing list and seeing who 
shows up and what occurs is one way to do that. But as far as I can tell, those 
folks are not at this time active participants overall in the IETF. Tho, 
perhaps I'm wrong, I dunno.

=JeffH

ps: with respect to IANA, one does /NOT/ need to be affiliated with the IETF in 
order to register things with IANA. I know this from personal experience in 
that I wrote and shepherded the registrations for 
"application/samlassertion+xml" and "application/samlmetadata+xml" from the 
context of the OASIS Security Services Technical Committee (SSTC).

---

From: Walter <[email-masked]>
Date: Sat, 10 Mar 2012 19:22:46 +0700

> existing specified protocols.

That's true. However, taking that view purely you could similarly
argue that almost everything is out of IETF scope because IPv4, TCP
and UDP exist.

Taking a broader view, one might argue that financial transfer is
already a relatively common internet use case today, and could be
reasonably likened to others such as email transfer, hypertext
transfer, file transfer, instant message transfer, telephony, etc.
Like those cases, it has its own specific needs and opportunities in
terms of the potential for the open standardization of one or more
protocols.  Those needs deserve a forum for discussion, just as other
use cases.

> So it isn't clear that the above /needs/ to be specified in the IETF. It can
> be done "anywhere".  (and I've been directly involved in efforts that were
> defined "elsewhere" and were layered over IETF protocols)

That's true: one could define anything anywhere.  However, the request
that IETF provides a forum for discussion and the potential
development of open, forward-looking financial standards for the
internet community is reasonable.

Compare to the IETF's mission statement (http://tools.ietf.org/html/rfc4677):

   o  Identifying, and proposing solutions to, pressing operational and
      technical problems in the Internet

   o  Specifying the development or usage of protocols and the near-term
      architecture to solve such technical problems for the Internet

   o  Making recommendations to the Internet Engineering Steering Group
      (IESG) regarding the standardization of protocols and protocol
      usage in the Internet

   o  Facilitating technology transfer from the Internet Research Task
      Force (IRTF) to the wider Internet community

   o  *Providing a forum for the exchange of information within the
      Internet community between vendors, users, researchers, agency
      contractors, and network managers*

The final point does seem rather relevant with regards to the present request.

> experts to convene wherever you decide to attempt to address the subject
> matter that concerns you.

It's very hard to draw attention to a forum for discussion before a
that forum exists.

> You ought to go ask them if they're interested in working in the IETF
> context to address the above. Perhaps allocating an IETF mailing list and
> seeing who shows up and what occurs is one way to do that.

Nobody knows who will show up until we have a venue and make some
noise about it. We are proposing the IETF host that venue in its
capacity as a shepherd for the internet community.  This seems to
accord both with general expectations prior to contacting the IETF,
and with its formal mission statement.

Regards,
Walter Stanish
Payward, Inc.

---

From: Walter <[email-masked]>
Date: Wed, 14 Mar 2012 11:21:24 +0700

*nudge*

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Mar 2012 00:40:51 -0500

> argue that almost everything is out of IETF scope because IPv4, TCP

Indeed, XMPP, for example, and many other protocols that are
application-specific are standardized here are standardized here.

I think the questions regarding whether to standardize financial
protocols here or not will be the same as with other application
protocols (and sub-IP protocols, for that matter).  Maybe someone more
familiar with past debates on similar issues can give us some
background.  I suspect it will all come down to: how many participants
are willing to work on this, how many are willing to review, whether
there is any running code, whether the wider community can be of help,
and so on.  We should at least consider it.  My fear is that there
isn't enough financial clue at the IETF to help the proponents, but
then, that probably could have been said about the media protocols
too.

Nico
--

---

From: Walter <[email-masked]>
Date: Wed, 14 Mar 2012 16:21:56 +0700

> application-specific are standardized here are standardized here.

Sincere thanks for taking the time to reply. In case there's an
audience still out there in the distinctly echoey (echoey...) halls of
this thread, I have tried to address the valid points you raised
below.

> background.

As a student and aspiring author of history myself, I do not in any
way wish to dissuade valuable historic inquiry, but this does seem a
tad tangential in light of the apparent existence of formalized
statements regarding the IETF's role and process. (That is, unless the
IETF has somehow descended in to the dark and near unnavigable realm
of ... "case law".*)

* Possible theme for a future roguelike? "You prize open the case law
archive. Mouldy remnants of past inquiry flap woefully in the
millennial breeze. The stench of legal aid skeletons and ancient
coffee emanates up from what must once have been a cheaply carpeted
floor."

> I suspect it will all come down to: how many participants
> are willing to work on this,

While we really do need the forum before collecting participants, we
can probably safely assume at least a smattering of mutual credit
communities, plus Bitcoin and other digital currency people, possibly
some financially oriented software vendors, some techier market and
banking people, etc. Maybe some big name companies - 'social' and so
forth - who are basically moving in to private currency accounting.
Such people are actually around (we have been in touch with quite a
few), it's just that many will need a neutral, focused forum to
congregate on definable problems before coming out of the woodwork for
procedural reasons.

> how many are willing to review,

Not to run before we walk ... I think gathering people to discuss the
perceived needs of individual community segments and come up with some
ideas for shared solutions (that do not sacrifice interoperability) is
the immediate task; latter issues of formal review MAY follow.

> whether
> there is any running code,

As above. In addition, running code has already been deemed "a tad
excessive" earlier on this thread:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04519.html

> whether the wider community can be of help,

Certainly there are multiple parties identified who have worked in
this direction in the past (see
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04511.html)
and multiple parties who are working in this direction at present,
though exclusively with narrower scope:
 - Ripple: http://ripple-project.org/Protocol/Protocol
 - CES (private communication, 2012): http://ces.org.za/
 - W3C Web Payments Community Group: http://www.w3.org/community/webpayments/

One might add to this short list the tremendous number of financial
services providers (both established and innovative) who currently
consistently present their customers with custom protocols or APIs
(XML, REST, SOAP, JSON RPC, HTTP; often with unique complex event
callback and/or state-based polling mechanisms; the same based on
weird VPNs, leased lines, client certificate SSL systems for security
box-ticking purposes, etc.) even for extremely well trodden settlement
problems (credit cards come to mind, as do mobile operators opening
their consumer billing platforms to payment integration, B2B banking
portals offered by leading banks, etc.).

Each of these entities, their vendors and clients would likely testify
to present pains of implementation: indeed, huge numbers of libraries
and software modules exist purely for specific-vendor-X API
integration purposes (few of which are created - shall we say - equal,
particularly in view of tax, fee, anti-fraud, accounting, auditing and
other related concerns that often slip out of view during small
scale/minimalist integrations).

As for how many might choose to actively contribute, that would be a
forward looking statement. Some will.

In short, there's a huge amount of experience out there in the
community to potentially focus on cost-saving, flexibility enhancing
standardization.  People are motivated, they get it. They've done
Euro, they've done taxes, they've done regulatory change, they've done
protocol upgrades, they've done vendor lock in, they're looking in to
mobile, they're seeing digital currencies. People want an interface
that works, and doesn't need to be thrown out and re-implemented
periodically.  The "wider community" in the non-IETF sense can thus be
relied upon to help, though which quarters specifically will step
forward we will only know in time.  In the IETF-internal sense of
"wider community", when any potential for formalization of output
approaches in the future, I'm sure people will volunteer.

But we will need a mailing list.

> then, that probably could have been said about the media protocols

Glad to see we're not on entirely new ground here. While unfamiliar
with the IETF's media protocols history, this seems rather chicken and
egg to me as affiliation with the IETF seems* to be largely based on
mailing list participation. Once formalization arises, surely any
knowledge or assistance required of existing IETF participants
(without necessitating broad finance domain expertise) could be teased
out of some quarter or other...

* "There is no membership in the IETF. Anyone may register for and
attend any meeting. The closest thing there is to being an IETF member
is being on the IETF or Working Group mailing lists".
http://www.ietf.org/tao.html

Thanks again for your valuable feedback.

Regards,
Walter Stanish
Payward, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Mar 2012 07:01:01 -0600

> But we will need a mailing list.

Actually, you don't *need* an *IETF* mailing list to discuss financial
application protocols.

I would like to note that I remain skeptical that there truly is a
community here, that there is a tractable engineering problem to be
solved, that the IETF is necessarily the right place to do work on
engineering solutions even if there is a tractable problem, or that the
proponent (I have yet to see more than one) has taken account of
previous work in this space at the IETF and why that work has not been a
wild success.

Notwithstanding, as an area director for the applications area (at least
for a few more weeks) and in consultation with Pete and Barry, I am
willing to create a list and see if a more concrete initiative gels
here. If list discussion doesn't lead anywhere, it will be easy enough
to close the list.

Walter, please provide the following information:

1. List name (please don't make it "finance" because people might think
it is an IAOC list)

2. List administrator email address(es)

3. Purpose (a *brief* description, see
http://www.ietf.org/list/nonwg.html for examples)

Thanks.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Mar 2012 14:52:11 +0100

On Mar 14, 2012, at 14:01, Peter Saint-Andre wrote:

> financial

Maybe I'm still struggling with the direction of this.
Is AMQP a financial application protocol?  0MQ?

Grüße, Carsten

---

From: Jorge Timón <[email-masked]>
Date: Wed, 14 Mar 2012 15:54:43 +0100

Hi, Walter contacted us in the ripple forum and I would be interested
in collaborating with a generic protocol design. Although I've
participated in the distributed Ripple protocol design, I've never
designed a protocol myself.
I have done a lot of research in alternative monetary systems. I'm a
computer scientist and I'm involved in the bitcoin and ripple
communities, although I haven't had the time to help with the coding
yet.
I've also discussed some things with the open transactions developers
too. I've proposed freicoin (just a bitcoin fork with demurrage, is
not even implemented yet, but a very similar crypto currency is about
to be released) and some other alternative chains.
For all of the above, I think I can be helpful designing the protocol
Walter wants.

ZeroMQ is not a financial protocol. I would say a
networking/queuing/concurrency framework, but I've just read a little
bit about it so don't take my word here.
Although I think it can be very useful for implementing the financial
protocol at hand, it can be used for other things that have nothing to
do with finances.

If we have to have a working group before getting help from IETF, we
can start a thread in the Ripple forum or in bitcoin's (probably the
dev mailing list is better) for that purpose. I think there's
different people working on different financial protocols that aim to
be more or less generic already. I can offer the freicoin forum too.

On 3/14/12, Carsten Bormann <[email-masked]> wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

-- 
Jorge Timón

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Mar 2012 08:56:29 -0600

> Is AMQP a financial application protocol?  0MQ?

AMQP and 0MQ are used in the financial industry, but I don't think they
are financial application protocols of the kind Walter seems to have in
mind, such as:

https://datatracker.ietf.org/doc/draft-iiban/
https://datatracker.ietf.org/doc/draft-imic/

But perhaps he can explain more clearly.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Walter <[email-masked]>
Date: Thu, 15 Mar 2012 06:12:50 +0700

> But perhaps he can explain more clearly.

AMQP and 0MQ are Message Queues.

Roughly (I'm no authority) MQ's are associated with finance for a few reasons:
 1. Message orientation
 2. Often good for building high availability systems on cheap
hardware (n:n topology support)
 3. Can be very low latency and bandwidth efficient
 4. (probably) 'Enterprise' cultural overhead

Code-wise, you can typically use the sockets interface to connect to
them but they have all sorts of their own options to expose their
flexibility.  Often reliability is optional - in part, it's this
ability to switch off the service guarantees provided by a standard
transport that lend these layers their power, the other side being
topology flexibility.

In any case, message queues definitely appear to be a (the?) primary
potential transport option for non "vendor locked-in" financial
systems today.

Hope that clarifies.

Regards,
Walter Stanish
Payward, Inc.

---

From: Walter <[email-masked]>
Date: Thu, 15 Mar 2012 06:27:52 +0700

> 1. List name (please don't make it "finance" because people might think

ifex (Internet Financial EXchange)

> 2. List administrator email address(es)

[email-masked]; others can be added as participation grows

> http://www.ietf.org/list/nonwg.html for examples)

Discussion of future financial services protocols for the internet community.

Regards,
Walter Stanish
Payward, Inc.

---

From: Walter <[email-masked]>
Date: Thu, 15 Mar 2012 07:17:10 +0700

Thanks for your support Jorge, and welcome to the effort :)

With regards to forum location, I think the main difficulty with using
an established forum is that most people come from a certain community
with interest and experience that is generally more focused on certain
aspects of internet based financial exchange.

For example, it would be unreasonable to expect people involved in
mobile operator billing to be familiar with mutual credit systems,
just as it would be unreasonable to expect people involved with high
frequency trading on stock exchanges to be familiar with credit card
settlement anti-fraud rule weightings.

The establishment of a unique forum under the IETF provides the
capacity for different groups to come together - without being under
the banner of any particular one - to look at issues of
interoperability and leverage the skills, insight and experience of
other parties.  It also means that there's an established and proven
procedure for getting things done (eventually formalized),  resolving
questions of consensus fairly, etc.

Anyway, Ripple brings a very unique and relevant perspective to
forward looking internet finance and I am really glad that you are
joining in. Looking forward to working together on the new list!

Regards,
Walter Stanish
Payward, Inc.

---

From: Jorge Timón <[email-masked]>
Date: Thu, 15 Mar 2012 12:10:05 +0100

Probably Ryan will be interested in participate too.
I agree that the discussion would be better in a "neutral" forum, I
was just suggesting forums to "join the people together" if it is
necessary to start the new mailing list.
If you want, I can start a thread in the bitcoin-dev mailing list to
get more people interested in the protocol.

-- 
Jorge Timón

---

From: Jorge Timón <[email-masked]>
Date: Wed, 21 Mar 2012 19:33:56 +0100

Please, let me know if there's any news. I'm going to unsubscribe from
this list for now.

-- 
Jorge Timón

---

From: Walter <[email-masked]>
Date: Fri, 23 Mar 2012 09:49:14 +0700

> Please, let me know if there's any news. I'm going to unsubscribe from

Is there any news from Area Managers regarding the status of the
creation of the proposed list as previously advised?

I have sent two requests for status updates privately but have not had
any response.

*nudge*

Regards,
Walter Stanish
Payward, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Mar 2012 20:56:07 -0600

On 3/22/12 8:49 PM, Walter wrote:
>> Please, let me know if there's any news. I'm going to unsubscribe
>> from this list for now.
> 
> I have sent two requests for status updates privately but have not
> had any response.
> 
> *nudge*

Email to your domain is being delayed:

   <[email-masked]>: conversation with mail.stani.sh[206.123.115.203]
   timed out while receiving the initial server greeting

This happened to both me and Barry.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Walter <[email-masked]>
Date: Fri, 23 Mar 2012 11:13:08 +0700

> Email to your domain is being delayed:

Resolved?

- Walter