Action-151 (was RE: Proposed Resolution - 3721 and 3789

"ACTION-151 Respond to Sergey to his questions 
on the 3721 and 3789 proposed resolution, 
Asir Vedamuthu 2006-11-16"


Hi Sergey,

>1. <iona:highlyAvailable/> assertion has these 
>semantics : a client runtime which understands 
>what it is may load a plugin which will tell 
>it to enumerate between mutiple service endpoints 
>in case of a communication failure with a given 
>endpoint. No wire representation. How should 
>we mark it so that we can interopreate with 
>third-party clients operating in both strict 
>and lax mode.

<iona:highlyAvailable/> assertion represents a behavior that may be engaged. This assertion can be marked optional.


>2. Will 'strict' mode cause the intersection 
>fail if a provider's policy contains wsp:MayBeIgnored >assertions ?  If yes, then how does it help 
>interoperability ? Can a strict mode intersection 
>succeed when we have wsp:MayBeIgnored assertions ?

First, the WG decided to use the tag 'wsp:Ignorable'. If the mode is strict, the new marker has no impact on the outcome of policy intersection.

Requestors have the option to chose one or more modes for policy intersection (strict | lax | strict, delegate-to-user | lax, delegate-to-user | strict, lax, delegate-to-user | ...)

A provider may provide requestors with out-of-band information to influence the choice of mode for policy intersection.


>3. Why would a requester's policy requirement ever 
>contain wsp:MayBeIgnored assertions ? Just so that the
>revised intersection algorithm could work ? How can a 
>third-party requester anticipate that a provider's 
>policy mat contain wsp:MayBeIgnored assertions ?

The WG considered informational assertions. For instance, provider always logs. Provider expresses the use of logging using an assertion whose semantics is: for your information, I am logging. This is a piece of information (or advertisement) for service consumers. Providers may use ignorable assertions (for such advertisements) to accommodate requestors who do not recognize these assertions.


>4. What is the difference between a compatibility 
>and equivalence ? If these are two diff terms then
>which one matters during the intersection ? Proposed resolution says that two assertions are equivalent 
>only if they're both ones are either not-ignorable 
>or ignorable.

Compatibility is a weaker form of equivalence. The policy intersection is used to determine compatibility. Equivalence of two {policy} properties is used for the WSDL 2.0 attachment mechanism.


>5. Proposed resoultion that by default assertions
>are not ignorable for intersection purposes. 
>Can someone tell me please if wsp:Optional 
>assertions are ignorable for intersection 
>purposes ? If they're then this text is misleading.

Optional and ignorable markers are orthogonal features. Optional is a syntactic shortcut for two alternatives: one with the assertion (say assertion x in alternative A) and another without the assertion (say alternative B). If assertion x or any other assertion is marked ignorable, then the assertion is an ignorable assertion and may be ignored for intersection. Otherwise, assertion x or any other assertion is not ignorable for policy intersection.


I hope this helps.

On behalf of the WS-Policy WG,
 
Asir S Vedamuthu
Microsoft Corporation



From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
Sent: Thursday, November 09, 2006 4:19 AM
To: Paul Cotton; Asir Vedamuthu; public-ws-policy@w3.org
Subject: Re: Proposed Resolution - 3721 and 3789

Hello
 
I'd like to ask for some clarifications...I truly appreciate a lot that the group has spent so much time and effort on resolving the issues we've submitted. The questions I'd like to ask are below and I'd really appreciate you spending some more time on them. I'm questioning the addition (or treatment, depend on the answers) of a new attribute and I'd simply like the clarification. Please try to look at them not as some negative comments. 
 
1. <iona:highlyAvailable/> assertion has these semantics : a client runtime which understands what it is may load a plugin which will tell it to enumerate between mutiple service endpoints in case of a communication failure with a given endpoint. No wire representation. How should we mark it so that we can interopreate with third-party clients operating in both strict and lax mode.
 
2. Will 'strict' mode cause the intersection fail if a provider's policy contains wsp:MayBeIgnored assertions ?  If yes, then how does it help interoperability ? Can a strict mode intersection succeed when we have wsp:MayBeIgnored assertions ?
 
3. Why would a requester's policy requirement ever contain wsp:MayBeIgnored assertions ? Just so that the revised intersection algorithm could work ? How can a third-party requester anticipate that a provider's policy mat contain wsp:MayBeIgnored assertions ?
 
4. What is the difference between a compatibility and equivalence ? If these are two diff terms then which one matters during the intersection ? Proposed resolution says that two assertions are equivalent only if they're both ones are either not-ignorable or ignorable.
 
5. Proposed resoultion that by default assertions are not ignorable for intersection purposes. Can someone tell me please if wsp:Optional assertions are ignorable for intersection purposes ? If they're then this text is misleading. 
 
Please answer to all these questions.
 
Many thanks
Sergey
 
----- Original Message ----- 
From: "Paul Cotton" <Paul.Cotton@microsoft.com>
To: "Asir Vedamuthu" <asirveda@microsoft.com>; <public-ws-policy@w3.org>
Sent: Wednesday, November 08, 2006 10:21 PM
Subject: RE: Proposed Resolution - 3721 and 3789

Attached are the notes of proposed changes to the 3721/3789 proposal that I took at today's F2F meeting.

/paulc

________________________________________
From: public-ws-policy-request@w3.org [public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu [asirveda@microsoft.com]
Sent: November 8, 2006 12:31 PM
To: public-ws-policy@w3.org
Subject: Proposed Resolution - 3721 and 3789

Please find a proposal to resolve issues 3721 and 3789.

On behalf of Maryann Hondo, Daniel Roth and Asir S Vedamuthu,

Asir S Vedamuthu
Microsoft Corporation

Received on Friday, 17 November 2006 05:29:46 UTC