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

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

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 10 Oct 2006 23:14:16 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D64165025C2E58@uspale20.pal.sap.corp>
To: "Sanka Samaranyake" <sanka@wso2.com>, "Fabian Ritzmann" <Fabian.Ritzmann@Sun.COM>
Cc: "Ashok Malhotra" <ashok.malhotra@oracle.com>, <public-ws-policy@w3.org>

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 Wednesday, 11 October 2006 06:16:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:42 GMT