RE: Action 309 Wording to Resolve Bug 4583

1. Since time is short, let's just accept Asir's rewrite of the first addition:

 

In Section 3.2, append the following sentence to the third paragraph:

 

If policy assertion authors did not specify the semantics of repetition of policy assertions of a type that allows neither parameters nor nested policy expressions within a policy alternative, then repetition is simply redundancy, and multiple assertions of the assertion type within a policy alternative have the same meaning as a single assertion of the type within the policy alternative.

 

2. In section 4.5 we need to say more about the composition of the result of the intersection.  I think this works best as a final bullet:

 

*	The result of policy intersection can be zero or more alternatives.  Each alternative may contain more than one assertion of the same type which may come from different input policies.  See Section 3.2 Policy Alternative <http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-policy-framework.html?content-type=text/html;%20charset=utf-8#rPolicy_Alternative>  for mechanisms for determining the aggregate behavior indicated by multiple assertions of the same policy assertion type <http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-policy-framework.html?content-type=text/html;%20charset=utf-8#policy_assertion_type> .  If policy assertion authors did not specify the semantics of multiple assertions of the same assertion type within a policy alternative and the type and its descendant assertion types (within a nested policy expression outline, if any) do not allow any parameters, then multiple assertions of the type within a policy alternative in the intersection result have the same meaning as a single assertion of the type within the policy alternative.

 

Remove the paragraph following whose contents are incorporated in the above bullet. 

 

 

3. The text following the example needs to discuss the specifics of the example. The current text does not do this.  (Why use > 1 when there are exactly 2 assertions.  And  the symbol > is fine in an equation but has no place in an English sentence).  

 

The big question is the following:  Consider an assertion type that allows optional parameters.  But, in fact, two assertions of that type in an alternative do not have any parameters, neither in the assertions nor in any of the nested policies.  Are these assertions redundant?  There is no problem with comparing such assertions.  I have answered this question in the affirmative that would, thus, would like the paragraph after the example to be changed to the following:

 

Note that there are 2 assertions of the type sp:SignedParts and 2 assertions of the type sp:EncryptedParts, one from each of the input Policies. In general, whether the two assertions in each pair are compatible or redundant depends on the domain-specific semantics of the assertion types. As mentioned above, if the assertions have no parameters and the assertions in nested policies have no parameters, the assertions are redundant.   Thus, the two sp:EncryptedParts assertions are redundant.  Whether the two sp:SignedParts assertions are compatible or redundant depends on the semantics defined for this assertion type.

All the best, Ashok 

________________________________

From: Asir Vedamuthu [mailto:asirveda@microsoft.com] 
Sent: Monday, June 11, 2007 6:20 PM
To: Ashok Malhotra; public-ws-policy@w3.org
Subject: RE: Action 309 Wording to Resolve Bug 4583

 

>The output of the intersection of two policies is one or more compatible alternatives.

 

The output of the intersection of two policies may contain ZERO or MORE policy alternatives.

 

If two policies are compatible, their intersection is the set of the intersections between all pairs of compatible alternatives, choosing one alternative from each policy. If two policies are not compatible, their intersection has no policy alternatives.

 

>Each compatible alternative contains pairs of compatible assertions

 

Well, in the case of ignorable, there may be a single assertion. In the general case, there may be 1 or more assertions of the same type. If the Framework were to say anything about the aggregate behaviors of multiple assertions of the same type then the Framework should address the general case: > 1 or multiple assertions of the same assertion type.

 

>Thus, the two sp:EncryptedParts assertions are redundant.

 

The sp:EncryptedParts assertion example in Section 4.5 carries a parameter: <sp:Body/>. The WS-SecurityPolicy specification specifies the semantics of multiple assertions of the EncryptedParts assertion type [1]. In this case, a default statement in the Framework would not apply.

 

[1] http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-cs.html#_Toc161826515 <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-cs.html#_Toc161826515>  

 

>Add a final bullet to the bullets at the start of section 5.4.

 

There is a paragraph in Section 4.5 that carries the necessary context for specifying any default rule if the assertions authors did not specify the semantics of multiple assertions of the same type:

 

"See Section 3.2 Policy Alternative <http://www.w3.org/TR/2007/CR-ws-policy-20070605/#rPolicy_Alternative>  for mechanisms for determining the aggregate behavior indicated by multiple assertions of the same policy assertion type <http://www.w3.org/TR/2007/CR-ws-policy-20070605/#policy_assertion_type> ."

 

We suggest adding any related clarification to the above paragraph.

 

> If the assertions have no parameters and the assertions in nested policies have no parameters

 

The default statement should be little more tighter and cover nested policy expressions at all levels.

 

>If domain policy assertion language authors fail to specify

 

Our suggestion would be to maintain a positive tone - s/fail to specify/did not specify/.

 

 

Applying these changes:

 

a) Change 1

 

In Section 3.2, append the following sentence to the third paragraph:

 

If policy assertion authors did not specify the semantics of repetition of policy assertions of a type that allows neither parameters nor nested policy expressions within a policy alternative, then repetition is simply redundancy, and multiple assertions of the assertion type within a policy alternative have the same meaning as a single assertion of the type within the policy alternative.

 

b) Change 2

 

In Section 4.5, append the following sentence to the paragraph that starts with 'See Section 3.2 Policy Alternative for mechanisms for determining the aggregate behavior .'

 

If policy assertion authors did not specify the semantics of multiple assertions of the same assertion type within a policy alternative and the type and its descendant assertion types (within a nested policy expression outline, if any) do not allow any parameters, then multiple assertions of the type within a policy alternative in the intersection result have the same meaning as a single assertion of the type within the policy alternative.

 

c) NO changes to the example because the above default rules do not apply to the SignedParts or the EncryptedParts assertion.

 

Regards,

 

Asir S Vedamuthu

Microsoft Corporation

 

 

 

From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Ashok Malhotra
Sent: Saturday, June 09, 2007 8:57 AM
To: public-ws-policy@w3.org
Subject: Action 309 Wording to Resolve Bug 4583

 

1.      Change Section 3.2 of the Framework Document as follows:

Was:

Section 3.2: A policy alternative MAY contain multiple assertions of the same type. Mechanisms for determining the aggregate behavior indicated by the assertions (and their Post-Schema-Validation Infoset (PSVI) (See XML Schema Part 1 [XML Schema Structures]) content, if any) are specific to the assertion type and are outside the scope of this document.

Suggested (based on wording from Dale and Asir): 

Section 3.2: A policy alternative MAY contain multiple assertions of the same type. Mechanisms for determining the aggregate behavior indicated by the assertions (and their Post-Schema-Validation Infoset (PSVI) (See XML Schema Part 1 [XML Schema Structures] content) are specific to the assertion type and are outside the scope of this document. If domain policy assertion language authors fail to specify the semantics of  repetition of policy assertions of a type that allows neither parameters nor nested policy expressions within a policy alternative, then repetition is simply redundancy, and multiple assertions of the assertion type within a policy alternative have the same meaning as a single assertion of the type within the policy alternative."

2.      Add a final bullet to the bullets at the start of section 5.4.

*       The output of the intersection of two policies is one or more compatible alternatives.  Each compatible alternative contains pairs of compatible assertions, one from each of the input policies.  The contents of both assertions in the pair are used to indicate the correct behavior.  Whether the two assertions in the pair are compatible or redundant depends on the domain-specific semantics of the assertion type. If the assertions have no parameters and the assertions in nested policies have no parameters the assertions of that type are redundant.

3.      Change the paragraph that follows the result of the intersection in section 4.5.

Was:

Note that there are > 1 assertions of the type sp:SignedParts; when the behavior associated with sp:SignedParts is invoked, the contents of both assertions are used to indicate the correct behavior. Whether these two assertions are compatible depends on the domain-specific semantics of the sp:SignedParts assertion. To leverage intersection, assertion authors are encouraged to factor assertions such that two assertions of the same assertion type are always (or at least typically) compatible.

Suggested (adds wording specific to the example).:

Note that there are 2 assertions of the type sp:SignedParts and 2 assertions of the type sp:EncryptedParts, one from each of the input Policies. In general, whether the two assertions in each pair are compatible or redundant depends on the domain-specific semantics of the assertion types. As mentioned above, if the assertions have no parameters and the assertions in nested policies have no parameters, the assertions are redundant.   Thus, the two sp:EncryptedParts assertions are redundant.  Whether the two sp:SignedParts assertions are compatible or redundant depends on the semantics defined for this assertion type.

All the best, Ashok