Re: Action-272: Re: [ISSUE 4393 PRIMER] Add text to strict and lax policy intersection discussion ...

"
A requester can choose how it wants to process a provider's policy to decide if and how the requester will interact with the provider.  A requester can have its own policy that expresses its own capabilities and requirements, and the requester can make one or more attempts at policy intersection in order to determine a compatible alternative and/or isolate the cause of an empty intersection result.  A requester can use the result of policy intersection to select a compatible alternative or trigger alternative processing options. For example, a requester can first try strict mode intersection but then fallback to lax mode intersection as an alternative if the initial intersection attempt returns an empty intersection result.  "



+1. Especially to the last sentence. If client tools/runtimes will follow this advice then it will make ignorable assertions a lot more useful.



Cheers, Sergey

  ----- Original Message ----- 
  From: Daniel Roth 
  To: Charlton Barreto ; public-ws-policy@w3.org 
  Sent: Wednesday, April 11, 2007 2:35 AM
  Subject: RE: Action-272: Re: [ISSUE 4393 PRIMER] Add text to strict and lax policy intersection discussion ...


  Hi Carlton,

   

  We have some questions about the last two paragraphs in this proposal:

   

  > Domain specific processing can be used by a requester to effectively navigate which QoS (service interface) to use through its requirements. 

   

  What does it mean to "navigate which QoS (service interface) to use"?  We think you are saying that a requester gets to decide using whatever processing the requester chooses if any of the policy alternatives supported by a provider are acceptable to the requester, correct?  QoS does really seem like the right term here . . .

   

  > The requestor may need to consistently apply certain assertions in order to use that service, whether these are the requestor's own, or accepted from the provider. 

   

  We agree that a requester may have its own policy about what behaviors it is willing to do.  Is this also saying that the provider may or may not support these behaviors?

   

  > Domain specific processing by a requester can also provide a way to trigger alternate processing options when no alternatives are available from the intersection alone. The requestor could be presented with the result to determine an acceptable alternative. For example, in strict mode intersection, no alternatives may be available as a product of the intersection to the requestor. The requestor can then make additional attempts at intersection in order to isolate the cause and/or determine an acceptable alternative."

   

  We think this is again restating that the requester can be creative about how they process the provider's policy.  We agree that trying strict intersection and then falling back to lax intersection is a fine thing to do.

   

  We think the text could use some rephrasing to make these points clearer.  Below is a suggested rewrite for the last two paragraphs:

   

  A requester can choose how it wants to process a provider's policy to decide if and how the requester will interact with the provider.  A requester can have its own policy that expresses its own capabilities and requirements, and the requester can make one or more attempts at policy intersection in order to determine a compatible alternative and/or isolate the cause of an empty intersection result.  A requester can use the result of policy intersection to select a compatible alternative or trigger alternative processing options. For example, a requester can first try strict mode intersection but then fallback to lax mode intersection as an alternative if the initial intersection attempt returns an empty intersection result.  

   

  Thanks.

   

  Daniel Roth

   

   

  From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Charlton Barreto
  Sent: Tuesday, April 10, 2007 1:43 PM
  To: public-ws-policy@w3.org
  Subject: Action-272: Re: [ISSUE 4393 PRIMER] Add text to strict and lax policy intersection discussion ...

   

  Here is an *updated* proposal based on the feedback we received last week,

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

  Title: Add text to strict and lax policy intersection discussion describing how a policy consumer can determine issues due to intersection mode conflicts

  Target: WS-Policy Primer, Section 3.4.1

  Description: While the Primer covers scenarios on applying intersection modes, we do not have any content which illustrates how conflicts can be detected. As such we need to indicate in the Primer how a consumer may address such conflict detection and reporting.

  Justification: As consumers have the option to choose one or more modes for policy intersection (strict | lax | strict, delegate-to-user | lax, delegate-to-user | strict, lax, delegate-to-user | ...), conflicts may occur when providers intend for their policies to be applied only in a lax mode - this is distinct from treating everything as ignorable. While the end result may be the same (failure, being that no policy alternatives are available), the consumer needs to be able to report why this occurs. 

  Proposal: Perform the following changes to the Primer text 

  Change in 3.4.1 Strict and Lax Policy Intersection, as follows (highlighted in colour below):

   "The previous sections outlined how the normal-form of a policy expression relate to the policy data model and how the compatibility of requester and provider policies may be determined. This section outlines how ignorable assertions may impact the process of determining compatibility. 

  In order to determine compatibility of its policy expression with a provider policy expression, a requester may use either a "lax" or "strict" mode of the intersection algorithm. 

  In the strict intersection mode two policy alternatives are compatible when each assertion in one is compatible with an assertion in the other, and vice versa. For this to be possible they must share the same policy alternative vocabulary. The strict intersection mode is the mode of intersection discussed in the previous sections of this document. 

  When using the strict intersection mode, all assertions are part of the policy alternative vocabulary, including those marked with wsp:Ignorable. Thus, the wsp:Ignorable attribute does not impact the intersection result even when its attribute value is "true".

  If a requester wishes to ignore ignorable assertions in a provider's policy, then the requester should use the lax intersection mode. In the lax intersection mode all ignorable assertions (i.e. with the value "true" for the wsp:Ignorable attribute) are to be ignored by the intersection algorithm. Thus in the lax intersection mode two policy alternatives are compatible when each non-ignorable assertion in one is compatible with an assertion in the other, and vice versa. For this to be possible the two policy alternatives must share a policy alternative vocabulary for all "non-ignorable" assertions. 

  Regardless of chosen policy intersection mode, a policy assertion marked with the wsp:Ignorable attribute does not express any requirement on the behavior of the client, rather, it is used for intersection as indicated in Section 2.7. After intersection, any assertions contained in the resulting policy that are understood by the client are handled as expected. As part of the policy expression, these assertions are not ignored, regardless of whether they are marked with wsp:Ignorable.

  Domain-specific processing could take advantage of any information from the policy data model, such as the ignorable property of a policy assertion. 

  Domain specific processing can be used by a requestor to effectively navigate which QoS (service interface) to use through its requirements. The requestor may need to consistently apply certain assertions in order to use that service, whether these are the requestor's own, or accepted from the provider. 

  Domain specific processing by a requestor can also provide a way to trigger alternate processing options when no alternatives are available from the intersection alone. The requestor could be presented with the result to determine an acceptable alternative. For example, in strict mode intersection, no alternatives may be available as a product of the intersection to the requestor. The requestor can then make additional attempts at intersection in order to isolate the cause and/or determine an acceptable alternative."

  Thanks, 

  -Charlton.