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

Re: A B2B application layer protocol for Interledger?

From: Jehan Tremback <jehan.tremback@gmail.com>
Date: Mon, 28 Mar 2016 12:58:06 -0700
Message-ID: <CABG_PfRjk70KG0-yaCNJf4rRxy6B9J1xxJ910Bx6Rmww4m6+rg@mail.gmail.com>
To: Joseph Potvin <jpotvin@opman.ca>
Cc: Roger Bass <roger@traxiant.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, "zaki@manian.org" <zaki@manian.org>, Interledger Community Group <public-interledger@w3.org>, Web Payments CG <public-webpayments@w3.org>, Pim van der Eijk <pvde@sonnenglanz.net>
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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Monday, 28 March 2016 19:58:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 28 March 2016 19:58:37 UTC