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

[Walter <[e-mail]>]

> Apps-Discuss folks: It's been about a week since Walter posted this,
> and no one's commented.  Perhaps that means that no one's  interested,
> but I'd like to stir the pot a bit and see whether anyone has anything
> to say.  Nudge-nudge, stir-stir.

For the record I have received a private response from a member of the
Energy WG.

> Walter, what we're looking for here is some public discussion that
> results in at least some reasonable level of understanding about what
> would be discussed on the mailing list you propose,

Is it really necessary to have people already participating in this
mailing list express interest in order to justify a new list on a
specific subject? Whilst I can understand the tradition, this does
seem like a bit of a paradox to me: surely interested parties are to
be drawn to such a mailing list from related corners of the wider
internet community?

> who might be
> interested in participating

Addressed in the original email, I believe.

> and, importantly, what IETF work might come out of it.

Being new to IETF processes in general, I can shed no light on this.
Certainly the establishment of some IANA registries.

>  I'll note that standardization doesn't only happen in
> the IETF; there other standards organizations with different foci, and
> industry consortia often form to develop special-purpose standards for
> limited industry subgroups.  What you want here might not be a bunch
> of Internet gearheads who worry about SMTP, HTTP, SIP, MPLS, and BGP,
> but, rather, some techies involved in the finance industry who can
> better develop something that really meets the need you have.

I am well aware of the protocol authoring focus.

Financial industry groups are not the right forum for this development
as they are top-heavy with a massive, indisputable interest in
maintaining the status quo.

Scope-wise: Whilst we are looking at higher level protocols (hence
'application area'), we can't simply take the de-facto choice and
build on HTTP or TCP because they don't meet the multipoint
requirements of many financial messaging systems.  (In addition, the
transaction-orientation of HTTP is too limiting for many such
communities who presently use exotic mixes of custom out of band
stream replay solutions to resolve intermittent loss on their high
bandwidth, sequence-numbered financial information streams)  There are
a wide range of message queue systems that are in commercial use or
open source development that may serve to elegantly resolve transport
layer requirements, though mandating an exotic transport layer would
be self-defeating. Therefore, the current view is toward transport
neutrality.

Regards,
Walter Stanish
Payward, Inc.