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

Re: A B2B application layer protocol for Interledger?

From: Joseph Potvin <jpotvin@opman.ca>
Date: Mon, 28 Mar 2016 15:39:27 -0400
Message-ID: <CAKcXiSp0Wvn5yyE6Rnmn6D=gTZeGF-2iwrOCom54oZnnd9RWmg@mail.gmail.com>
To: Roger Bass <roger@traxiant.com>
Cc: 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>
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:40:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 28 March 2016 19:40:18 UTC