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.