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