Re: Policy alternatives, negation, [Non]AnonResponse assertion and the none URI


So you are saying (I'm rephrasing to get clarity) that:
"... does not apply .." => one MUST NOT do whatever the missing 
assertion asked one to do.
If so, the spec needs to be clarified to make it clear. This was not 
clear to a lot of folks on WS-Addressing.

Additionally, does this negation effect apply to only top-level 
assertions or nested assertions as well. IOW, are nested assertions part 
of the vocabulary.

One not obvious (not to me) side-effect of this 'negation' is the following:

Consider the scenario where two very complicated polices are created by 
the IT department. Let's call them P1 and P2. I'm required to use P1 or 
P2 on services that are exposed outside the firewall. P1 contains an 
assertion A that is absent in P2. If I advertise P1 only then I have to 
do whatever A asks me to do. If I advertise P2 only, I may or may not 
use A (as it is not part of the vocabulary) -- it is up to me. If I 
advertise a policy that says either of P1 or P2 and P2 is selected, I 
cannot use A. This is very surprising (at least to me). This does not 
follow the 'principle of least surprise'. "OR"ing operation in other 
contexts does not introduce negation based on vocabulary set. I'm 
curious as to the rationale for this. In any case, guidance and 
clarification in the spec or the primer would be very useful.


Ashok Malhotra wrote:
> If you have a Policy that says Assertion A and B then you have to do A and B.  Since it says nothing about C, you may or may not do C.  
> However, if A,B and C are all in the Policy Vocabulary (the assertions contained in the Policy) and you select an alternative from the Policy that contains only A and B, you may not do C.  Thus, it is a form of negation.
> All the best, Ashok
>> -----Original Message-----
>> From: Anish Karmarkar []
>> Sent: Monday, April 16, 2007 2:41 PM
>> To: Ashok Malhotra
>> Cc:; ws policy
>> Subject: Re: Policy alternatives, negation, [Non]AnonResponse assertion
>> and the none URI
>> Ashok,
>> We discussed this at the ws-addr call today and are waiting to get
>> clarification from ws-policy WG on the phrase "... assertion will not be
>> applied ...," as to its meaning. It is not clear, to at least some
>> (many?) member of ws-addr wg, what it means.
>> We decided to postpone a resolution on this (and related issue) till we
>> get some direction/resolution from ws-policy wg.
>> -Anish
>> --
>> Ashok Malhotra wrote:
>>> Here is the relevant text from the Policy Framework document:
>>> [Definition: A policy vocabulary is the set of all policy assertion
>> types used in a policy.] ... When an assertion whose type is part of the
>> policy's vocabulary is not included in a policy alternative, the policy
>> alternative without the assertion type indicates that the assertion will
>> not be applied in the context of the attached policy subject.
>>> All the best, Ashok
>>>> -----Original Message-----
>>>> From: [mailto:public-ws-addressing-
>>>>] On Behalf Of Anish Karmarkar
>>>> Sent: Monday, April 16, 2007 9:56 AM
>>>> To:
>>>> Subject: Policy alternatives, negation, [Non]AnonResponse assertion and
>>>> the none URI
>>>> There is view among the WS-Policy wonks (not sure how widely accepted
>>>> this is or whether the WS-Policy specs explicitly calls this out) that
>>>> when there are alternatives present and the selected alternative does
>>>> not contain an assertion X but another alternative does, then the
>> effect
>>>>   of such a selection consists of negation of X.
>>>> We have two assertions AnonResponse and NonAnonResponse assertions.
>> Both
>>>> of them require that the 'none' URI be allowed for the response EPR.
>>>> Does that mean that negation of any of these implies 'none' must not be
>>>> used?
>>>> If so, that is a problem, none is useful for things like one-way
>>>> operations that don't use the response EPR for that MEP.
>>>> Additionally, if one has two alternatives one with AnonResponse only
>> and
>>>> one with NonAnonResponse only, then that would be self-contradictory.
>>>> -Anish
>>>> --

Received on Monday, 23 April 2007 19:15:25 UTC