binding Digikoppeling 2.0

Ik heb samen met Tom Peelen een eerste verkenning gedaan van wat er moet gebeuren voor deze Binding.

Digikoppeling 2.0 voegt toe signing & encryptie alsmede attachments. De eerste lijkt vooralsnog voor een StUF binding niet relevant aangezien er binnengemeentelijk niets met signing en encryptie lijkt te gebeuren. Dit is puur voor transport en heeft geen weerslag op de payload (stuf) die getransporteerd wordt.

Attachments zijn echter wel interessant. In de huidige bindingen (3.01)wordt voor de SOAP binding XOP/MTOM voorschreven. Digikoppeling 2.0 ondersteund voor WUS ook XOP/MTOM en voor ebMS worden meerdere containers met MIME multiparts ondersteund. Er van uitgaande dat de al bestaande StUF SOAP binding leidend is bij het maken van een binding voor Digikoppeling lijken mogelijke problemen zich te concentreren op mime content-types:

ebMS 2.0
Bij Digikoppeling ebMS 2.0 is het gebruik van content-type verplicht. Volgens de stuf soap binding is het slechts optioneel behalve voor stuf vraag berichten, daarbij is contenttype helemaal niet toegestaan. Dit lijkt voor een ebMS 2.0 binding geen hindernis te vormen zolang bij deze binding content type verplicht wordt gesteld en StUF vraag berichten niet over ebMS gaan. Dit laatste ligt volgens mij in de lijn der verwachting aangezien ebMS bedoeld is voor meldingen en mutaties, niet voor bevragen. Voor meldingen en mutaties kan het stuf attachment dus in een losse container als MIME part met zijn eigen content-type worden meegegeven in een ebMS bericht.

WUS 2.0
WUS 2.0 maakt net als de StUF SOAP binding gebruik van XOP/MTOM. Echter alle voorbeeld berichten uit de koppelvlakstandaard gebruiken daarbij een MIME content-type.
Volgens onze interpretatie van de XOP/MTOM standaard is het gebruik van MIME content-type niet optioneel (zoals wel in de 301 binding wordt gesuggereerd). Bij het doorlezen van de XOP/MTOM standaard ontstaat bij ons het beeld dat content-type inclusief de uitbreding met internet media types verplicht zijn(zie "Assigning Media Types to Binary Data in XML" uit de XOP standaard). Dit kan mogelijk een conflict opleveren met de bestaande StUF SOAP binding. Als in een StUF bericht volgens de SOAP binding een attachment zonder content-type wordt verstuurd kan dit maar moeilijk omgezet worden in een StUF bericht over WUS met content type. Bij stuf vraag berichten zou dit met name een probleem kunnen worden.

We zijn benieuwd naar de feedback van de StUF community op ons voorwerk to dusver. Met name waar het gaat om de interpretatie van de XOP/MTOM standaard aangaande MIME content-type

Vriendelijke groeten,
Frank Terpstra

Hallo Frank,

Onderstaand mijn reactie op jouw opmerkingen.

1) In een vraagbericht zal het element nooit binaire inhoud bevatten en dus ook nooit aanleiding geven tot een extra MIME-part. De huidige specificatie leidt daar dus niet tot problemen.

2) Onderstaande tekst is letterlijk overgenomen uit http://www.w3.org/TR/xop10/

3.1 Creating XOP Packages

To create a XOP Package from an Original XML Infoset:

1. Ensure that the Original XML Infoset contains no element information item with a [namespace name] of "http://www.w3.org/2004/08/xop/include" and a [local name] of Include. As discussed in 2 XOP Infoset Constructs, XML Infosets with such element information items cannot be represented using XOP.
2. Create an empty package.
3. Identify within the Original XML Infoset the element information items to be optimized. To be optimized, the characters comprising the [children] of the element information item MUST be in the canonical form of xs:base64Binary (see [XML Schema Part 2: Datatypes Second Edition]3.2.16 base64Binary) and MUST NOT contain any whitespace characters, preceding, inline with or following the non-whitespace content.
4. Create a XOP Infoset which is a copy of the Original XML Infoset, but with the [children] of each element information item identified in the previous step replaced by a xop:Include element information item (see 2.1 xop:Include element information item) constructed as follows:
   - Transform the replaced characters into binary data by processing them as base64-encoded data.
   - Serialize the binary data into a new part of the package, with appropriate metadata corresponding to the [normalized value] of the href attribute information item of the xop:Include element information item (see 2.2 href attribute information item).
   - If the element information item being optimized (i.e., the [parent] of the newly inserted xop:Include element information item) has a xmlmime:contentType attribute information item, its value SHOULD be reflected appropriately in the metadata for the part.
5. Serialize the resulting XOP Infoset into the package using any W3C recommendation-level version of XML (e.g., [Extensible Markup Language (XML) 1.0 (Third Edition)], [Extensible Markup Language (XML) 1.1]) and identify it as the root part according to the packaging mechanism's convention, labeling it with the application/xop+xml media type, as described in 5 Identifying XOP Documents.

Additional parts MAY be added to the package to satisfy application specific requirements. Other content-specific metadata MAY be reflected in the packaging metadata as appropriate.

If content cannot be successfully encoded into the XOP package, implementations SHOULD behave as if that portion of the Original XML Infoset was not nominated for optimization."

Punt 3 onder punt 4 stelt niet dat het mimetype verplicht is. Het stelt wel dat als het aanwezig is, dan moet het ook worden opgenomen als contenttype van het corresponderende MIME-part. De beschrijving van de MTOM binding in StUF is daarmee niet in strijd met de MTOM/XOP standaarden.

Zolang Digikoppeling geen additionele voorschriften geeft, voldoet de StUF MTOM binding.

Met vriendelijke groet,

Maarten

Hallo Tom,

StUF schrijft het gebruik van MTOM bij het in een StUF-bericht opnemen van binaire inhoud. Dit impliceert dat de bytes voor de bijlage uit de XML worden gehaald en als separate MIME-parts in het bericht worden opgenomen.

De standaard schrijft daarbij voor dat op verschillende niveaus contentType al dan niet gevuld  moet worden.

Zie (gekopieerd uit http://www.w3.org/TR/soap12-mtom/)

3.2 Serialization of a SOAP message

When sending a SOAP message using the MIME Multipart/Related Serialization, the SOAP envelope Infoset is serialized as specified in [XML-binary Optimized Packaging] 3.1 Creating XOP packages. Specifically:

• The content-type of the outer package MUST be multipart/related.
• The type parameter of the content-type header of the outer package MUST have a value of "application/xop+xml" (see [XML-binary Optimized Packaging], 4.1 MIME Multipart/Related XOP Packages).
• The startinfo parameter of the content-type header of the outer package MUST specify a content-type for the root part of "application/soap+xml".
• The content-type of the root part MUST be application/xop+xml (see [XML-binary Optimized Packaging], 4.1 MIME Multipart/Related XOP Packages).
• The type parameter of the content-type header of the root part MUST specify a content-type of "application/soap+xml".

The result is a MIME Multipart/Related XOP package (see [XML-binary Optimized Packaging]): one body part, the root, containing an XML representation of the modified SOAP envelope, with an additional part used to contain the binary representation of each element that was optimized.

Het door StUF gedefinieerd contentType wordt met bovenstaande contentTypes niet bedoeld, maar zit er weer ergens binnen. In mijn vorige post heb ik aangegeven dat dat niet verplicht is en daarom blijf ik bij mijn mening dat de StUF protocolbinding niet in strijd is met de MTOM/XOP spec.

Met vriendelijke groet,

Maarten

Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0117.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Aangezien digikoppeling 2.0 al in de protocolbindingen 3.02  is doorgevoerd is tijdens de StUF Expertgroep van 21 september besloten dat dit RFC mag worden afgevoerd.