This submission by the CEF eDelivery team is provided in relation to the initiative proposed in this conversation:
https://lists.oasis-open.org/archives/bdxr/202006/msg00003.html
and to the e-Delivery Network Feasibility Assessment detailing several options for the how the BDXL standard can be modified to support a federated model of governance:
https://businesspaymentscoalition.org/wp-content/uploads/20191031-bpc-e-delivery-network-feasibility-assessment.pdf
Background: During the past years, CEF eDelivery has been closely involved in many European cross-border projects to promote and facilitate the electronic message exchange for various networks of participants (business domains), including OpenPEPPOL.
CEF eDelivery builds on the OASIS ebMS 3.0 with AS4 profile and on OASIS standards BDXL v1.0 and OASIS SMP 1.0 for dynamic discovery of the participants' message exchange capabilities.
The CEF eDelivery SML Service, based on BDXL v1.0, is designed to support message exchange networks in the initial (bootstrapping) stages. When the networks reach maturity and start to require high availability and/or a large number of participants, they need
to switch operations to their own BDXL-compatible service. To allow such transitions to take place in a gradual manner, rather than a big bang one, the updated BDXL standard should allow multiple SML service providers to coexist in a message exchange network.
To that end, we propose to update the BDXL v1.0 standard (http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/BDX-Location-v1.0.html)
with the following chapter:
2.4.1 Fallback discovery flow
To:
-
increase the reliability of DNS resolution,
-
allow a gradual transition in a business document exchange network from one DDDS service provider / hosting domain path to another,
-
allow creating a multi-tiered (e.g., regional/continental/global) federation of DDDS service providers
the business document exchange network MAY provide one or more fallback DNS query paths from which the U-NAPTR record can be retrieved. To this end, DDDS client applications SHOULD allow for the configuration of multiple hosting domain paths. The fallback DNS
query path(s) MUST be used only if the primary DNS query path did not return a result. Whether one or multiple fallback DNS query paths are used in a business document exchange network, as well as the strategy for selecting the query order among them, are
not in scope of this specification; they are typically defined by the network.
Kind regards
Joze Rihtarsic