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: Minutes of BDXR TC meeting March 2, 2016



Jens Aabol
Kenneth Bengtsson (chair)
Erlend Klakegg Bergheim
Sander Fieten
Sven Rasmussen


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.


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).


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.


There was no other business.


March 16 2016, regular conference call
March 30 2016, regular conference call
April 13 2016, regular conference call

Kenneth Bengtsson

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