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

RE: Action-45

From: Sverdlov, Yakov <Yakov.Sverdlov@ca.com>
Date: Wed, 16 Aug 2006 09:39:56 -0400
Message-ID: <ACE36C31EA815A4CBA7EBECA186C0D41ACA569@USILMS13.ca.com>
To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, <public-ws-policy@w3.org>
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).




Yakov Sverdlov




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
[Minutes] http://www.w3.org/2006/08/02-ws-policy-minutes.html
[3564] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3564


Dr. Umit Yalcinalp 
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
"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

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