W3C home > Mailing lists > Public > public-ws-policy@w3.org > November 2006

RE: NEW ISSUE: Change optional example from MTOM to security (Gui delines and Primer)

From: Prasad Yendluri <prasad.yendluri@webmethods.com>
Date: Mon, 13 Nov 2006 11:18:48 -0800
Message-ID: <A3E375FA108EF94496269A5A96AFCAC1073855BA@mailwest-e0b>
To: Frederick Hirsch <frederick.hirsch@nokia.com>, ext William Henry <william.henry@iona.com>
Cc: public-ws-policy@w3.org


Could the client indicate it wants to receive a MTOM message using the HTTP
Accept: multipart/related;type="application/xop+xml", even though it does
not send a multipart (MTOM/XOP) encoded message?	 


-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Frederick Hirsch
Sent: Monday, November 13, 2006 7:44 AM
To: ext William Henry
Cc: Frederick Hirsch; public-ws-policy@w3.org
Subject: Re: NEW ISSUE: Change optional example from MTOM to security
(Guidelines and Primer)

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

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
Received on Monday, 13 November 2006 19:19:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:18 UTC