W3C home > Mailing lists > Public > public-interledger@w3.org > March 2016

Re: A B2B application layer protocol for Interledger?

From: David Nicol <davidnicol@gmail.com>
Date: Wed, 30 Mar 2016 00:12:54 -0500
Message-ID: <CAFwScO-RvYs5A7YF4EsnN-iFxp+YqKJdWFZxGyokibcCMCJGNw@mail.gmail.com>
To: Interledger Community Group <public-interledger@w3.org>, Web Payments CG <public-webpayments@w3.org>
Having worked in the EDI departments of two huge corporations, I'd like to
remind all that the de facto standard for B2B electronic data exchange
continues to be a moldy old protocol called "X12" which has been getting
extended to support new use cases for forty years, but suffers from loose
standardization to the point where any two businesses who wish to use it
have to start off their trading partner relationship with an integration
phase where they negotiate the exact details of the portions of X12 they
will be using to communicate over their new EDI channel.

Based on that experience, I suggest two paths, which are not incompatible:

Path One: allow room for an arbitrary B2B data block which can hold
anything the trading partners want to put there. This seems backwards, as a
lot of B2B EDI doesn't involve transactions as such, but other things like
shipping notices and price lists, which would have to be placed inside
dummy zero-amount transactions.

Path Two: survey the existing B2B EDI technologies' representations of
payment mechanisms, and have the new protocol identify any particular
transaction in a way that it can be referred to by the existing tech. For
X12, I think that would be an element in the 820 "Payment Advice"
Transaction Set, see
http://www.x12.org/x12org/subcommittees/x12f/docs/csp_820a.pdf for a 51
page discussion of X12 payment transaction sets -- the 820 has the "BPR"
segment, which contains information about the payment being advised about.
The first example of a BPR there includes a Payment Method Code of "ACH"
meaning Automated Clearing House. At most, to be compatible with X12 EDI
installations, a new Payment Method Code would need to be declared, and
trading partners could then agree to use it.

I presume the other similar B2B protocols have an equivalent. If not, it's
easy enough to declare a B2B protocol that has ACH as a constant rather
than as a parameterizable field for payment method is Broken and should be
Revised.

At your service,

David Nicol





On Mon, Mar 28, 2016 at 3:35 PM, Joseph Potvin <jpotvin@opman.ca> wrote:

> RE: "ebXML looks like it would add a ton of complexity"
>
> Agreed. It's not the way to go. And there's been almost no activity in
> ebXML itself since around 2008.
>
> On the other hand,
>

-- 
A circular pizza with radius Z and thickness A has a volume of PI (Z*Z) A
Received on Wednesday, 30 March 2016 05:13:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 05:13:25 UTC