Dear all
I was forwarded a link to a document on PEPPOL s website with a list of discrepancies between cipa component implementation and the PEPPOL specifications , which says that there are some known issues with
BDXR TC work products that they (PEPPOL) have asked us to fix.
First I thought it was an old and outdated document, but the date says that it is from April 2017 (so almost a year after the final SMP 1.0 committee specification was published).
The document can be found here:
https://peppol.eu/wp-content/uploads/2017/04/ITC-Transport-BDX-Discrepancies-100.pdf And it is referenced from their website here:
https://peppol.eu/downloads/the-peppol-edelivery-network-specifications/ (at the bottom, under Other support documents ).
My observations:
1) The SML specification imposes the use of soap 1.1 but defines the soap faults using the soap 1.2
specification. The CIPA SML component uses
soap 1.1 fault definitions.
Status: Change request for the Oasis busdox TC to update spec
But PEPPOL s SML is their own proprietary specification. The OASIS BDXL doesn t use SOAP..
2) In order for the SMP rest response to be valid (the Extension element is causing issues),
processContents="skip" should be added to the ExtensionType in the ServiceMetadataPublishingTypes
1.0.xsd?
Status: Change request for the Oasis busdox TC to update spec
The OASIS SMP (1.0) specification has processContents= lax , which shouldn t cause any problems when validating an extension. I am not aware that we have any requests for changing lax to skip ..?
The PEPPOL SMP still doesn t use our schema. Their schema has processContents= strict (I happened to recently run into this a week ago), which yes, poses certain complications when including extensions. That
could be easily fixed by using our schema instead.
3) In the current SMP implementation, the response for the get of the SignedServiceMetadata is not valid
since the time is not included in the ServiceActivationDate and ServiceExpirationDate.
Status: Change request for the Oasis busdox TC to update spec
But the types of ServiceActivationDate and ServiceExpirationDate in the SMP 1.0 SignedServiceMetadata schema are both xs:dateTime.. I thought they were the ones asking us to change to xsd:date (which we did
for SMP 2.0), so this is really confusing. And regardless, why would any of them invalid the response of an SMP GET request?
4) The SMP specification indicates that the canonicalization algorithm should be set to
http://www.w3.org/2001/10/xml exc c14n#, while in the current implementation it is set to
http://www.w3.org/TR/2001/REC xml c14n 20010315
Decision : Currently canonicalization Inclusive is used, but the specs state Exclusive . Inclusive is more secure as the results are unlikely to be inserted into another document.
Status: Change request for the Oasis busdox TC to update spec
The SMP 1.0 says that the canonicalization algorithm
MUST be
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 (so opposite of what it says in the PEPPOL document), and SMP 2.0 uses
http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/ .
Anyone knows about this document, or with whom we should clarify with?
/Kenneth