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

Response to Felix

>>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".

It is outside the framework scope to specify domain specific semantics
for repetition of policy assertions of a type in a policy alternative.
That remains true. This says what is the default interpretation of
repetition if domain specific authors fail to specify what repetition
[of policy assertions of a type that have no parameters or subpolicies]
means. [I wish we had a term like "simple policy assertion" to refer to
this class of policy assertions.] I don't see what is inconsistent about
having a default and also saying that it can be overridden. You will
need to fill that part in for me.


>>There is also no means to test the statement "fail to specify what
>>repetition ... means", since it implies domain specific information.

There is also no means to test whether an application does the right
thing for repetition when a special domain meaning is specified. I am
not sure what you are driving at here or why you think this is a
difficulty. A framework may have some assertions (like definitions) that
are not testable. That does not mean that definitions (and other
informative ideas) do not belong in the framework.


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:39:53 UTC