- From: Sverdlov, Yakov <Yakov.Sverdlov@ca.com>
- Date: Wed, 16 Aug 2006 09:39:56 -0400
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, <public-ws-policy@w3.org>
- Message-ID: <ACE36C31EA815A4CBA7EBECA186C0D41ACA569@USILMS13.ca.com>
Hi Umit, Just to provide some justification on my personal preference for the option C. I agree with you that the option A does not necessarily lead into negotiation. At the same time, it is not clear to me which additional binding specific mechanisms (such as specific SOAP headers), suggested in the option A, may be considered here without extending the scope of the specification into transport, messaging, etc In your particular example, the REST scenario comes up again i.e. SOAP HTTP GET usage. Naturally, a requester (sender) would not be able to use SOAP header(s). Regards, Yakov Sverdlov CA ________________________________ From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit Sent: Tuesday, August 15, 2006 5:52 PM To: public-ws-policy@w3.org Subject: Action-45 This completes my action item [Action45] for reviewing/correction the minutes mentioned in [Minutes] with respect to discussion on [3564]. I believe that a lot of other points are missing from the records, but I am hoping that it would be captured in the discussion/email. The minutes should read: Glen: We need at least something like Umit's option C ... Optiona A seems to venture into negotiation space Umit: I definitely think option C is a must, however I do not believe a solution suggested in A to this problem ventures into negotiation. Let me explain. Negotiation means a lot of different things to different people, from a third party communicating sets of policies of two separate parties on behalf of those parties to exchange of policies between the parties. In this case, what I intended for A is a "selection mechanism" not a negotiation mechanism on behalf of a requestor. The sender is not exchanging its policies with the receiver, the receiver knows that there are alternates due to optional assertions but needs to choose one. My suggestion is to define a header to "select" an alternative that disambiguates the presence of an optional assertion when needed (analogous to mustUnderstand) After all, an optional assertion yields two alternatives, one with and one without the assertion after normalization on the receiver. Nadalin: Umits description seems to mix alternatives and optionality Umit: An optional assertion results in two alternatives as a result of normalization. The question is which one to select. ... the rest should be retained. I am sure there may be other points that were missed, but I can not speak for others as I was doing the presentation of the issue. [Action45] http://www.w3.org/2005/06/tracker/wspolicy/actions/45 <http://www.w3.org/2005/06/tracker/wspolicy/actions/45> [Minutes] http://www.w3.org/2006/08/02-ws-policy-minutes.html <http://www.w3.org/2006/08/02-ws-policy-minutes.html> [3564] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3564 <http://www.w3.org/Bugs/Public/show_bug.cgi?id=3564> ---------------------- Dr. Umit Yalcinalp Architect NetWeaver Industry Standards SAP Labs, LLC Email: umit.yalcinalp@sap.com Tel: (650) 320-3095 SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238 <https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238> -------- "First they ignore you, then they ridicule you, then they fight you, then you win." Gandhi
Received on Wednesday, 16 August 2006 13:40:12 UTC