- From: Jehan Tremback <jehan.tremback@gmail.com>
- Date: Mon, 28 Mar 2016 12:58:06 -0700
- 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>
- Message-ID: <CABG_PfRjk70KG0-yaCNJf4rRxy6B9J1xxJ910Bx6Rmww4m6+rg@mail.gmail.com>
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:38 UTC