Re: [bdxr] Minutes of BDXR TC meeting March 2, 2016

[Kenneth Bengtsson <kbengtsson@efact.pe>]

Dear all

Today we had a meeting with representatives of DIGST and the eHealth community of e-SENS regarding the change requests received as comments to SMP 1.0 CS 2.0. Participants were:

Jens Aabol

Kenneth Bengtsson

Erlend Klakegg Bergheim

Joao Cunha

Adrien Férial

Sander Fieten

Masi Massimiliano

Sven Rasmussen

Hugo Soares

We briefly went through the TC's resolutions of change requests CR002, CR003, CR004, CR006 and CR008 (as documented in the meeting minutes below), before going in to details with change requests CR001, CR005 and CR007:

CR001: Add an additional "status" metadata

It was clarified that the additional "status" element would be used exclusively to exchange connectivity information, and tentatives values would be "in accordance", "expired", "suspended", "revoked", "not in accordance". It was discussed that there are alternative methods to accomplish the same functionality as described in the change request. We concluded that the present BDXR TC members had received sufficient information to be able to resolve the change request at our next TC meeting.

CR005: Change end record names from "Document" to "Resource"

It was clarified that a descriptive text in the SMP specification would be sufficient documenting that a "Document" element can also be used for a "Resource". It was proposed that the BDXR TC drafts such a text to be added to the specification and shares with eHealth for their comment. To be resolved at our next TC meeting.

CR007: Multiple signatures

We had a long conversation to clarify the underlying requirement of the change request. It was contemplated if the requirement is of a character specific to eHealth so that a "workaround" (for example using extensions) could be proposed from BDXR, or if the requested change has a broad enough scope so as to justify a change to the SMP specification. One proposed solution was to suggest a solution using the extension elements and to document this in an official document from the BDXR TC. We concluded that the present BDXR TC members had received sufficient information to be able to resolve the change request at our next TC meeting.

Any other business

The BDXR TC will publish an official comment resolution log documenting the change requests and the actions taken. The timeframe for implementing changes is approximately early April, after which the BDXR TC has to decide if material changes have been made. If no material changes (as defined by the OASIS TC Process: https://www.oasis-open.org/policies-guidelines/tc-process#definitions) have been made, the TC can request that OASIS set up a ballot for the approval of a new Committee Specification (approximately one week), and after approval the new Committee Specification will be published by OASIS (typically 4-5 weeks).

Best regards,

Kenneth

From: <bdxr@lists.oasis-open.org> on behalf of Kenneth Bengtsson <kbengtsson@efact.pe>
Date: Thursday, March 3, 2016 at 9:07 AM
To: "bdxr@lists.oasis-open.org" <bdxr@lists.oasis-open.org>
Subject: [bdxr] Minutes of BDXR TC meeting March 2, 2016

MEETING MINUTES OF BDXR TC MEETING 2 MARCH 2016

ATTENDANCE

Jens Aabol

Kenneth Bengtsson (chair)

Erlend Klakegg Bergheim

Sander Fieten

Sven Rasmussen

SMP 1.0 COMMENTS RECEIVED

Prior to the meeting, the TC received comments and change requests to SMP 1.0 CS 2.0 from the European Commission Directorate-General for Informatics (DIGIT), available here: https://lists.oasis-open.org/archives/bdxr-comment/201602/msg00002.html

The present TC members were able to go through and discuss all received change requests, however it was determined that a few of the items require further information and debate, why it was agreed to write back to DIGIT and request a conference call.

Change requests were resolved as follows:

CR001: Add an additional "status" metadata

There were opinions both for and against including a status element in EndpointType, and it was discussed that if a status element is introduced, its possible values it should be bound to a fixed list in the specification. It was agreed to request more specific information from DIGIT, including a list of the intended possible values.

CR002: Make field RequireBusinessLevelSignature optional

DIGIT requested that the RequireBusinessLevelSignature element become optional. It was agreed to accommodate the request and include the change in the upcoming SMP 1.0 CS 04. The change does not impact existing SMP implementations.

CR003: Validation of the "Extension" element

DIGIT requested to add a "processContents" attribute with the value "lax" to the ExtensionType to ensure that an SMP response containing extensions can be validated against the XSD.

It was agreed to accommodate the request for the functionality, and there was a strong leaning towards the technical solution proposed by DIGST. Notwithstanding, the TC would like to evaluate other technical solutions to achieve the same result before settling on a final implementation. The change will be included in the upcoming SMP 1.0 CS 04, and will not impact existing SMP implementations.

CR004: ServiceActivationDate and ServiceExpirationDate of SignedServiceMetadata should not include Time

It was discussed that this request has its roots in the original PEPPOL sample implementation of SMP, where these elements were implemented as type xs:date and not xs:dateTime. It was agreed that a change from the current xs:dateTime to xs:date would limit a functionality of SMP, which has potential use and value. The TC therefore agreed to not accommodate the change request, and instead propose that the implementation(s) in question are updated to conform with the SMP specification.

CR005: Change end record names from "Document" to "Resource"

DIGIT requested that all references to “Document” in the specification be changed to “Resource”, as this better reflect the use of SMP in the eHealth domain. DIGIT also suggested that an explanation that “documents” can also be understood as “resources” be included in the document as an alternative solution.

It was discussed that changing the specification to use “Resource” as terminology instead of “Document” is a major change, why there was predominant inclination towards the simpler alternative solution. It was concluded that the TC does not have enough information available to fully understand and analyze the request, why it should be make a topic for the proposed meeting with DIGIT.

CR006: Usage of extensions

DIGIT requested a clarifying change to the SMP 1.0 CS 02 section on using extensions. The TC agreed with the meaning of the proposed change, and assessed that the redrafted section in SMP 1.0 CS 03 already includes the request.

CR007: Multiple signatures

DIGIT requested that the specification allows for an additional signature, to be signed with the certificate of a participant (corners 1 and 4 of the 4-corner model).

The TC debated the impact on such change on the 4-corner model, and whether it would be incompatible. It was agreed to propose to discuss this more in detail at a meeting with DIGIT.

CR008: Multiple extensions

DIGIT requested that an SMP response should be able to contain multiple extensions, and suggested to make the Extension element unbounded.

The TC agreed with the change request that an SMP response should be able to contain multiple (unbounded) extensions, however the preference of the TC would be to make the xs:any inside the Extension element unbounded (instead of the Extension element itself). This approach would provide the same functionality as requested by DIGIT. It was agreed to include the change in the upcoming SMP 1.0 CS 04. The change does not impact existing SMP implementations.

BDE 1.1 STATUS

Kenneth had received an informal question from the Australian Taxation Office regarding the overhead of base64 encoding when sending large binary attachments. Difi recently made a study into this issue, concluding that base64 increases file size with around 40%, but found no widely implemented alternative or better approach to limit XML file augmentation. Methods to mitigate the negative footprint in the network are to use transport protocols that support compression and/or to compress the XML file using .zip file compression (such as the ETSI ASiC container).

UPDATE ON BDXL AND SMP STATEMENTS OF USE

Work on a new Committee Specification Draft for SMP 1.0 is commencing why no need for Statements of Use until a new Committee Specification has been published.

ANY OTHER BUSINESS

There was no other business.

MEETING SCHEDULE

March 16 2016, regular conference call

March 30 2016, regular conference call

April 13 2016, regular conference call

Kenneth Bengtsson