Re: A B2B application layer protocol for Interledger?

Joseph et al,

Lichen and Xalgorithms sound like interesting efforts. UBL is a perfectly
reasonable choice as a canonical data format, or wire format, I'd agree.
But you're simply not comparing apples and apples in talking about other
layers of the protocol stack, about proprietary solutions like Tradeshift
(who I know well), or about semi-proprietary implementations like PEPPOL
(which btw, invented its own much more proprietary protocols for various
layers of the stack addressed by ebXML: I bet you've never even heard of
START/LIME). Not to get into it here, but there's also less than meets the
eye to the OpenPEPPOL effort in my view (see OASIS BDX/BDXR, in which I was
also quite involved).

I think there are some more fundamental business network dynamics at work
as regards how interoperability standards evolve and get adopted at
different layers of the stack, i.e. data vs others. Secure, reliable
messaging in particular, for example, is one that's a general need and
where convergence has happened slowly, but is more or less now there.

Anyhow, this discussion is perhaps getting increasingly arcane, and even
off-topic from the perspective of the Interledger group, I rather suspect.

Per the IETF credo, "rough consensus and running code" seems to be the way
to go - with a continuing focus on the simpler, consumer payment OWPS use
case to start with. Religious debates on B2B, or anything else, seem less
than constructive. If any of us have specific proposals around focused B2B
use cases, maybe this discussion gets interesting again.

Roger


On Mon, Mar 28, 2016 at 1: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, it's more elegant offspring UBL has flourished.
>
> UBL in N. America is Industry-led (in B2B frieght, mainly)
> — US: e-Invoice-based Freight Payment
> http://eeiplatform.com/14904/us-bank-launches-e-invoice-based-freight-payment-trade-finance-service/
> — Electronic Freight Management Overview
> http://ops.fhwa.dot.gov/Freight/intermodal/efmi/electronic.pdf
> — e-Invoicing is at the center of the treasury & trade convergence
> http://www.swift.com/resources/documents/SOFA_2012_eInvoicing_Fast_Evolving_Landscape_02_Mar_2012.pdf
>
> There are several UBL implentations based in Europe -- mostly oriented to
> govermentment procurment use cases. This is because UBL is now (or is soon
> becoming) mandatory for public sector procurement invoicing in most
> European countries.
>
> There was a government-sponsored pilot (now ended) called PEPPOL. It lives
> on as OpenPEPPOL, an "open" government+commercial platform (i.e. the
> continuation of PEPPOL) ... though it's not clear to me yet how genuinely
> free/libre/open source it really is.
> http://www.peppol.eu/about_peppol/about-openpeppol-1
>
> http://www.peppol.eu/news/new-open-source-implementations-for-the-peppol-network
>
> One of the European implementations of UBL, "NemHandel" (Denmark) is a
> government-run project. Buy several of NemHandel's core developers left
> home and set up the company "Tradeshift" in California
> http://www.forbes.com/sites/tomgroenfeldt/2014/12/23/tradeshift-a-supply-chain-model-that-takes-after-linkedin/
>
> Tradeshift is restricted software on a SaaS model, with an open API)
> http://tradeshift.com/ http://integrate.tradeshift.com/
> Onboarding Users to Tradeshift
> http://eeiplatform.com/15769/tradeshift-and-the-art-of-supplier-on-boarding/
>
> "Interview with Tradeshift’s CEO Christian Lanng":
> http://www.computerworlduk.com/news/public-sector/3436545/tradeshift-ceo-uk-government-could-save-852m-moving-to-open-e-invoicing/
>
>    -         http://www.programmableweb.com/api/tradeshift
>    -         https://github.com/Tradeshift/tradeshift-api-client
>    -         Python-based API to Tradeshift
>    http://www.cranesoftwrights.com/resources/ubl/index.htm#tspython
>    -         https://github.com/Tradeshift/Tradeshift-Apps
>    -         https://github.com/Tradeshift/Tradeshift-AppDeveloper
>    -         https://github.com/Tradeshift/Tradeshift-Java-Client
>    -         https://github.com/Tradeshift/tradeshift-ubl-xsd
>
> The particular niche that Xalgorithms Foundation is pursuing with Lichen &
> with the Xalgorithms Federated Registry is to simplify and make much more
> efficient the availability of computational algorithms that are needed to
> accomplish a complete transaction. It is our view the scope of improved
> "payment" includes all essential elements including taxes, exemptions,
> credits, cross-border duties, point system adjustments, just as the scope
> of "a complete trip" by aircraft includes the passenger's baggage.
>
> Lichen uses UBL an e-commere data 'Rosetta Stone'.
>
> Joseph Potvin
> Executive Director, Xalgorithms Foundation
> Mobile: 819-593-5983
> jpotvin@xalgorithms.org
> https://www.xalgorithms.org
>
> On Mon, Mar 28, 2016 at 3:58 PM, Jehan Tremback <jehan.tremback@gmail.com>
> wrote:
>
>> ebXML looks like it would add a ton of complexity.
>>
>> On Mon, Mar 28, 2016 at 12:39 PM, Joseph Potvin <jpotvin@opman.ca> wrote:
>>
>>> Lichen is being structured as a full reference implementation of UBL.
>>> Most UBL implememtations cherry-pick according to context. Cherry-picking
>>> can be done in a UBL standard conformant way. With Lichen Xalgorithms, we
>>> don't assume a context any more specific than "commerce".
>>>
>>> UBL is derived from ebXML / EDI, but is much reduced in complexity. But
>>> it accommodates a great divesity of use cases and specialize requirements.
>>> And it has some fields that accommodate semantic flexibility, with the
>>> result that to some degree extensions can be in the sematics rather than in
>>> the data structure per se.
>>>
>>>
>>>
>>> Joseph Potvin
>>> Operations Manager | Gestionnaire des opérations
>>> The Opman Company | La compagnie Opman
>>> jpotvin@opman.ca
>>> Mobile: 819-593-5983
>>> LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>
>>>
>>> On Mon, Mar 28, 2016 at 3:15 PM, Roger Bass <roger@traxiant.com> wrote:
>>>
>>>> You were suggesting, Adrian, that the scope of any such B2B effort
>>>> might be quite large. That may be so - in which case, it probably would be
>>>> premature to work on it (as you also suspect: Adrian, Zaki).
>>>>
>>>> That said, to the extent that the ebXML stack as well is written in a
>>>> layered way, and is reasonably mature, it may be that the relevant scope
>>>> could be limited to the definition of bindings between the relevant
>>>> protocol layers. I'm looping in some of the folks more expert on this than
>>>> I am to discuss this. Such an effort might also seem more worthwhile if the
>>>> scope were narrowed to focus on a more specific use case. One possible
>>>> scenario relates to a (B2B-oriented) payer-to-payee message that could be
>>>> "settled" via multiple alternate networks (card, ACH... and perhaps ILP) -
>>>> a check alternative, if you will. (The message itself would be an ISO 20022
>>>> message, though there would likely some other protocol pieces involved).
>>>> From my perspective at least, it may be that interest in the non-ILP
>>>> scenarios are more critical to determining if this moves forward. But if it
>>>> does, defining ILP bindings for this could become quite interesting.
>>>>
>>>> Roger
>>>>
>>>>
>>>> On Mon, Mar 28, 2016 at 12:00 PM, Adrian Hope-Bailie <
>>>> adrian@hopebailie.com> wrote:
>>>>
>>>>> > My sense is that is premature to try to standardize now but I think
>>>>> experience reports will be very valuable from those who can share them.
>>>>>
>>>>> +1 - that's why we're working on a very simple application layer
>>>>> protocol to start with and not trying to incorporate any baggage from other
>>>>> standards or frameworks yet.
>>>>>
>>>>> As the core ILP foundation solidifies the direction to take with
>>>>> higher level functions will become clearer. It's quite possible that some
>>>>> of the early application layer protocols may even disappear as the stack
>>>>> matures. Anyone remember Gopher :)
>>>>>
>>>>> On 28 March 2016 at 16:38, zaki@manian.org <zaki@manian.org> wrote:
>>>>>
>>>>>> Skuchain is pretty committed to bring Interledger to B2B use cases
>>>>>> and preliminary indications are that  ISO20022 might be the way to
>>>>>> go.
>>>>>>
>>>>>> My sense is that is premature to try to standardize now but I think
>>>>>> experience reports will be very valuable from those who can share them.
>>>>>>
>>>>>> On Mon, Mar 28, 2016 at 8:04 AM, Joseph Potvin <jpotvin@opman.ca>
>>>>>> wrote:
>>>>>>
>>>>>>> RE: "the Interledger architecture is layered... there is scope for a
>>>>>>> more complex and rich application layer protocol that is more targeted at
>>>>>>> "enterprise" use cases"
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> RE; "to begin developing another application layer protocol that is
>>>>>>> focused on B2B and leverages existing standards like ebXML. ISO20022 or UBL
>>>>>>> then that would be great:
>>>>>>>
>>>>>>> In part, like this?
>>>>>>> https://github.com/Xalgorithms/xa-arch/blob/master/README.md
>>>>>>> https://www.xalgorithms.org/
>>>>>>>
>>>>>>>
>>>>>>> RE: It is a far larger task than the current group could take on but
>>>>>>> I'd certainly support it and try to get involved as time allows.
>>>>>>>
>>>>>>> Xalgorithms Foundation (XF) has not yet been reaching out much. An
>>>>>>> initial group is doing some grunt work to determine which specific
>>>>>>> functions we'll target and how, and which parts are for others to do. i.e.
>>>>>>> Which the internal functions of OSI Layer 7 can we enhance with the our two
>>>>>>> contributions?)  Our scope is much narrower than you described for Layer 7
>>>>>>> work, only some component parts. Some structure for our work is now getting
>>>>>>> posted to Github. We haven't yet got much of any use for anyone to
>>>>>>> download. At present we're creating a limited working proof-of-concept.
>>>>>>> There's also a fully-scalable free/libre/open pathway in planning.
>>>>>>>
>>>>>>> Starting on 6 April at 2:30 EST, XF will be hosting an
>>>>>>> open-to-anyone 30 min "Xalgorithms Tech Weekly Forum" on Google Hangout.
>>>>>>> I'll share details shortly.
>>>>>>>
>>>>>>> Anyone with specific enquiries (which may be out-of-scope for this
>>>>>>> email list) can contact me directly via jpotvin@xalgorithms.org
>>>>>>>
>>>>>>> Joseph Potvin
>>>>>>> Executive Director, Xalgorithms Foundation
>>>>>>> Mobile: 819-593-5983
>>>>>>> jpotvin@xalgorithms.org
>>>>>>> https://www.xalgorithms.org
>>>>>>> <http://t.sidekickopen06.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XYgdDM1sVRYyfn4XXSbTVd0r_-56dVbMd4C5Ts02?t=https%3A%2F%2Fwww.xalgorithms.org%2F&si=6060383291310080&pi=e92aa223-ebe7-4a9d-e849-f83c11b9920b>
>>>>>>>
>>>>>>> On Mon, Mar 28, 2016 at 6:13 AM, Adrian Hope-Bailie <
>>>>>>> adrian@hopebailie.com> wrote:
>>>>>>>
>>>>>>>> From the discussion around payment to invoices there appears to be
>>>>>>>> a number of views that the current application layer protocol is not
>>>>>>>> meeting the needs of all B2B use cases.
>>>>>>>>
>>>>>>>> Further, there is a suggestion that there are a number of existing
>>>>>>>> protocols and standards that we should be leveraging.
>>>>>>>>
>>>>>>>> It's important to note that the Interledger architecture is
>>>>>>>> layered, intentionally, to resemble something like the OSI model for
>>>>>>>> communications protocols. At the lowest layers are very simple protocols
>>>>>>>> that have a specific purpose but these build up to an application layer
>>>>>>>> where it is possible to construct a number of application layer protocols
>>>>>>>> that are built on the lower layer primitives and fit for a particular
>>>>>>>> purpose.
>>>>>>>>
>>>>>>>> I'd compare these to communications stack protocols like HTTP and
>>>>>>>> FTP. These two protocols are built on the same underlying IP-based stacks
>>>>>>>> but were designed for very different purposes.
>>>>>>>>
>>>>>>>> Right now OWPS is intended to be a very simple application layer
>>>>>>>> protocol primarily designed to handle P2P payments or very simple C2B
>>>>>>>> payments (i.e. 1:1 payment to invoice). It has very specific design
>>>>>>>> principles which may not be appropriate for a lot of use cases (such as
>>>>>>>> being operatorless). This protocol may evolve but it's unlikely to ever be
>>>>>>>> a rich protocol that incorporates comprehensive stacks like ISO20022 or
>>>>>>>> ebXML.
>>>>>>>>
>>>>>>>> Rather than trying to turn OWPS into a protocol that can handle all
>>>>>>>> use cases I'd suggest there is scope for a more complex and rich
>>>>>>>> application layer protocol that is more targeted at "enterprise" use cases.
>>>>>>>>
>>>>>>>> If there is a willingness within this group to begin developing
>>>>>>>> another application layer protocol that is focused on B2B and leverages
>>>>>>>> existing standards like ebXML. ISO20022 or UBL then that would be great.
>>>>>>>>
>>>>>>>> It is a far larger task than the current group could take on but
>>>>>>>> I'd certainly support it and try to get involved as time allows.
>>>>>>>>
>>>>>>>> Adrian
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>