Re: Proposal for linking MTOM section 4 to SOAP 1.2 HTTP binding

Marc,

I agree with the general direction of your proposal.

I think that 4.3.2 should be modified similarly to reflect changes on 
the receiver side by specifying the modifications done to section 
7.5.2.2 of SOAP 1.2 part 2 (if we agree on your proposal, I think that 
doing the same for 4.3.2 is mostly editorial work).

Best regards,

Hervé.


Marc Hadley wrote:

> I took an action to propose a way to link section 4 in MTOM[1] to the 
> existing SOAP 1.2 part 2 HTTP binding. I propose a replacement for one 
> subsection to demonstrate the direction/approach I think we should 
> adopt. If the WG likes this approach it could be extended to the rest of 
> the section.
> 
> The existing section 4.3.1:
> 
> "4.3.1 Sending a SOAP message
> 
> When sending a SOAP message for which the Abstract Transmission 
> Optimization Feature is enabled, the HTTP Transmission Optimization 
> Feature optimizes the transmission of the message by serializing it 
> using the MIFFY format (ref?). Unless otherwise stated, serializing a 
> SOAP message infoset into the HTTP body MUST be semantically equivalent 
> to performing the following steps separately, and in the order given.
> 
>   1. Serialize the SOAP Message into a MIME Multipart/Related packaging 
> as described in the MIFFY format (ref?).
>   2. Serialize the MIME Multipart/Related packaging into the HTTP body."
> 
> Suggested replacement:
> 
> "4.3.1 Sending a SOAP message
> 
> This section describes the pertubations to the SOAP 1.2 HTTP binding 
> (see [xxx]), section 7.5.1 Behaviour of Requesting SOAP Node, that 
> result from use of the MTOM feature. Only those aspects described below 
> differ from the existing operation of the HTTP binding, all other 
> aspects of its operation remain unchanged.
> 
> 4.3.1.1 Init
> 
> This section describes changes to SOAP 1.2 Part 2, section 7.5.1.1 Init. 
> When using the MTOM feature, the application/soap+xml serialization of a 
> SOAP message is replaced by a MIFFY package[xx].
> 
> Table xx: HTTP Request Fields
> 
> +--------------+-----------------------------------+
> | Field        | Value                             |
> +--------------+-----------------------------------+
> | Content-Type | mime/multipart-related            |
> | header field |                                   |
> +--------------+-----------------------------------+
> | HTTP entity  | SOAP message serialized according |
> | body         | to rules in MIFFY[xx]             |
> +--------------+-----------------------------------+
> 
> The MIFFY package is constructed according to the MIFFY 
> specification[xx] with the following restrictions:
> 
>   1. The package MUST use the mime/multipart-related serailization as 
> described in section xxx of MIFFY[xx].
>   2. Each optimization MUST generate exactly one extracted binary part 
> in the resulting package. I.e. extracted binary parts MUST NOT be 
> referenced with more than one miffy:Include in the SOAP message part.
> 
> Note: This does not preclude the MIFFY package from including additional 
> parts not referenced with a miffy:Include. Such additional parts are not 
> part of the SOAP message infoset are not included in the SOAP processing 
> model."
> 
> 
> Marc.
> 
> [1] http://www.w3.org/mid/[email protected]
> 
> -- 
> Marc Hadley <[email protected]>
> Web Technologies and Standards, Sun Microsystems.