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: 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]