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

Hi

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

I'm not sure it's the case.
In your example I think it's just a matter of putting an wsp:optional MTOM assertion in the scope of the output message element and 
that's it. The client can see it and send a standart HTTP content negotiation header saying that it may accepts MTOM message...

Cheers, Sergey


>
> Glen,
>
> I guess the overhead is the multipart/related outer wrapper?
>
> 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 observe however that this is not an MTOM assertion specific issue,
> applicable in general to Optional assertions, that fall in this criteria.
>
> Regards,
> Prasad
>
> -----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 Friday, 3 November 2006 13:19:22 UTC