bdxr — archive

[Philip Helger]

Hi guys, OpenPeppol is currently looking into the OASIS SMP 2.0 specification in detail and stumbled upon an issue, where we would need your input. We were studying the data model of the SMP Endpoint information and stumbled upon a difference we cannot completely assess. In the Peppol SMP specification (latest version: https://docs.peppol.eu/edelivery/smp/PEPPOL-EDN-Service-Metadata-Publishing-1.2.0-2021-02-24.pdf ) and the BDXR SMP 1.0 version an SMP endpoint is uniquely identified via the quadruple of: a) Service Group ID b) Document Type ID c) Process ID and d) Transport Profile In comparison to that, the data model of SMP 2.0 looks slightly different and uses a unique key consisting of a triple: a) Service Group ID b) Document Type ID c) Transport Profile From our perspective we are loosing an element of customizability (Process ID) and wanted to ask if: a) Is our understanding on that topic correct? b) Have you foreseen a way to mimic the Peppol SMP endpoint structure? c) If you answered b) with no , do you plan to support the Peppol SMP endpoint structure in future version? d) If you answered c) with no , do you see a chance if a respective request comes in, to change back to the old structure? Thanks and BR, Philip