W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

RE: Features: required implementation and use (was Re: Describing which blobs are to be optimized.)

From: <paul.downey@bt.com>
Date: Tue, 8 Jun 2004 14:12:32 +0100
Message-ID: <2B7789AAED12954AAD214AEAC13ACCEF0FFF22D1@i2km02-ukbr.domain1.systemhost.net>
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.

Received on Tuesday, 8 June 2004 09:25:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:48 UTC