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

Hi Asir

Thanks for allocating a dedicated action and answering to my questions.

We feel that our interoperability concerns have been addressed.
Specifically, we reckon, given your answers to my second question below, that providers will be able to advertise informational 
safe-to-ignore assertions such that requesters will be able to consume such services without failing at the intersection stage.

We also acknowledge the fact that it will be useful for requesters to cause an intersection failue when they encounter unrecognized 
(possibly unsafe-to-ignore) assertions.

Perhaps strict-mode requesters will be more 'willing' to ignore unrecognized ignorable assertions if those assertions have a 
safe-to-ignore statement signed by a recognized authority.

We consider this action being resolved

Thanks, Sergey



"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 16:55:53 UTC