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

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