Re: NEW ISSUE: Change optional example from MTOM to security (Guidelines and Primer)

Okay, I feel I was wrong on one issue. I believe the consumer can  
decide to change whenever they wish.

But if a consumer doesn't indicate the ability/desire to use MTOM  
then how could the provider send it? The provider is advertising the  
alternatives not the consumer.

Consider a store that advertises that they take US dollars and Euros.  
If I hand in US dollars I expect to receive my change in US dollars  
not Euros.  (Excluding the exceptional case of you having no US  
dollar change)

I just don't think it's fair to force an alternative on a consumer if  
they didn't choose that alternative. Now if there is a away for the  
consumer to specify their capabilities then that's a different issue  
- perhaps an exchange of policies.

Am I missing something?

Perhaps MTOM becomes so popular and wide spread that your scenario is  
exactly right, (i..e. the capability is expected) but in the mean  
time ....

William

On Nov 13, 2006, at 8:21 AM, Frederick Hirsch wrote:

> I'm not convinced those assumptions are correct.
>
> Why couldn't the first message not need an attachment and not bother
> sending a multipart message with only one part, yet the response need
> an attachment and multipart for rational reasons?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> On Nov 9, 2006, at 12:22 PM, ext William Henry wrote:
>
> >
> > Hi Frederick,
> >
> > I think it's pretty obvious that if a requester sends a non-MTOM
> > request it must be assumed that they are using the alternative -
> > presumably whatever binding is specified in the binding. Then all
> > exchanges between requester and provider will be with that
> > alternative. If the requester uses MTOM then it is assumed that
> > exchanges will be with the MTOM alternative.
> >
> > I assume this is the same with security assertions two. Once using
> > an alternative it is assumed that it will be used on all exchanges
> > between that requester and provider.
> >
> > Regards,
> > William
> >
>
>