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: Agenda for Atlantic BDXR TC call 10 March 2021 16:00UTC


Agenda for Atlantic BDXR TC call 10 March 2021 16:00UTC

http://www.timeanddate.com/worldclock/fixedtime.html?iso=2021-03-10T16:00:00

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

 

Conferencing info

 

Meeting ID: 547 975 473

Passcode: oasis

 

Join from PC, Mac, Linux, iOS or Android:

https://us02web.zoom.us/j/547975473?pwd=bjVvdDhDcEZXZ3R3cldRYkpuQU13Zz09

 

Or iPhone one-tap (US toll):

+13462487799,,547975473#,,,,,,0#,,130346# US (Houston)

+16465588656,,547975473#,,,,,,0#,,130346# US (New York)

 

Or international dial-in number (toll):

https://us02web.zoom.us/u/kchtpYJm7L

Meeting ID: 547 975 473

Passcode: 130346

 

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/202103/msg00008.html

 

Review of Atlantic call minutes

https://lists.oasis-open.org/archives/bdxr/202103/msg00006.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

-   Ger Clancy

-   Sander Fieten

-   Philip Helger

-   David Hixon

-   Ken Holman

-   Levine Naidoo

-   Dennis Weddig

 

Members gaining voting status after this meeting:

-  Pim van der Eijk

 

Members losing voting status after this meeting:

-   David Hixon

 

Webinar

 

Discussed to organize open meetings with the participation of users of our specifications to showcase the work done by the TC and the work in progress. Could for example be quarterly meetings. Agreed to schedule a first meeting mid-April if feasible. There may be interest both in Australia, Europe and the U.S. Would be good to find a time that’s convenient for all.

 

Possible agenda items:

-  Overview of the Four-corner Model

o Todd + Kenneth

-  XHE

o Ken + Kenneth

-  SMP 2.0

o Erlend

-  AS4 Profile for Four-corner Networks

o Sander

 

Format: One hour total time. 10 minutes per subject + 5 minutes for questions.

Agreed to make two webinars, one for Europe and North America and one for Australia:

Pacific: April 14/15 at 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney

Atlantic: April 15 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

 

Exchange Header Envelope (XHE)

 

Public review of XHE 1.0 COS has been announced and will end April 11: https://www.oasis-open.org/2021/02/10/invitation-to-comment-on-exchange-header-envelope-xhe-version-1-0-ends-11-april/

 

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.

 

The project has completed the first internal review of PMode parameters. Working draft uploaded here: https://www.oasis-open.org/committees/document.php?document_id=68261&wg_abbrev=bdxr

 

Todd will merge the uploaded document with his version with the introductory text. Kenneth will draft a conformance clause.

 

The specification draft will be finalized in the committee. The project group will no longer be meeting.

 

Reviewed feedback received from Pim (based on the initial WD01): https://lists.oasis-open.org/archives/bdxr/202102/msg00025.html. Discussed whether the title can (mis)lead readers to believe that they MUST use this specification when implementing a four-corner network. Clarified that this is an interoperability profile. Shall we support additional signature algorithms and hash functions? Philip will make a proposal for additional algorithms (signature, hash and encryption).

 

Overview of the four-corner model Committee Note

 

During work with BDXL 1.1, Sander and Kenneth identified that elements of the text (describing the four-corner model, its components and its actors) would perhaps be better suited for a broader Committee Note. An early (incomplete) draft has been uploaded here, for discussion in the TC:

 

https://www.oasis-open.org/committees/document.php?document_id=68197&wg_abbrev=bdxr

 

The TC continues to review the committee note draft.

 

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.

 

Face-to-face meeting

Should we schedule online work sessions to replace the face-to-face meeting?

 

Call schedule

 

Agreed to move the Pacific call to one hour later from April 6 when Australia goes back to standard time.

 

2021-03-09/2021-03-10

-  Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney

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

2021-03-16/2021-03-17

-  Pacific: 17:00MSP/23:00Europe/18:00Ottawa/22:00UTC/09:00Sydney

-  Atlantic: 11:00MSP/12:00Ottawa/16:00UTC/17:00Europe

2021-03-23/2021-03-24

-  Pacific: 17:00MSP/23:00Europe/18:00Ottawa/22:00UTC/09:00Sydney

-  Atlantic: 11:00MSP/12:00Ottawa/16:00UTC/17:00Europe

2021-03-30/2021-03-31

-  Pacific: 17:00MSP/00:00Europe/18:00Ottawa/22:00UTC/09:00Sydney

-  Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

2021-04-06/2021-04-07

-  Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney

-  Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

2021-04-13/2021-04-14

-  Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney

-  Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

2021-04-20/2021-04-21

-  Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney

-  Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

2021-04-27/2021-04-28

-  Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney

-  Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

2021-05-04/2021-05-05

-  Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney

-  Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

2021-05-11/2021-05-12

-  Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney

-  Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

2021-05-18/2021-05-19

-  Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney

-  Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

2021-05-25/2021-05-26

-  Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney

-  Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/16:00Europe

 

Other business

 

As comes forward

 



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