Re: New issue on duplicate assertions of a single type in an alternative: 4583

+1

Felix

Dale Moberg wrote:
>
> I like Asir’s wording for this proposed addition.
>
> ------------------------------------------------------------------------
>
> *From:* Asir Vedamuthu [mailto:asirveda@microsoft.com]
> *Sent:* Tuesday, June 05, 2007 7:36 PM
> *To:* Dale Moberg; Ashok Malhotra; Paul Cotton
> *Cc:* public-ws-policy@w3.org
> *Subject:* RE: RE: New issue on duplicate assertions of a single type 
> in an alternative: 4583
>
> It appears that Dale’s proposed text addresses the simple case – an 
> assertion type that neither allows parameters nor allows a nested 
> policy expression. If the WG were to adopt the proposal we would 
> suggest rephrasing the sentence using terminology defined in the 
> Framework draft:
>
> “If authors did not specify the semantics of multiple assertions of 
> the same assertion type that neither allows parameters nor allows a 
> nested policy expression within a policy alternative, then multiple 
> assertions of the assertion type within the policy alternative have 
> the same meaning as a single assertion of the type within the policy 
> alternative.”
>
> Regards,
>
> Asir S Vedamuthu
>
> Microsoft Corporation
>
> *From:* public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Dale Moberg
> *Sent:* Thursday, May 31, 2007 3:38 PM
> *To:* Ashok Malhotra; Paul Cotton
> *Cc:* public-ws-policy@w3.org
> *Subject:* RE: New issue on duplicate assertions of a single type in 
> an alternative: 4583
>
> A modest proposal that does not impact the current policy intersection 
> procedure (I hope)
>
> 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:
>
> 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. If domain policy assertion language authors fail to 
> specify what repetition of a policy assertion type (without parameters 
> or subpolicies!) within a policy alternative means, then repetition is 
> simply redundancy, and multiple assertions of a policy type have the 
> same meaning as a single assertion of the type within the policy 
> alternative.
>
> An advantage is that the guidelines can present simplified burdens on 
> domain policy assertion language authors; the instruction can be to 
> specify what repetition of a policy assertion of a type means only 
> when repetition does _/not/_ have the same meaning as a single 
> assertion of the type within the policy alternative.
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Ashok Malhotra
> *Sent:* Thursday, May 31, 2007 2:38 PM
> *To:* Paul Cotton
> *Cc:* public-ws-policy@w3.org
> *Subject:* RE: New issue on duplicate assertions of a single type in 
> an alternative: 4583
>
> I looked at the Policy assertions defined by WS-SX, WS-TX and 
> WS-Addressing. None of these assertions have parameters.
>
> I also looked at WS-SecurityPolicy. Parameters do appear in some of 
> these assertions but, as yesterday’s discussion on issue i134 
> indicates, these are considered “additional information” and not 
> considered part of the semantics of the assertion. Thus, matching 
> assertions with different values of these parameters is ok. AFAIK, 
> these parameters seem to be in the nature of comments.
>
> The word on the street is that parameters should not be used to convey 
> useful information in an assertion because of the WS-Policy 
> intersection algorithm which ignores parameters.
>
> If parameters are not used in assertions then the duplicate assertions 
> in the intersected policy are identical and can be removed.
>
> All the best, Ashok
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Paul Cotton
> *Sent:* Thursday, May 24, 2007 1:52 PM
> *To:* Ashok Malhotra
> *Cc:* public-ws-policy@w3.org
> *Subject:* RE: New issue on duplicate assertions of a single type in 
> an alternative: 4583
>
> >The framework document indicates that duplicate instances of an 
> assertion type are allowed in a policy alternative.
>
> You are correct. This is covered by the following two pieces of text 
> in the CR Framework document [1]:
>
> 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.
>
> Section 4.5: See Section 3.2 Policy Alternative for mechanisms for 
> determining the aggregate behavior indicated by multiple assertions of 
> the same policy assertion type.
>
> In fact the Section 3.2 text was in the member submission version of 
> WS-Policy [2].
>
> >1. Should duplicate instances of the same type be allowed in a policy 
> alternative before and after intersection.
>
> Yes. In fact if we want to carry out our Charter which indicates we 
> should be as backwards as compatible as possible [3], then I think we 
> need a very strong reason to change this text.
>
> >2. Do we need to add guidance re. removing duplicate assertions from 
> an alternative.
>
> Personally, I think the Section 3.2 text covers what the Framework 
> needs to say about duplicate assertions.
>
> >2. What is the default semantic re. the resulting behavior if there is 
> more than one instance of an assertion in an alternative.
>
> Section 3.2 says that the semantics for duplicate assertions are 
> covered by domain specific semantics.
>
> For example, during the WG F2F meeting you asked what a 
> WS-SecurityPolicy implementer should do if they encountered duplicate 
> EncryptedPart assertions in a policy. I believe this is handled by the 
> following text in SecurityPolicy just as suggested in the Ws-Policy 
> Framework text [4]:
>
> There MAY be multiple EncryptedParts assertions present. Multiple 
> EncryptedParts assertions present within a policy alternative are 
> equivalent to a single EncryptedParts assertion containing the union 
> of all specified message parts. Note that this assertion does not 
> require that a given part appear in a message, just that if such a 
> part appears, it requires confidentiality protection.
>
> I hope this helps.
>
> /paulc
>
> [1] http://www.w3.org/TR/2007/CR-ws-policy-20070330/
>
> [2] http://www.w3.org/Submission/WS-Policy/#Policy_Alternative
>
> [3] http://www.w3.org/2006/04/ws-policy-charter.html
>
> [4] 
> http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/23821/ws-securitypolicy-1.2-spec-cs.pdf
>
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> Tel: (613) 225-5445 Fax: (425) 936-7329
> mailto:Paul.Cotton@microsoft.com
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Ashok Malhotra
> *Sent:* May 24, 2007 3:01 PM
> *To:* public-ws-policy@w3.org
> *Subject:* New issue on duplicate assertions of a single type in an 
> alternative: 4583
>
> The framework document indicates that duplicate instances of an 
> assertion type are allowed in a policy alternative. During yesterday's 
> and today's discussion a number of questions arose about this situation.
>
> 1. Should duplicate instances of the same type be allowed in a policy 
> alternative before and after intersection.
>
> 2. Do we need to add guidance re. removing duplicate assertions from 
> an alternative.
>
> 2. What is the default semantic re. the resulting behavior if there is 
> more than one instance of an assertion in an alternative.
>
> All the best, Ashok
>

Received on Wednesday, 6 June 2007 03:42:41 UTC