Minutes of Atlantic BDXR TC call 13 January 2021 17:00UTC

http://www.timeanddate.com/worldclock/fixedtime.html?iso=2021-01-13T17:00:00

Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe

Participation

Todd Albers

Kenneth Bengtsson (chair)

Erlend Klakegg Bergheim

Sander Fieten

Philip Helger

Ken Holman

Pacific call:

Kenneth Bengtsson (chair)

Ken Holman

Levine Naidoo

Regrets:

Dennis Weddig

Standing items

Review of Pacific call minutes

https://lists.oasis-open.org/archives/bdxr/202101/msg00016.html

Review of Atlantic call minutes

https://lists.oasis-open.org/archives/bdxr/202101/msg00004.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):

- Todd Albers

- Kenneth Bengtsson

- Erlend Klakegg Bergheim

- Sander Fieten

- Ken Holman

- Levine Naidoo

- Dennis Weddig

TC Vitality check

As described in the new TC Process (https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26/#tcVitality), we need to perform a vitality check every 4 years and decide one of the following actions:

- Continue the TC with its current charter;

- Continue the TC through a charter clarification;

- Recharter the TC; or

- Close the TC.

At the same time, the TC must appoint or reappoint chair(s).

Charter clarification

At last week’s call it was discussed that the TC wants to continue its work, though clarifying in its charter that START and LIME protocols are no longer within our scope of work. A draft charter clarification has been shared here: https://lists.oasis-open.org/archives/bdxr/202101/msg00006.html

Does the TC approve the Chair requesting that TC Administration hold a Special Majority Ballot to approve the charter clarification contained in https://lists.oasis-open.org/archives/bdxr/202101/msg00006.html?

Kenneth made the motion. Seconded by Levine. Approved by all members of the Pacific and Atlantic calls.

Appointment of chair(s)

The process of (re)appointing chair(s) is defined here: https://www.oasis-open.org/policies-guidelines/oasis-committee-operations-process/#chairs

A call for candidates has been sent out here: https://lists.oasis-open.org/archives/bdxr/202101/msg00005.html. Following the call for candidates, TC members have 7 days to propose themselves as candidates. So far only Kenneth has proposed himself as candidate. It was agreed that Kenneth be reappointed chair of the TC.

SMP 2.0

Public review of SMP 2.0 Candidate OASIS Standard ended 18 December. Comments received:

- https://lists.oasis-open.org/archives/bdxr-comment/202012/msg00000.html

Draft comment resolution log has been uploaded here: https://www.oasis-open.org/committees/document.php?document_id=68140&wg_abbrev=bdxr

The only change proposed in the draft comment resolution log is the addition of the words “in the BDXL” to section 2.1.1 to clarify that “Each Participant is registered in the BDXL with one and only one Service Metadata Publisher”. No other changes are proposed.

A Working Draft 09 with the above change is uploaded here: https://www.oasis-open.org/committees/document.php?document_id=68141&wg_abbrev=bdxr. The package contains both a “clean” version of the specification as well as a version with change tracking enabled.

Does the TC approve the Chair requesting that TC Administration hold a Special Majority Vote to approve Working Draft 09 of Service Metadata Publishing (SMP) Version 2.0 and all related artifacts contained in https://www.oasis-open.org/committees/document.php?document_id=68141&wg_abbrev=bdxr as Candidate OASIS Standard 02 and present this Candidate OASIS Standard to the membership for an OASIS Standard vote in accordance with the procedures documented in 3.4.2, “Public Review of a Candidate OASIS Standard” in the OASIS TC Process?

By passing this motion, the TC affirms that (a) Working Draft 09 contains changes from Candidate OASIS Standard 01; (b) that the changes made are documented in https://www.oasis-open.org/committees/document.php?document_id=68140&wg_abbrev=bdxr as well as in the track changes version of the Word document contained in the Working Draft 09 package; (c) that these changes are Non-Material; and (d) that these changes are made ONLY to address the comments received during the public review period.

Kenneth made the motion. Seconded by Levine. Approved by all members of the Pacific and Atlantic calls.

Exchange Header Envelope (XHE)

XHE 1.0 CSD03 Committee Specification 03 has been approved. Announcement: https://www.oasis-open.org/2020/12/17/exchange-header-envelope-xhe-v1-0-from-bdxr-tc-approved-as-a-committee-specification/

Statements of Use received:

- IBM (Levine Naidoo): https://lists.oasis-open.org/archives/bdxr/202101/msg00015.html

- ph-xhe (Philip Helger): https://lists.oasis-open.org/archives/bdxr/202101/msg00011.html

- Chasquis (Sander Fieten): https://lists.oasis-open.org/archives/bdxr/202101/msg00010.html

- Efact (Kenneth Bengtsson): https://lists.oasis-open.org/archives/bdxr/202101/msg00009.html

AS4 profile for four-corner networks

Discussions within the BPC revealed the need for a transport layer validation and response when the receiving access point (corner 3) cannot receive a message on behalf of or determine the identity of the final recipient (corner 4). The CEF AS4 profile has defined AS4 properties for carrying information about the final recipient within the ebMS message, which can be used for validation and for rejecting a message in the initial communication with the sending AP (corner 2).

Would it be desirable to create a generic AS4 profile for 4-corner networks, either a committee note or a specification? Agreed at the 20/10 call that the TC wants to work on this. Todd volunteered as lead-editor with co-editing support of Dennis, Sander, Philip and Kenneth.

Agreed at the project meeting November 17, 2020 to write a Committee Specification. Drafting of CS is in process.

Starter template provided here: https://lists.oasis-open.org/archives/bdxr/202012/msg00014.html

Next project meeting will be held January 26.

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.

Federated BDXL

Agreed to add a section about BDXL network federation to BDXL 1.1. Both Peppol and the Business Payment Coalition are working towards federated BDXL designs.

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.

TC conference call schedule

Agreed to hold weekly meetings until further notice.