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

Paul,

Sounds like we're both on the same page.

Cheers

Gudge 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: 08 June 2004 14:13
> To: Martin Gudgin; [email protected]; [email protected]
> Cc: [email protected]; Jonathan Marsh; [email protected]; 
> [email protected]
> Subject: RE: Features: required implementation and use (was 
> Re: Describing which blobs are to be optimized.)
> 
> 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
>