RE: ISSUE (3639) Which policy alternative was selected?

Hi Prasad:

> I guess the overhead is the multipart/related outer wrapper?

Yes - arguably not that big a deal, but still significant for small
messages.

> You raise an interesting point however. 
> The initial client request that does not have any attachment 
> content also
> has the same kind of constraint. E.g. An insurance adjuster 
> sends a message
> to retrieve an insurance claim on file. Wants the response to 
> be MTOM/XOP
> encoded but, the request going into the service is a simple 
> message with
> claim number. Here again the client must use MTOM encoding if 
> it wants an
> MTOM encoded response. 

I'd say in this case that the assertion should be written such that it
is *not* marked as optional, but the meaning is "use MTOM if you want".
So by virtue of the non-optionality, the client would know that it MUST
be capable of receiving MTOM messages, but not required to actually send
one.  Considering that MTOM is built on top of the standard HTTP binding
(and therefore everyone that does MTOM/XOP should be able to accept
normal SOAP/HTTP as well), I see no reason to ever *require* MTOM of
someone sending you a message - it's up to them to decide that, and you
can just tell them that you can handle it.

That's the way it SHOULD be - I'm not saying that's necessarily the way
it is. :|

> I observe however that this is not an MTOM assertion specific issue,
> applicable in general to Optional assertions, that fall in 
> this criteria.  

Yes, that's true.

--Glen


> -----Original Message-----
> From: public-ws-policy-request@w3.org
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Glen Daniels
> Sent: Thursday, November 02, 2006 11:08 AM
> To: Daniel Roth; Frederick Hirsch; ext Sergey Beryozkin
> Cc: Yalcinalp, Umit; Sanka Samaranyake; Fabian Ritzmann; 
> Ashok Malhotra;
> public-ws-policy@w3.org
> Subject: RE: ISSUE (3639) Which policy alternative was selected?
> 
> 
> Hi Dan:
> 
> > So, if you send a request using MTOM you MUST also send a 
> > response using MTOM.  If the request sends a message that 
> > does not use MTOM, the provider should respond with a message 
> > that does not use MTOM.
> 
> Perhaps a nit, but this seems a little warped to me - why would you
> force MTOM on a response if you didn't need it?  Example - I 
> send in an
> insurance claim request with a bunch of attached pictures.  
> The response
> message is simply a claim number and maybe some human contact info...
> why waste the bandwidth wrapping that response in MTOM?  Shouldn't it
> say if MTOM is used on the request the response MAY also be MTOM?
> 
> > The provider can tell from the message if MTOM is in use, so 
> > I think it's fine to use wsp:Optional with the MTOM assertion.
> 
> This I 100% agree with.
> 
> --Glen
> 
> > I hope this helps.
> > 
> > Daniel Roth
> > 
> > -----Original Message-----
> > From: public-ws-policy-request@w3.org 
> > [mailto:public-ws-policy-request@w3.org] On Behalf Of 
> Frederick Hirsch
> > Sent: Wednesday, November 01, 2006 5:52 AM
> > To: ext Sergey Beryozkin
> > Cc: Frederick Hirsch; Yalcinalp, Umit; Sanka Samaranyake; 
> > Fabian Ritzmann; Ashok Malhotra; public-ws-policy@w3.org
> > Subject: Re: ISSUE (3639) Which policy alternative was selected?
> > 
> > 
> > Can someone please explain to me what it means to have an optional
> > MTOM assertion on a single endpoint, thus appropriate to 
> all messages?
> > 
> > The MTOM assertion Asir referenced says that the assertion 
> means that
> > all requests and responses MUST use MTOM.
> > 
> > Thus if this assertion is optional on a given endpoint, and the
> > requestor sends a request that does not use (or need) MTOM for that
> > request, how does the provider know whether or not to use 
> MTOM on the
> > response, assuming it would be appropriate when using MTOM?
> > (requestor retrieved provider policy and chose consistent 
> alternative
> > to use, but no explicit agreement with provider exists)
> > 
> > I would think that for a case like this the endpoint should 
> not offer
> > a policy alternative to this assertion. Is this a potential
> > guideline? Is this what Daniel said before?
> > 
> > regards, Frederick
> > 
> > Frederick Hirsch
> > Nokia
> > 
> > 
> > On Oct 31, 2006, at 12:42 PM, ext Sergey Beryozkin wrote:
> > 
> > >
> > > Hi all,
> > >
> > > Can you please clarify a couple of things...
> > > I don't understand why a service provider needs to know which
> > > policy alternative was selected.
> > > I feel what Daniel suggested about attaching policies to different
> > > endpoints should be an adequate approach for most cases, because
> > > this is what endpoints are for in the first place.
> > > If two alternatives can be meaninfully/usefully created in a scope
> > > of a single endpoint then it's fine (security related
> > > alternatives, etc), this is also probably useful when nested
> > > polices are used.
> > >
> > > I've read the proposal for optional assertions and the suggestion
> > > to mark with wsp:optional something a provider will not always do
> > > and to enable optional behaviours out-of-band, perhaps by 
> letting a
> > > provider know which policy alternative was selected.
> > > I'm confused. For example :
> > >
> > > <custom:MTOM wsp:optional/>
> > >
> > > it says custom:foo is something a provider won't always do and it
> > > will do only if it's told somehow by a requester to do it.
> > >
> > > So here we go :
> > >
> > > <Policy>
> > >   <ExactlyOnce>
> > >   <!-- Alt1 -->
> > >   <All>
> > >     <custom:bar/>
> > >   </All>
> > >   <!-- Alt2 -->
> > >   <All>
> > >     <custom:MTOM/>
> > >     <custom:bar/>
> > >   </All>
> > >   </ExactlyOnce>
> > > </Policy>
> > >
> > > By selecting the second alternative and by the virtue of sending
> > > MTOM-serialized messages the requester is saying to a 
> provider that
> > > it needs to load its <custom:MTOM/> handler. I don't see a reason
> > > for some more out-of-band indication that alternative2 
> was selected.
> > >
> > > In what cases one would want to explicitly tell the provider which
> > > alternative was selected ?
> > >
> > > Thanks, Sergey
> > >
> > >
> > >
> > >
> > >
> > > I agree. We should definitely acknowledge that this is a problem
> > > even if
> > > we may choose not to tackle it in an interoperable way in this
> > > version.
> > >
> > > Please see that the proposal for optional assertions that I sent a
> > > while
> > > back also contains some language for out of band mechanisms in
> > > order to
> > > make messages self describing (which includes the option of an
> > > additional protocol).
> > >
> > > --umit
> > >
> > >
> > >> -----Original Message-----
> > >> From: public-ws-policy-request@w3.org
> > >> [mailto:public-ws-policy-request@w3.org] On Behalf Of Sanka
> > >> Samaranyake
> > >> Sent: Tuesday, Oct 10, 2006 12:55 PM
> > >> To: Fabian Ritzmann
> > >> Cc: Ashok Malhotra; public-ws-policy@w3.org
> > >> Subject: Re: ISSUE (3639) Which policy alternative was selected?
> > >>
> > >>
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >>
> > >> Fabian Ritzmann wrote:
> > >> >
> > >> > Ashok Malhotra wrote:
> > >> >> My original motivation in raising this issue was to provide a
> > >> >> rationale for why we
> > >> >> wanted a pointer from the message to the policy 
> > (alternative) that
> > >> >> was applied to it.  (There are
> > >> >> other reasons why such a pointer may be useful, for 
> > example if the
> > >> >> policy changes
> > >> >> during the course of a long-running transaction, or 
> to indicate
> > >> >> policies or assertions which do not affect the wire format of
> > >> >> messages - bug 3789.)
> > >> >>
> > >> >> At the f2f in Bellevue the WG said:
> > >> >> 1. You can add such a pointer to a msg using the SOAP
> > >> extensibility
> > >> >> mechanism but
> > >> >> 2. The WG did not want to standardize such a header 
> as it raised
> > >> >> all manner of questions such "shd this
> > >> >> be the first header."
> > >> >>
> > >> >> Subsequently, Dan Roth told the WG
> > >> >>
> > >> http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/
> > >> 0043.html
> > >> >> that Microsoft products used the following solutions:
> > >> >> 1. In case multiple alternatives apply, create an 
> endpoint that
> > >> >> supports exactly one policy alternative.
> > >> >> 2. Use an out-of-band mechanism to convey which 
> alternative was
> > >> >> selected.  In effect, this uses an out-of-band
> > >> >> mechanism instead of the pointer in the message that I wanted.
> > >> >>
> > >> >> So, at this point I am willing to agree to close the 
> > issue with no
> > >> >> action.
> > >> >> If others feel differently please propose the solution you
> > >> would like.
> > >> >>
> > >> >
> > >> > Regarding the suggested solutions:
> > >> >
> > >> > 1. Web services are meant to be interoperable. I don't 
> think that
> > >> > any product-specific solution can satisfy that requirement.
> > >> >
> > >> > 2. Irrespectively of whether an in-band or out-of-band 
> > mechanism is
> > >> > chosen, it would be beneficial to have standardized solutions.
> > >> >
> > >> > Having said that, I believe that designing a solution 
> would take
> > >> > more time and effort than would be good for our 
> > schedule. I'd like
> > >> > to see this issue deferred to V.next.
> > >> >
> > >> > Fabian
> > >> >
> > >>
> > >> I believe as policies are get used in more and more real life
> > >> scenarios, it is likely that we might end up with policy 
> > alternatives
> > >> that are not distinguish able just looking at the message 
> > itself. And
> > >> I feel that, irrespectively of whether it is in-band or 
> > out-of-band,
> > >> there should be way to indicate to the server, which 
> > alternative the
> > >> client has picked. I am ok if with differing this  to the next
> > >> version
> > >> as far as  it  is remains noted.
> > >>
> > >> Sanka
> > >>
> > >> - --
> > >> Sanka Samaranayake
> > >> WSO2 Inc.
> > >> T:+94-77-3506382 F:+94-11-2424304
> > >>
> > >> http://sankas.blogspot.com/
> > >> http://www.wso2.net/
> > >> -----BEGIN PGP SIGNATURE-----
> > >> Version: GnuPG v1.4.2.1 (GNU/Linux)
> > >>
> > >> iD8DBQFFK/qJ/Hd0ETKdgNIRAmtvAJ9A//SEe+02heUIpqj6ba35k0ypzgCdE6M5
> > >> GiWeAJJim2cGpqHoqPe3U7A=
> > >> =VrOI
> > >> -----END PGP SIGNATURE-----
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > 
> > 
> > 
> > 
>

Received on Thursday, 2 November 2006 21:39:34 UTC