New combining algorithms profile and a potential issue in 3.0 core spec

All,

I have uploaded a new working draft of the combining algorithms profile.

I have generalized the on-permit-apply-second algorithm so it can take
a third child which is applied in case the first child ("the condition")
returns N/A or Deny. This is the if-then-else feature which we discussed
earlier on the list.

I also made some other changes to the algorithm. It used to be "clever" in
case of different flavors of Indeterminate. But I realized that doing so
is dangerous and undesirable for this algorithm, so I simplified
the error handling. Let me explain why.

The purpose of this algorithm is to allow using conditions in policies.
For instance, someone could write a policy like this:

PolicySet Y [on-permit-apply-second]
  Policy A, Rule, Condition: the subject has an account in corporate LDAP
  PolicySet X
    ... policies which apply to these subjects ...

Now, when the PolicySet X is authored, it is likely to be done with the
assumption that the user has an ldap account, since this is what is
tested for in the condition. The author would assume that the policy set X
is not evaluated if the condition is false.

However, in WD 03 of the profile, if Policy A (with the condition) returns
an Indeterminate{P} or Indeterminate{DP}, the policy set X is evaluated
anyway to determine the flawor of Indeterminate which should be
returned as a whole for policy set Y.

But since the policy A was indeterminate, we don't really know whether
the condition is true or not, so we might in fact be in a situation