bdxr — archive

[Kenneth Bengtsson]

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