W3C home > Mailing lists > Public > public-ws-policy@w3.org > June 2007

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

From: Felix Sasaki <fsasaki@w3.org>
Date: Fri, 01 Jun 2007 11:14:21 +0900
Message-ID: <465F80FD.6030701@w3.org>
To: Dale Moberg <dmoberg@us.axway.com>
CC: Ashok Malhotra <ashok.malhotra@oracle.com>, Paul Cotton <paul.cotton@microsoft.com>, public-ws-policy@w3.org

Dale Moberg wrote:
> 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.
>   

I am just saying that it is different than saying "this is out of scope" 
and IMO it reads contradictory. But other people might read it different.

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

my point was not mainly the testability, but the need for domain 
specific information. Again I think we cannot talk both on a 
framework-independent level *and* requiring domain-specific information.

Felix

>
> 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 02:14:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:52 GMT