policy vocabulary, will not be applied, oh my!

There are some related issues/questions/concerns that have been expressed 
by members
of the WG with regards the framework specification as it relates to the 
"will not be applied" principle 
and the definions for "policy vocabulary", etc. Below, I have enumerated 
these issues
and suggest a path forward to address those concerns.

1. The definition of "policy vocabulary" is incompatible with intersected 
policy as regards to 
the "will not be applied" principle because post intersection, the 
resultant policy expression
does not carry the policy vocabulary of the input policy expressions. 
Hence, if a provider
had two alternatives, one with Foo and one without Foo, and the result of 
intersection determined
that the alternative without Foo was compatible with a client's policy, 
then the resultant
policy expression would not have in its vocabulary (as computed using the 
currently specified) Foo and hence it would not be clear whether Foo 
carries with it
the "will not be applied" semantic.

Action-283 - 
Action-284 - 
Ashok email - 

2. There is a degree of confusion regarding the "will not be applied" 
semantic as it applies to nested policy.
This is related to the interpretation of "policy vocabulary" that many 
held prior to the clarification provided by

Asir's email on nested policy vocabulary - 

3. As a result, a number of email threads have sprung up that question the 
merits of the "will not be applied"

Ashok - 
Dale - 
Ashok - 
Dale - 

It may be that the most prudent course forward would be to drop the "will 
not be applied" semantic as relates
policy vocabulary. As a result, there is little need of a normative 
definion for policy vocabulary or policy alternative
vocabulary, as these definitions only served to allow one to determine 
whether the behavior implied by a
given assertion carried the "will not be applied" semantic.

Instead, we could simply state that the behavior implied by an assertion 
that is absent from a given alternative
is not to be applied in the context of the attached policy subject when 
that alternative is engaged.
This would provide clearer semantic (I believe) to borth assertion and 
policy authors.

The attached mark-up of the policy framework specification contains the 
changes that I believe would 
be necessary to affect this change.

Impact analysis:

- The proposed change does not affect the XML syntax
- Nor does it impact the semantics of the namespace, therefore the 
namesapce URI can remain unchanged
- It does not affect the processing model (normalization, intersection)
- It does not impact testing results to date
- It does not affect any of the assertion languages developed to date

The related questsion that needs to be asked should we choose to adopt 
this proposal is:

        Does this change affect any implementations?

>From analysis of the set of test cases, the answer is not clear, because 
there were no tests that
excercised either policy vocabulary or the "will not be applied" semantic. 
Thus, it would be important that
we check our respective implementations to ascertain whether there would 
be any impact. From an IBM
perspective, this change does not impact our implementation.


Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

Received on Tuesday, 1 May 2007 20:23:12 UTC