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