Why would you send a large binary field of a SOAP 1.2 message with MTOM/XOP instead of inline base64, and what does it preserve?
answer
- base64 costs a third more
- a MIME package with a root part
- an include element pointing at cid:
- the Infoset stays as if inline
basics
~20 sInline base64 inflates binary by about a third and is parsed as text. MTOM/XOP moves canonical base64Binary element content into raw MIME parts referenced by xop:Include, while the Infoset, and so its signatures, stays as if inline.
solid answer
~50 sInline base64 turns every 3 bytes into 4 characters and forces the receiver to scan and decode them as XML text. **XOP** (XML-binary Optimized Packaging) packs the document into MIME Multipart/Related: selected `xs:base64Binary` element content is decoded into its own raw part, and the element's content is replaced by an `xop:Include` whose `href` is a `cid:` URI naming that part. **MTOM** is the SOAP 1.2 feature that applies XOP to SOAP messages and defines its HTTP serialization, with `Content-Type: multipart/related; type="application/xop+xml"`. Only element content in the canonical base64 form, with no whitespace, may be optimized, because the receiver must be able to reconstruct exactly the original characters. The message's Infoset is unchanged, so anything computed over it, such as a signature over the base64 form, still verifies; that is the difference from older SOAP with Attachments, where the attachment sits outside the envelope.
go deeper
Recall that base64 makes binary about a third larger and that MTOM sends binary as raw MIME parts referenced from the SOAP message.
Explain how XOP builds the package, what xop:Include and the cid: URI do, and why only canonical base64Binary element content qualifies.
Show why optimization keeps the Infoset intact for signatures and intermediaries, and judge when MIME packaging is worth its cost.
Decide how large documents should cross a SOAP integration: inline, MTOM, or a reference to separate storage, weighing security processing and partner capability.
## The cost of inline binary XML has no binary type on the wire. A schema declares binary content as `xs:base64Binary`, and the sender writes it as base64 text: every 3 bytes become 4 characters, roughly a third more data before any compression. The receiver's XML parser then has to scan those characters like any other text and decode them. For a scanned contract, an image or a signed PDF of several megabytes, both costs land on the hottest path of the service. ## XOP: packaging that keeps the document whole **XOP** (XML-binary Optimized Packaging, a W3C Recommendation) defines a **XOP package**: the XML document serialized inside an extensible packaging format, in practice **MIME Multipart/Related**. The construction: 1. Choose element content that is base64-encoded binary in its **canonical lexical form**. 2. Decode it and place the raw bytes in a separate MIME part with its own `Content-ID`. 3. Replace the element's content in the XML with an `xop:Include` element whose `href` is a `cid:` URI naming that part. The root part holds the XML with the `xop:Include` placeholders; the other parts hold raw bytes. A reader that needs the XML as written puts the base64 characters back. XOP is deliberately limited: "Only element content can be optimized; attributes, non-base64-compatible character data, and data not in the canonical representation of the base64Binary datatype cannot be successfully optimized." The canonical-form rule is what guarantees a one-to-one correspondence between the package and the original Infoset. ## MTOM: XOP applied to SOAP **MTOM** (SOAP Message Transmission Optimization Mechanism) is a W3C Recommendation for SOAP 1.2 in three pieces: - an **Abstract SOAP Transmission Optimization Feature**, saying a binding may optimize canonical `xs:base64Binary` element content while presenting the full Infoset to the application; - an **Optimized MIME Multipart/Related serialization** of a SOAP message built on XOP; - an **HTTP SOAP Transmission Optimization Feature**, which changes the SOAP 1.2 HTTP binding so the request's `Content-Type` is `multipart/related` and the body is the XOP package. The sending rule is strict: to be optimized, the characters MUST be in canonical `xs:base64Binary` form and MUST NOT contain whitespace, and implementations MUST NOT substitute canonical for non-canonical forms. How a sender picks which elements to optimize is implementation-dependent, for example a schema annotation or the API that built the value. ```http POST /claims HTTP/1.1 Host: api.example.com Content-Type: multipart/related; boundary=MIME_boundary; type="application/xop+xml"; start="<[email protected]>"; start-info="application/soap+xml" --MIME_boundary Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" Content-ID: <[email protected]> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <c:SubmitClaim xmlns:c="http://example.com/claims"> <c:scan><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:[email protected]"/></c:scan> </c:SubmitClaim> </env:Body> </env:Envelope> --MIME_boundary Content-Type: application/pdf Content-ID: <[email protected]> ...raw bytes... --MIME_boundary-- ``` ## What MTOM preserves, and why it matters | Property | Inline base64 | MTOM/XOP | SOAP with Attachments | |---|---|---|---| | Wire size of binary | about 4/3 | raw bytes | raw bytes | | Binary inside the SOAP Infoset | yes | yes, logically | no, referenced from outside | | Schema sees an `xs:base64Binary` element | yes | yes | no | | Message-level processing over the content | works | works on the reconstructed form | needs separate handling | XOP says the binary "can be thought of as being base64-encoded in the XML Document", because that conceptual form may be needed "e.g., for signing". A signature or a schema check computed over the Infoset therefore gives the same result whether the message travelled inline or packaged. The older **SOAP Messages with Attachments** Note also used Multipart/Related, but its attachments are parts referenced from the envelope rather than content of it, so anything that processes the envelope has to treat them separately. ## When it is worth it - Large binary fields, or many of them, where the third extra size and text decoding are measurable. - Paths where intermediaries or security processing need the envelope intact. It is not free: both sides must support the feature, MIME packaging adds framing, and small values gain little. For a few kilobytes, inline base64 is often simpler. ## Reading an MTOM message correctly 1. The HTTP `Content-Type` is `multipart/related`; its `type` parameter is `application/xop+xml` and `start-info` names the SOAP media type, so the receiver knows the root is a SOAP 1.2 envelope. 2. The root part is the envelope with `xop:Include` placeholders; it is not a complete message on its own. 3. Each placeholder's `cid:` URI matches the `Content-ID` of exactly one later part. 4. Application code, schema validation and security processing all see the reconstructed Infoset, never the placeholders. A frequent mistake is logging or validating only the root part and concluding the binary field is empty.
- Can a sender optimize a base64 attribute value or a base64 string that contains line breaks?No. XOP optimizes only element content, and MTOM requires the characters to be canonical xs:base64Binary with no whitespace. Attributes and non-canonical content stay inline, because the receiver must reconstruct exactly the characters that were sent.
- How does MTOM change the SOAP 1.2 HTTP request?The HTTP SOAP Transmission Optimization Feature sets `Content-Type` to `multipart/related`, with a `type` of `application/xop+xml` and `start-info` naming `application/soap+xml`. The root MIME part carries the envelope with `xop:Include` placeholders, and the following parts carry the raw bytes.
A long letter that says 'see enclosure 2' at the point where a photograph belongs. The photo travels in the same envelope as its own item, yet anyone reading the letter treats it as part of the text; a sealed and signed letter stays valid because the enclosure is accounted for exactly.
saying these in an interview costs you the question
- MTOM takes the binary out of the SOAP message, so signatures no longer cover it.
- Any element or attribute whose type is binary can be optimized by MTOM.
- MTOM is just another name for SOAP with Attachments.
- Base64 inline costs nothing measurable, so MTOM only matters for streaming.
- The MTOM specification fixes a size threshold above which content must be optimized.