Re: A B2B application layer protocol for Interledger?

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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>