[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: PEPPOL "BDX Discrepancies" document
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]