RE: What is the Vocabulary of an Intersected Policy

Monica,

For a while, I thought the situation might be even trickier because of
these open-world assumptions.  I'm just thinking this through a bit, but
I had thought it might be that there are two priorities of vocabularies,
the service and the client.  Any vocabulary types in the service would
need to be in the vocabulary of the effective policy, because the
service has clearly made a decision about including them or not.  But a
client vocabulary type (not known by the service) perhaps shouldn't be
in the effective policy because the service has made no decision for or
agin the particular type.  

I then tried to think of both ignorable and non-ignorable, and it seems
to me there's actually no need to exclude client vocabulary types.
Imagine the client knows about doing ws-addressing but the service
doesn't.  The service has not said it will or will not do ws-a, but
having it in the effective vocabulary (or not) doesn't change the
effective policy which would say no ws-a.  However, imagine the client
knows about the hypothetical EndOfLife assertion and service doesn't.
Again, the effective policy will say no EOL and the vocabulary type
would have EOL, and effective policy is still true.  

At this point, I don't see a need to differentiate between client and
service vocabulary types for purposes of the effective policy
vocabulary.  Anybody have any other thoughts on this?

Cheers,
Dave

> -----Original Message-----
> From: Monica.Martin@Sun.COM [mailto:Monica.Martin@Sun.COM] 
> Sent: Thursday, April 19, 2007 9:47 AM
> To: Ashok Malhotra
> Cc: David Orchard; Sergey Beryozkin; ws policy
> Subject: Re: What is the Vocabulary of an Intersected Policy
> 
> 
> I agree with the point that David is making. There are two 
> aspects of this discussion, and Ashok's original question 
> that should be
> differentiated:
> 
>    1. Vocabulary of the effective policy: Is this the 
> vocabulary scoped
>       to the effective policy or the union of the vocabularies that
>       input into the effective policy?
>    2. Application of the effective policy: It may be prudent 
> to separate
>       this sentence from what the constraint is.
> 
>         "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."
> 
> This indicates the assertion will not be applied not that 
> there is an explicit constraint or restriction to doing so 
> (i.e. this Framework text is descriptive in nature rather 
> than RFC language that dictates required functionality). This 
> is not an opinion of what it could/should indicate or dictate 
> to an implementation, or the value of considering or 
> including in future work a NOT operator. What it does 
> evidence is we should be explicit about our intent. When we 
> discussed this at length before (when this text was changed) 
> and even earlier (remember WS-TX discussions on 
> wsp:Optional), this conflict of text and its intent existed. 
> Now we revisit it again with more impact seen for other 
> domains, including WS-Addressing.  
>   
> 
> Thanks.
> 
> >orchard: ...The fact that C wasn't selected is a different 
> fact than C isn't in the vocabulary.
> >sergey2: ...I don't understand why having C&D in the 
> vocabulary of the effective policy will help to avoid applying them. 
> >...	 
> >sergey: My understanding is that A&B is the vocabulary of 
> the final effective policy, the fact that this policy was 
> computed through the intersection is not important		 
> >
> >		"BUT, Chris points out the vocabulary should be 
> {A,B,C,D} to remember 
> >the fact that this was the union of the vocabularies of the two 
> >intersected policies and that {C. D} must not be
> >applied since they were not selected."		 
> >
> >		I don't understand. Why would the consumer need 
> to keep C&D in the 
> >vocabulary of the effective(calculated through the
> >intersection) policy if they can't be appplied ?
> >  
> >
> malholtra: ...Subject: What is the Vocabulary of an 
> Intersected Policy We spoke briefly about this on the call 
> today and I see a problem. This note is an attempt to state 
> the problem clearly.
> 
> Consider two normalized policies
> <Policy>
>     <ExactlyOne>
>         <All>
>               <A/>
>                <B/>
>         </All>
>          <All>\
>                 <C/>
>          </All>
>       </ExactlyOne>
> </Policy>
> 
> <Policy>
>     <ExactlyOne>
>         <All>
>               <A/>
>                <B/>
>         </All>
>          <All>\
>                 <D/>
>          </All>
>       </ExactlyOne>
> </Policy>
> 
> Let us intersect these two policies.  What we get is:
> 
> <Policy>
>     <ExactlyOne>
>         <All>
>               <A/>
>                <B/>
>         </All>
>     </ExactlyOne>
> </Policy>
> 
> Now, what is the vocabulary of this policy?  Looking at this 
> policy alone it should be { A, B}.
> BUT, Chris points out the vocabulary should be {A,B,C,D} to 
> remember the fact that this was the union of the vocabularies 
> of the two intersected policies and that {C. D} must not be 
> applied since they were not selected.
> 
> This seems like a contradiction.   To remember the negative 
> decision we need to include assertions that are not in the 
> policy, in its vocabulary.
> 
> SOLUTIONS:
> The only viable solution that I can see is to drop the 
> 'negation' semantic, namely, "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."   (Dale was arguing 
> for this on other grounds as well)  Some would object 
> strongly to this.  A counter proposal would be to add an 
> explicit NOT operator.
> 
> Unfortunately, these are radical suggestions but I do not see 
> any other way out.   
> All the best, Ashok
> 
> 
> 
>

Received on Thursday, 19 April 2007 17:59:36 UTC