Minutes of Pacific BDXR TC call 25 May 2022 15:00UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=2022-05-25T15:00:00 Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe Participation Kenneth Bengtsson (chair) Erlend Klakegg Bergheim Sander Fieten Pacific call: Kenneth Bengtsson (chair) Levine Naidoo Standing items TC Vitality The TC must next appoint or reappoint chair(s) in January 2023. Next TC vitality check must be made in January 2025. Review of Pacific call minutes
https://lists.oasis-open.org/archives/bdxr/202205/msg00001.html Review of Atlantic call minutes
https://lists.oasis-open.org/archives/bdxr/202203/msg00003.html Membership status review
https://www.oasis-open.org/policies-guidelines/tc-process#membership Voting status is determined by the following: - existing voting members must not miss two consecutive meetings to maintain voting status - non-voting members must attend two consecutive meetings to obtain voting status - members formally on leave by prior request must not attend and their voting status is not impacted Current BDXR TC voting member list (alphabetical): - Kenneth Bengtsson - Erlend Klakegg Bergheim - Kees Duvekot - Sander Fieten - Levine Naidoo Overview of the four-corner model Committee Note The TC resumed work on the four-corner model committee note. Kenneth to distribute new “clean” version with edits made today. Levine has forwarded text about governance. Kenneth will incorporate into the Committee Note. Agreed to write small sections explaining the concepts of “semantics/data” and “governance/directives”. BDXL BDXL 1.0 A ticket was created pointing out an issue with regular expressions in the BDXL 1.0 examples. It was agreed at the TC meeting November 25 to focus on BDXL 1.1 first, and then look at a possible BDXL 1.0 errata after that.
https://issues.oasis-open.org/browse/BDXR-29 BDXL administration API Proposal from Erlend:
https://lists.oasis-open.org/archives/bdxr/201905/msg00015.html There have been discussions within Peppol regarding requirements for the BDXL Administration API. Sander will reach out to the involved participants to gather further requirements. Agreed that the updated BDXL 1.1 specification will mention the BDXL Administration API and its features for updating and maintaining BDXL records. Discussed that the BDXL Administration API could include a section for how to update a primary BDXL in a federated model. Steps forward: 1) Map the API interface from the existing specification previously submitted to the TC (Kenneth) 2) Describing functionality (group) 3) Work on XML and JSON bindings (Sander, Dennis and Kenneth) Kenneth presented a map of the Peppol SML registration interface as well as a class diagram showing the data model. It was discussed that the data model for the BDXL administration API may need to be developed in parallel to the API if special functions such as batch updating (“grouping” participants with services) need to be supported. Diagrams used for discussions:
https://lists.oasis-open.org/archives/bdxr/202007/msg00017.html . Discussed whether NAPTR records other than “U”-flag records are allowed in BDXL 1.0, and whether redirect type NAPTR records can be used as a strategy. Agreed that we need to advance further with the updated BDXL specification before moving forward with the API. It was agreed at the August 12 TC meeting that the introductory sentence in section 2.2 (normative), which states that “Because the goal is to find URLs, the NAPTR RR with “U” value in its Flags field (U-NAPTR)” narrows the scope of U-NAPTR records in the specification to those with “U”-flags, and that “U-NAPTR” elsewhere in the specification consequently refers to only those NAPTR records with “U”-flags. BDXL 1.1 Starter document received from OASIS:
https://lists.oasis-open.org/archives/bdxr/202002/msg00015.html Discussed that the hostname to look up the NAPTR record (commonly done as “BASE32([SHA256 hash of participant ID])” and “B-[MD5 hash of participant ID]”) should be standardized. Should we include a methodology for including multiple SMPs in the SML? Federated SML Agreed to add a section about BDXL network federation to BDXL 1.1. Both Peppol, the Business Payment Coalition and CEF are working towards federated BDXL designs. Requirement from CEF eDelivery for BDXL/SML client lookups in multiple DNS zones:
https://lists.oasis-open.org/archives/bdxr-comment/202111/msg00002.html . BPC rationale is to create competition among several BDXL service providers, allowing network participants to freely choose among available services. All BDXL services will offer similar and compatible services. Requirements:
https://lists.oasis-open.org/archives/bdxr/202006/msg00003.html Peppol is looking at delegating control of different participant identifier schemes to different SML services, as well as possibly separating groups of participants based on their ID. There would be an algorithm that enables APs to locate the appropriate SML service based on the calculation of the participant identifier. Part of the rationale is that the transactional footprint on the current SML has increased with the addition of DNSSEC, and grouping participants into different SML services is a strategy for distributing the load. Discussion paper for multiple registration services with only one DNS provider:
https://lists.oasis-open.org/archives/bdxr/202006/msg00003.html Discussed that in DNS, zone changes are replicated from primary DNS to secondary DNS services through zone transfers and that the update of primary DNS services can be done using DNS Update:
https://tools.ietf.org/html/rfc2136 Sander and Kenneth had a meeting to come up with a proposal for an architectural drawing of a federated BDXL model within the complete 4-corner network. The outcome is shared here:
https://lists.oasis-open.org/archives/bdxr/202007/msg00010.html Discussed that the BDXL specification could/should hold information about the current registrar service of a given participant, so that BDXL and registrar services can prevent unauthorized updates of participant identifiers registered through a different registrar service. Discussed to include a non-normative section describing different network policies and approached to KYC and participant registration. Kenneth will begin drafting an introduction for BDXL 1.1. discovery through Blockchain Agreed to explore whether a blockchain based discovery can be standardized. TC conference call schedule Face-to-face meeting Invitation to meet in Oslo together with the UBL meeting, for example back-to-back with the Exchange Summit Europe second half of 2022. Call schedule Agreed to cancel the meeting 23/2 and then every second meeting for the months of March and April. Agreed to cancel meetings for the month of March. Next TC meeting will be April 13/14. 2022-08-02/2022-08-03 - Pacific: 17:00MSP/00:00Europe/18:00Ottawa/22:00UTC/08:00Sydney - Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe 2022-09-06/2022-09-07 - Pacific: 17:00MSP/00:00Europe/18:00Ottawa/22:00UTC/08:00Sydney - Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe 2022-10-04/2022-10-05 - Pacific: 17:00MSP/00:00Europe/18:00Ottawa/22:00UTC/ 09:00Sydney - Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe 2022-11-01/2022-11-02 - Pacific: 17:00MSP/ 23:00Europe /18:00Ottawa/22:00UTC/09:00Sydney - Atlantic: 11:00MSP / 12:00Ottawa / 16:00UTC /17:00Europe 2022-12-06/2022-12-07 - Pacific: 16:00MSP /23:00Europe/ 17:00Ottawa /22:00UTC/09:00Sydney - Atlantic: 10:00MSP / 11:00Ottawa /16:00UTC/17:00Europe Other business Agreed to move forward with the AS4 Profile for Four-corner Networks as a candidate OASIS Standard. The TC agreed that it has no urgent business for the moment being. We have produced 4 OASIS Standards (with one more in the pipeline) and countless Committee Specifications in recent years, which have globally facilitated and shaped the standardization of e-delivery. The TC will use the remainder of this calendar year to keep monitoring the use of our work products and see if any action is necessary, but apart from moving forward with the AS4 Profile as a candidate OASIS Standard we have no current action items. The BDXR TC is therefore going on a summer vacation and will convene again on August 2 (Pacific) and August 3 (Atlantic). The meeting schedule from August and until the end of the year is monthly, every first Tuesday/Wednesday of the month.