OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [bdxr] AW: PEPPOL's support for SMEs

Kenneth, Susanne,


From your last emails, I’m not sure we’re yet 100% aligned on our definitions of “Semi-automated” and “Fully automated” setup processes.  Of course, my presentation is this scheduled for next week’s meeting, and we’ll have an opportunity to discuss then.  That said, I’ll share a couple of thoughts here on defining these terms.


It seems to me that both PEPPOL and (from Susanne’s email) e-CODEX currently have an essentially open, email-like model, without explicit authorization of relationships.  As you said, there might be ‘spam filter’ like mechanisms on top of that, but up to now, I’ve not heard that those mechanisms formed part of the formal requirements.  Nor have I yet heard if there’s a use case for you where an email invitation is the trigger for setup of an access point/mailbox.  The question of possible future requirements in those LSPs for explicit relationship authorization is really your domain rather than mine.  However, in procurement/supplier network systems other than PEPPOL, I would observe that explicit relationship setup processes are the norm rather than the exception.


In both these cases, the user may indeed have nothing to do to get connected (beyond publishing their ‘address’ in some form). However, as a matter of definitions, it’s perhaps not helpful to think of this as a “Fully automated relationship setup process”.  The “relationship” this is intended to refer to is more like the social network scenario where that the relationship is explicit for both parties.  (Email whitelisting scenarios can be similar, though that setup process is not necessarily conversational).


“Semi-automated” was intended to refer to the scenario where one entity (typically the large/enterprise) has an automated process for inviting partners (e.g. SMB suppliers) to get connected, but where the initial steps on the partner end are at least partially manual, i.e. clicking on an email link.  This is still different from typical supplier on-boarding processes today, however, in that the human actions would include identification of a system that they designate as their proxy or gateway (corner 3), followed by some automated setup dialog between the gateways (corners 2 and 3 out of 4).  (We may need a better term than “semi-automated” to express this).


Susanne, I understood from your email that the e-CODEX model is actually really more of a 6-corner model, in that the access point for the end user is separate from the gateway.  The extent to which any of this matters to the e-CODEX use case may depend partly on whether an end-user is simply assigned a mailbox/access point/service provider in a given national/local domain, or whether they have some ability to select.  In particular, for scenarios where full, machine-to-machine automation is desired, it’s generally going to be up to each user to say which ‘machine’ (i.e. software application) they actually use.  The access point/service provider that gets set up for them would then be determined (or at least constrained) by that choice.


Best regards,




From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Kenneth Bengtsson
Sent: Thursday, May 24, 2012 8:53 AM
To: Roger Bass; bdxr@lists.oasis-open.org
Subject: Re: [bdxr] AW: PEPPOL's support for SMEs


Susanne, Roger et.al.


I very much like what you are describing here. The "fully automated" process is roughly what PEPPOL aims at, and both scenarios are very very interesting. I very much look forward to the coming presentations and discussions.


We have quite a lot for the agenda for the coming meetings. Last week, one hour was hardly enough for two presentations and we didn't have any time for discussions and questions. I propose that next week, and while we are in this "requirements discovery phase" we instead schedule two hours for the meetings. Any strong objections?


Best regards,





From: Roger Bass <robass1@earthlink.net>
Date: Monday, May 21, 2012 1:03 AM
To: <bdxr@lists.oasis-open.org>
Subject: RE: [bdxr] AW: PEPPOL's support for SMEs


Susanne, Kenneth,


I, for one, look forward to hearing you elaborate further, as you say Susanne, on your specific discovery requirements.  You refer to use cases involving human processing vs direct EDI integration.  You didn’t say enough for me to be sure, but I wonder if this relates to the two scenarios I will be touching on in my presentation, rescheduled from last time.  I did already upload one version of that, though I may update it further.  Those two use case scenarios there are for “Semi-Automated” and “Fully Automated” setup of an electronic (EDI-like) trading relationship between two parties, including the mutual authorization step.  I’ll say more next time, but “semi-automated” is roughly a B2B analog of the social network “invitation” scenario.  “Fully automated” but anticipates two previously-authorized gateway systems (i.e. corners 2 and 3) automatically detecting that their respective users (corners 1 and 4) have a business relationship, and then performing the required setup steps without any human intervention being required at all.


This also relates, I think, to the discussion about SME support in this broad sense: making users’ experiences as simple as possible matters for adoption everywhere, but most especially for SMEs.  And in this context, I think that means defining a model for setting up relationships that’s as easy as possible, including extensibility to relationships #2, 3… etc.  In this specific sense, I think we do care about standardizing interactions beyond just those between the gateways (corners 2 and 3), although I agree with your point as regards the flow of the business documents themselves.  I do also agree about the importance of “Circles of Trust” as you call them (or “Trust Frameworks”, in the more commonly used industry term), i.e. the legal governance structures that link the connected entities/gateways.  However, many of the required features effectively require a “Chain of Trust” between the end user parties.  That being so, it’s also important that one gateway be able to trust another SPECIFICALLY AS THE AUTHORIZED AGENT FOR A SPECIFIED END USER, so the process by which that authority gets established also matters.


At the technical level, I think this relates very much to the material Dale presented last time.  Pim has also referred to a notion of a “Connect” protocol that also seems closely related to these ideas.  I expect all this will be presented to the TC in due course, even with it probably being in a “work in progress” state.


Overall, I’m gratified by the rough alignment I see between the ideas and requirements that we’re each seeing, albeit coming from rather different perspectives.  I’m hopeful that the discussions over our next few meetings will help us to further converge the TCs thinking about more specific goals/requirements and technical deliverables.  I hope this email may perhaps have helped point out some of the points of commonality.






From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Susanne.Wigard@it.nrw.de
Sent: Sunday, May 20, 2012 3:25 PM
To: kenneth@alfa1lab.com; bdxr@lists.oasis-open.org
Subject: [bdxr] AW: PEPPOL's support for SMEs


Dear Kenneth,


Good to hear the e-CODEX presentation was useful, I felt somewhat insecure about what is interesting to this group and what isn't. What I'd like to do at some later point in time, maybe in a few weeks, is elaborate a bit more on the particulars of our discovery requirements.

Also if ever it fits, I would find it interesting to discuss the differences between uses cases that involve some human processing vs. direct EDI application integration.


The 4-corner-drawing I've not only seen but also quoted in our own e-Delivery document ;)


Thank you for your clarification on SME support - if that's basically about not assuming any specific capabilities on the 1st and 4th corner, that would in e-CODEX again map to subsidiarity - existing national systems remain untouched, whatever they may be (and whatever their technical maturity).  

However, there seems to be some small difference: where in PEPPOL SMEs can rely on a (commercial) service provider, e-CODEX gateways will be run by governments (ministries of justice), and so they will for their own country define minimum requirements to connect to that gateway.

In some countries as far as I know the national "Registered Email" solutions are in fact commercial, but these service providers don't run their own e-CODEX gateways, but will be connected to the one of their country.  

Somewhat confusingly, what we call "service providers" are the technical systems connected to the gateways, so these sit rather on the 1st and 4th corner.

The agreements between the entities running the gateways (that correspond to the PEPPOL agreements) are the basis of what we call the "Circle of Trust" (the legal details of which are still in the making).

Similar to PEPPOL, we also standardize only what's between the 2nd and 3rd corner; how end entities communicate with the gateways is up to the Member States. (We do have defined a backend interface for the "default" implementation we provide for our partners, however in principle countries can change / replace that backend interface or use an altogether different implementation, as long as it communicates with the other e-CODEX gateways via the standardized (ebMS) protocol.)

In fact, we can probably learn a lot from PEPPOL in terms of interoperability agreements.   


What corresponds to PEPPOL's service providers, catering for different needs of different user groups, are for e-CODEX the ministries, catering for the needs of their judicial IT infrastructures.


We're not so much concerned about demand and supply - it's governments that decide they have a demand for cross-border e-Justice, and who then decide to run an e-CODEX gateway (and by joining the project as a piloting country, they have already implicitly made that decision).


So in sum you are right that this requirement maps not so much to ours of avoiding proprietary infrastructures, but to the one already mentioned, that (where you have no requirements for SMEs) we have no requirements for the national systems (e.g. case management systems) nor to how they are connected to the e-CODEX gateways (e.g. .some secure national transport infrastructure, or, in the extreme case, gmail).

Thank you for pointing this out.


Regarding your last remark, that you "see that a similar structure can support your use case for connecting judicial authorities" let me just mention that we view the citizens’ communication via the European e-Justice portal just as a special case of this - in fact the e-Justice portal wants to connect to the e-CODEX infrastructure through e-Trustex, very much like e-Trustex is connected to PEPPOL.


Best regards






Von: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] Im Auftrag von Kenneth Bengtsson
Gesendet: Donnerstag, 17. Mai 2012 02:07
An: bdxr@lists.oasis-open.org
Betreff: [bdxr] PEPPOL's support for SMEs

Dear Susanne


Thank you very much for your interesting presentation today. I actually learned something and now understands e-CODEX somewhat better (I think) :-)


I'm attaching the PEPPOL 4-corner drawing that I know you've already seen a million times, but just as a visual aid to help me elaborate on how PEPPOL supports SMEs:


The "private company" in the drawing can be any company who supplies to public sector in Europe. It may be a medium sized or a large company who already does EDI and is well-equipped to implement new standards and procedures, but it may also be a one-man company whose technical capabilities are limited to the use of Gmail. The last example may be a bit extreme, but the point is that PEPPOL cannot assume any capabilities or assign any technical responsibilities to the "1st and 4th corner" of the infrastructure.


Instead the responsibilities are placed on the shoulders of the "2nd and 3rd corners" - the service providers (acting as intermediaries):


First of all, service providers required to comply with a set of technical standards and specifications, assuring that every service provider connecting to PEPPOL is able to exchange documents with every other service provider connecting to PEPPOL.


Secondly, the service provider is required to sign an agreement with PEPPOL that obligates him to perform certain functions and to provide a certain level of service. This agreement covers (among other things) an obligation to receive messages to his end-users sent through any other service provider in the PEPPOL infrastructure, and to make sure these messages (if compliant with PEPPOL requirements) are delivered all the way to the end-user. The agreement also covers that the service provider must accept messages from his end-users intended for any other end-user of the infrastructure, and that he must deliver these message to the service provider of the recipient in a manner compliant with PEPPOL requirements and specifications. The PEPPOL service provider agreement does not cover how service providers must interact with their end-users, only that they must relay message to and from their end-users. In other words, it is only the message exchange between the 2nd and the 3rd corner that is standardized in PEPPOL.


The theory here is that where there is a demand there will also be a supply. Where there are companies who want to fully integrate their ERP systems there will also be service providers offering to connect them, and where there are companies who think that Gmail is already a mouthful there will also be service providers who can cater for their needs. Because service providers are obligated to always relay messages between their end-users and other providers in the PEPPOL infrastructure, then every SME (as well as every large organization) has the freedom to choose the service provider that best matches their needs and capabilities, completely independent from what service is used by their trading partner.


In a way you can say that for PEPPOL, the "technical requirement derived from SME support" is that there are no technical requirements for SMEs. Only for their service providers. My take is that this differs a bit from the e-CODEX requirement of avoiding "expensive and proprietary infrastructures" - at least to my understanding but please put me back in my place if I am wrong. I can also see that a similar structure can support your use case for connecting judicial authorities.


Best regards,





From: <Susanne.Wigard@it.nrw.de>
Date: Monday, May 14, 2012 5:11 AM
To: <bdxr@lists.oasis-open.org>
Cc: <giorgia.lodi@digitpa.gov.it>, <Raia@digitpa.gov.it>
Subject: [bdxr] e-CODEX use cases and requirements


Dear TC,


Please find attached a first impression of the use cases and requirements from the e-CODEX project (www.e-codex.eu). Since the requirements are, at this level, very similar to the ones from PEPPOL, I have referenced Kenneth's presentation and added the e-CODEX viewpoint for better comparability.


Best regards





--------------------------------------------------------------------- To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdxr-help@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]