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: Use case for interconnecting national infrastructures


Dear Dale, Roger and all

Thank you for your very interesting comments and reflections on the requirements and scenarios discussed. I agree with Dale's comment that we need to start organizing and structuring the requirements and use cases. I very much like the use case template used by the Id-cloud TC. Unless someone has a better alternative?

An additional, and very relevant use case emerging from the PEPPOL project is connecting European national infrastructures to PEPPOL's pan-European community. I believe the use case is already somehow contained within the various scenarios described by Roger, and that the technical requirements are already covered by Dale's "DNS generalization scheme". To give some background:

PEPPOL is a community for cross-border transactions between European Union countries (and potentially others). It is a mandatory requirement within PEPPOL that all participants in the community comply with the defined interoperability standards, both on a protocol level (SMLP and START) and on a semantic and business requirement level (PEPPOL BIS document standards and business rules). There are countries who already have national infrastructures in place for electronic trade. These countries typically connect their national infrastructures to PEPPOL through the establishment of a national gateway. There are other countries (or at least one other for now) who have completely replaced their national infrastructure with the PEPPOL infrastructure. In this case, all national parties are automatically registered in PEPPOL and consequently must comply with PEPPOL requirements, also for their domestic transactions. Both these scenarios are covered by the current PEPPOL specifications.

A third scenario exists where a country wants to adopt PEPPOL standards (=BDXR) for their national infrastructure and wants to align national technical standards with PEPPOL, but do not wish that their economic operators automatically are registered as PEPPOL participants. The specific reason for this is that European Union legal requirements for exchanging electronic business documents across borders differ from local national requirements (document archiving, registration etc.). It is seen that registering cross-border "readiness" and capabilities in the PEPPOL cloud imposes additional legal and administrative requirements on economic operators (besides the technical requirements). These countries therefore want to create a national community, parallel to the PEPPOL community and with local operators being able to reuse investments in standards and technology, but with a strict opt-in policy for registering national participants in the PEPPOL community.

The general requirement here really is to be able to interconnect specific users of two (or more) multi-cornered infrastructures, with the first corner being in one cloud and the fourth corner being in another cloud, and without having to multiply all components (gateways, SMP's etc.). In many ways this asks some of questions that Dale and Roger already started addressing, and I think the use case has multiple uses also outside of Europe and PEPPOL. One part of the requirement (service discovery) can be solved within the proposed SMLP architecture simply by having each community (or "cloud") establish their own SML. However, the proposed SML specifications doesn't support the existence of more than one SML service, this also doesn't solve the trust issues involved. I think(!) that both issues can be easily accommodated for using Dale's NAPTR scheme(?).

Best regards,

Kenneth



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