about XOP / MTOM

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: about XOP / MTOM

Some possible approaches with MTOM / XOP, if we go this way:
- there seems to be two levels of compliance to consider: (1) XOP, <http://www.w3.org/TR/2004/CR-xop10-20040826/>
and (2) MTOM <http://www.w3.org/TR/2004/CR-soap12-mtom-20040826/> (a profiling of XOP for SOAP).
- Approach #1: focus on the XOP conformance "on the wire", adopt MIME XOP packaging, and not require the end-point processing (extracting from the original infoset on sender side and reconstructing the infoset on receiver side.) Given that the "XOP includes" would only concern our "payloads", the way we decide to process these at each SOAP node (Sender and Receiver) could be just one more payload service. This means the infoset transformation and reconstitution can be controlled and made optional..

That would give some flexibility for handling payloads that are initially separate, and that we don't want to merge in the SOAP envelope. XOP spec actually acknowledges this usage (and alternatives to base64 are also OK here in MIME parts) .

- Approach #2: MTOM compliance. Not sure if the same level of flexibility we have with XOP is preserved when trying to comply with SOAP MTOM. The "profiling" of XOP that is required here seems more restrictive than XOP, regarding the handling of what we used to call "attachments". The processing model - at any SOAP node - requires the SOAP infoset to be reconstituted before doing SOAP processing (and be exactly same as the initial infoset). However, "Implementations are free to reconstruct only those portions actually needed for processing, or to present information from the message in a form convenient for efficient processing."  A rule that the MSH could observe here as a SOAP node, is then:

-  only the SOAP header would be reconstituted (XOP includes are resolved in header only,  to recreate the infoset).
- The SOAP Body would be left un-reconstituted, and the MIME parts it refers to (XOP includes) would be consumed separately from the SOAP envelope.

So any "attachment" that we want to handle separately from end to end, would be referenced by XOP includes from the SOAP Body. That seems to fit also the intermediary processing (body remains untouched). Those ebMS parts that need to be processed - if any - with the SOAP envelope, would be referenced from the SOAP header (ebMS headers) . That makes the processing of  ebMS headers consistent with that of other external headers that could use MTOM optimization. A consequence of this, however, is that the SOAP body in an ebMS message with "attachments", cannot be used for regular payloads: it will be used as a manifest for the XOP-included MIME parts.

Jacques