Re: Some MTOM precisions

Comments inlined.

-Anish
--

youenn fablet wrote:
> 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?
> 

I was thinking of more than XOP. XOP does not define any serialization. 
In particular I was thinking of having an extension for MTOM section 3 
-- which specifies how the MIME serialization of optimized SOAP messages 
is done without pulling in HTTP.
We could then say that enabling MTOM section 3 in the context of http 
binding also enables MTOM section 4 (or define 2 extensions, whatever 
makes sense).

It would be nice to have an extension that can be reused across 
protocols and not be limited to HTTP.


>> 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.

In the write up I did see the stmt:
"This is an empty global element that allows any namespaced attribute, 
especially the wsdl:required attribute."

But in the infoset description I did not see anything like:

"Zero or more namespace qualified attribute information items ..."

> 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 ?
> 

I was thinking of just modifying the stmt to say:
... e.g., as a policy assertion in a policy framework or a WSDL 1.1 
extension).

But if it can be done as a non-normative text describing how/where to 
put this extension element in WSDL 1.1 document that would be good too.

-Anish
--

>> 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 Friday, 20 October 2006 01:29:23 UTC