- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Thu, 19 Oct 2006 18:27:24 -0700
- To: youenn fablet <youenn.fablet@crf.canon.fr>
- CC: Jonathan Marsh <jonathan@wso2.com>, www-ws-desc@w3.org, "'Jean-Jacques Moreau'" <jean-jacques.moreau@crf.canon.fr>
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