- From: <paul.downey@bt.com>
- Date: Tue, 8 Jun 2004 14:12:32 +0100
- To: <mgudgin@microsoft.com>, <hugo@w3.org>, <gdaniels@sonicsoftware.com>
- Cc: <Marc.Hadley@Sun.COM>, <jmarsh@microsoft.com>, <www-ws-desc@w3.org>, <xml-dist-app@w3.org>
Gudge wrote: >> 1) that setting the MTOM feature for a message indicates that a >> sender may optionally send soap+xml or a mime package, but the >> receiver mustUnderstand MTOM messages regardless of the state >> within an MEP. If a receiver is unable to process MTOM messages >> then it should use another endpoint, binding or interface. > > I'm not sure I understand the above. If the WSDL description of > an endpoint says that the endpoint supports MTOM, then that endpoint > had better be able to consume and/or emit MTOM messages ( depending > on whether you can state MTOM support at the binding, operation or > input/output level ). There has been some discussion about 'servers' only sending MTOM if a previous 'request' used MTOM and the like. I find it useful to focus on the sender and receiver of an individual message regardless of what may happened previously within the MEP. Like Hugo, i believe this kind of interaction belongs in the domain of 'constraints and capabilities'. So i think you've better phrased what i was trying to say, expect i concentrated on receiving a message. Because the MTOM feature is optional, a one-way MEP could be still used by a non MTOM sender, but if an endpoint (message, operation, binding, etc) is marked as supporting MTOM, then it must be able to process the MTOM messages it is likely to receive. If an implementation can't handle MTOM messages then it could fault or use another compatible endpoint, binding, whatever, that doesn't have the MTOM feature enabled. Paul
Received on Tuesday, 8 June 2004 09:25:41 UTC