Re: A B2B application layer protocol for Interledger?

Roger, Joseph,

I think it would be a shame to take this discussion off the public list as
the B2B use cases are most certainly relevant to the group. SkuChain have
been active group participants and as Zaki says are pretty committed to
bringing ILP to the B2B use cases.

I think we will find the discussions here begin to become either focused on
the core ILP technology or the more use case specific application layer
technologies.

There are two ways we can segment these discussions to a) ensure there is a
forum for everyone to discuss what is important to them and b) not create
so much noise that contributors find it a distraction:

1. We can create a separate list for use case specific discussion,
something like public-interledger-usecases@w3.org
2. We can try to use subject line filters to assist folk to filter out
threads they aren't interested in example, start subject s with "[use
cases]" or "[b2b]" or similar.

I'd favour option 1 as it's a pretty trivial thing to setup and then allows
that list to even frther segment their threads based on specific use cases
using subject line filters.

What would be everyone's preference?



On 28 March 2016 at 22:08, Joseph Potvin <jpotvin@opman.ca> wrote:

> RE: "not comparing apples and apples in talking about..." & "this
> discussion is perhaps getting increasingly arcane, and even off-topic"
>
> Agreed. :-)  I was just providing some background to the breadth of
> applied-UBL activity, since it takes some poking around to sift out and
> make sense of it. I almost changed the subject line to "UBL [WAS: A B2B
> application layer...]"
>
> Happy to discuss details off-list jpotvin@xalgorithms.org
>
> Joseph Potvin
> Executive Director, Xalgorithms Foundation
> Mobile: 819-593-5983
> jpotvin@xalgorithms.org
> https://www.xalgorithms.org
>
> On Mon, Mar 28, 2016 at 4:56 PM, Roger Bass <roger@traxiant.com> wrote:
>
>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>