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

I think you can't do both at the same time: Saying "outside the scope of
this document", and "If ... multiple assertions have the same meaning".
There is also no means to test the statement "fail to specify what
repetition ... means", since it implies domain specific information.

A question to Ashok: your last mail in this thread did not ask for a
change in any document. Neither did your initial description of bug 4583.
Could you make a concrete proposal, or do you think that is not necessary
(anymore)?

Thank you,

Felix

> 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 <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 Friday, 1 June 2007 00:15:56 UTC