[V.Next] 4179 Preferences for policy expressions

We would like to get this issue logged for V.Next.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4179


        Title

Preferences for policy expressions


        Description

For V.Next, WS-Policy should consider how to handle preferences. Earlier 
attempts to apply preferences to WS-Policy was using an absolute scale 
where there was no guarantee that two policy providers were using the 
same scale. Therefore preferences must be relative to one policy 
document. For V.Next, WS-Policy should either supply 1) a mechanism to 
indicate relative preferences or 2) a standard preference XML attribute 
for policy assertions. Priority is a synonym for preference in the 
context of this document.


        Justification

Preferences can be used by policy providers to indicate to policy 
consumers which policy assertions are preferred. This is particularly 
relevant in scenarios where a policy consumer chooses policies 
automatically without human interaction. For example, three encryption 
algorithms may be supported, but one is extremely slow but uses minimal 
memory and is available for use by memory-constrained clients. This 
example also shows that policy consumers may have their own set of 
preferences that can override the preferences of the policy provider.


        Target

WS-Policy Framework V.Next


        Proposal

Several approaches may be considered:

   1. Stating document order in a Policy indicates preferences would be
      sufficient. Determine if the WG would need to resolve any
      contradiction to the current rule that no policy elements are
      ordered.
   2. Policy alternatives could be associated with identifiers. A policy
      metadata syntax could list identifiers in preference order.
   3. An XML attribute that contains relative preference numbers to
      include in assertion elements. The preference or priority would
      apply only to the immediate level [1]
      <http://wikihome.sfbay.sun.com/wts/Wiki.jsp?page=PolicySpecIssuePreferences#ref-PolicySpecIssuePreferences-1>.
      XPath may be used to examine or select portions of a WS-Policy
      instance for analysis, transformation or other uses. To contain
      this, options at the same level without explicit preference
      indications could be assumed to be equivalent [2]
      <http://wikihome.sfbay.sun.com/wts/Wiki.jsp?page=PolicySpecIssuePreferences#ref-PolicySpecIssuePreferences-2>.
      This would enable non-normalized policies where preferences may
      not be attached consistently [3]
      <http://wikihome.sfbay.sun.com/wts/Wiki.jsp?page=PolicySpecIssuePreferences#ref-PolicySpecIssuePreferences-3>.

   4. Domains could provide a proprietary means of expressing
      preferences. This has already been detected in the security arena,
      e.g. <AlgorithmSpeed>slow</AlgorithmSpeed> could be included under
      the same <All> operator as the slow encryption algorithm. However,
      as this should be a mechanism that cuts across domains, this is
      not an optimal or interoperable approach.

In order to effectively handle intersections and merge, this proposal 
could be extended to include concrete algorithms. Nested policies must 
be considered. A standard algorithm for a policy consumer is required to 
compute the most preferred policy alternative.

[#1]

<All Preference="6">
 <ExactlyOne>
     <All Preference="3">
        <Assertion1 />
      </All>
     <All Preference="2">
        <Assertion2 />
     </All>
</ExactlyOne>
</All>
<All Preference="1">
 <Assertion3 />
</All>

Which would be normalized into three alternatives (sorted according to 
preference):

<All>
 <Assertion3 />
</All>
<All>
 <Assertion2 />
</All>
<All>
 <Assertion1 />
</All>

would have the following preference order:

    * Assertion3
    * Assertion2
    * Assertion1

[#2] The WG may specify a default, possibly with a Policy attribute to 
override, to indicate whether options without explicit preference 
indications are considered and at what preference. Note, this is similar 
to any recommendation that may be made to WS-Addressing. See draft: 
http://lists.w3.org/Archives/Member/member-ws-policy/2006Oct/0002.html.

[#3] More than one attribute may be needed or the capability to acquire 
the value of this attribute. We recognize this may need more discussion.



-- 
Fabian Ritzmann
Sun Microsystems, Inc.
Stella Business Park             Phone +358-9-525 562 96
Lars Sonckin kaari 12            Fax   +358-9-525 562 52
02600 Espoo                      Email Fabian.Ritzmann@Sun.COM
Finland