Re: [V.Next] 4179 Preferences for policy expressions


So, you are basically stating up-front that the WG could close this with 
no action today and
simply add the keyword so that it is taken into consideration with 
the others we have closed in this


Christopher Ferris
STSM, Software Group Standards Strategy
phone: +1 508 377 9295

Fabian Ritzmann <Fabian.Ritzmann@Sun.COM> 
Sent by:
01/10/2007 06:13 AM

"" <>

[V.Next] 4179 Preferences for policy expressions

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

Preferences for policy expressions 
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 
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. 
WS-Policy Framework V.Next 
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]. 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]. This would 
enable non-normalized policies where preferences may not be attached 
consistently [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. 
<All Preference="6">
     <All Preference="3">
        <Assertion1 />
     <All Preference="2">
        <Assertion2 />
<All Preference="1">
 <Assertion3 />

Which would be normalized into three alternatives (sorted according to 
 <Assertion3 />
 <Assertion2 />
 <Assertion1 />

would have the following preference order: 
[#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: 
[#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

Received on Wednesday, 10 January 2007 14:44:37 UTC