Re: Some MTOM precisions

Anish Karmarkar wrote:
>
> Youenn,
>
> Few comments on the proposal:
>
> 1) Section 2 says:
> ---
> This extension allows describing the capacities and requirements of a 
> service related to the use of MTOM. This specification defines the 
> semantics of this extension when used in conjunction with:
>
>    1. WSDL2.0 SOAP Binding, as defined in [WSDL 2.0 Adjuncts]
>    2. HTTP being set as SOAP transport protocol
> ---
>
> When I first read this I interpreted the above to mean that this 
> extension is used only when WSDL 2.0 soap bidning *AND* HTTP is used.
>
> After reading the rest of the proposal it was clear that this 
> extension can be used for non-HTTP transports.
>
> I would suggest removing the 2nd bullet.
I tried not to preclude this use case.
I tried only to say that when used with SOAP over another protocol (SMTP 
for instance), this extension is not defined.
Are you suggesting we should generalize the specification ?
One way to accommodate this would be to talk about enabling the XOP 
functionality in lieu of the MTOM one.
Then we could add a sentence, telling that enabling XOP in the context 
of SOAP over HTTP is equivalent to enabling MTOM.
Do you think this makes sense?

> 2) Table 2-1, 2nd row, 2nd column says:
> ---
> MTOM MUST be supported and SHOULD be engaged by the client. Typically, 
> MTOM MAY be disengaged when NO binary data is to be sent.
> ---
>
> There are two cases when the client may not want to engage MTOM:
> a) there is no binary data to be sent (for example, the binary part 
> has minOccurs="0").
> b) the binary data that is to be sent is so small that the MTOM 
> optimization results in a larger message ('cause of all the MIME 
> overheads). I.e., base64 encoding is more efficient than MIME 
> packaging with raw binary MIME part
>
> I would suggest modifying the above stmt as follows:
> MTOM MUST be supported and SHOULD be engaged by the client. Typically, 
> MTOM MAY be disengaged when NO binary data is to be sent OR when the 
> binary data to be sent is too small to benefit from MTOM optimization.
I thought of this use case, but was not sure that people could agree on 
what is small/big enough to use MTOM.
Hence my phrasing with SHOULD (and not MUST engage except for...).
But it may be better to advertise this case, so I am ok with both phrasing.
>
> 3) I'm curious as to why the wso:OptimizedMimeSerialization element is 
> not extensible via attributes and elements.
It is already extensible by attributes.
There is no particular reason to forbid element extensibility, except 
maybe to ease its implementation.
AFAIK, wsa:UsingAddressing is not extensible by elements.

>
> 4) Section 3.1 says:
> ---
> The wso:OptimizedMimeSerialization element MAY be used in other 
> contexts than WSDL2.0 (e.g., as a policy assertion in a policy 
> framework).
> ---
>
> Can this extension also be used in WSDL 1.1?
Are you suggesting to add non normative text describing how and where to 
put this extension element in WSDL1.1 documents ?

> Thanks.
>
> -Anish
> -- 
>
>
> Youenn Fablet wrote:
>> To put forward the proposal, here is the proposal reformated as a 
>> "specification-like" web page.
>> I hope this file will help speed up discussions on this proposal.
>> I do not know yet whether I will be able to join the call tomorrow.
>> Regards,
>>    Youenn

Received on Thursday, 19 October 2006 09:17:00 UTC