Re: WS-Policy and interopearbility (Was: policy vocabulary, will not be applied, oh my!)

Ashok Malhotra wrote:
>
> Dan:
>
> You said ….
>
> 1. In order to interoperate with a web service there is a finite set 
> of behaviors or protocols that you have to engage (ex WS-Security, 
> WS-Addressing).
>
> I contest this. Could you take a stab at defining the universe of all 
> web services assertions.
>

let's talk about human interaction for a moment: for successful human 
interaction, you don't need to know the whole universe of concepts in a 
domain. But you need to know the concepts in the situationally grounded 
interaction.

To give more details: People have interaction in a situation. Let's 
assume two participants, let's say Q asking a questions and A giving an 
answer. To be able to successfully interact, Q and A need to agree on 
the same language, but not on the same set of words. They also need to 
have the same view on what constitutes the situation, for example the 
cultural context (e.g. Q and A are talking in Japan, vs. in the US). 
This context is *independent* of (or at least does not map 1:1: to) 
words in a specific human language.

A concrete example. Q says "should we eat fish together?". Q could also 
say instead "should we go to a fish restaurant?" or use other 
expressions, even in a different language. But to be able to reply 
adequately, A and Q need to share the understanding of "fish". For 
example, does "fish" encompass Fugu [1]?

My point is that:
- people do what was "said" (web services: the assertions), and only 
what was said, but
- what was said can only be "understood" (web services: the behavior can 
only be understood), on the ground of
- a "shared view on the (cultural) situation" (web services: a shared 
view of the domain).
Only with situationally grounded words (web services: a shared view of 
how to interpret assertions in the domain) it is clear what is meant by 
"fish", and a successful conversation and interaction becomes possible.

Going back to Ashoks warning about assertions which Oracle needs: Oracle 
might have a different view (a different "cultural" context) on the "eat 
fish" situation than others. They could say (let's assume different to 
others), "Fugu" [1] is the main fish in the restaurant they want to go. 
If Oracle as Q makes "Fugu" explicit saying "let's eat Fugu", A might 
say "no, I don't eat with you". If Oracle just says "fish" and hides the 
different understanding of what is meant by fish in the situation, A 
might enter the restaurant with Q, but leave without eating ... .

Felix

[1] http://en.wikipedia.org/wiki/Fugu

> I’ll warn you that Oracle has defined a bunch of assertions we need. 
> So, you couldn’t possibly include them in your set.
>
> Also, go take a look at security policy. The username token has a 
> bunch of variations. Security Policy defines assertions for some of 
> them but it’s not a complete set. At Oracle we have defined assertions 
> for the remaining options – say username token with nonce and clear 
> text password. So, trying to create a universe of Web Services 
> assertions is a hopeless task. And that’s why this proposal does not 
> make sense.
>
> All the best, Ashok
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Daniel Roth
> *Sent:* Wednesday, May 09, 2007 2:41 PM
> *To:* Dale Moberg; Sergey Beryozkin; public-ws-policy@w3.org
> *Cc:* David Orchard; Christopher B Ferris
> *Subject:* RE: WS-Policy and interopearbility (Was: policy vocabulary, 
> will not be applied, oh my!)
>
> Hi Dale,
>
> > My real question was about how adhering to “behaviors other than 
> those implied by policy assertions in a policy alternative will not be 
> engaged” produces interoperability . . .
>
> Here is the argument, step by step:
>
> 2. In order to interoperate with a web service there is a finite set 
> of behaviors or protocols that you have to engage (ex WS-Security, 
> WS-Addressing).
>
> 3. To interop with you need to engage those behaviors need for interop 
> and only those behaviors. If there were any other behaviors that 
> needed to be engaged then these behaviors would be part of the set of 
> behaviors needed for interop.
>
> 4. All other behaviors that have interop implications should not be 
> engaged (ex if you try to send an encrypted message to a service that 
> doesn’t do encryption, you won’t interop)
>
> Therefore, a policy alternative has to tell you everything you need to 
> do in order to interop and everything else you shouldn’t do.
>
> Note that if a behavior is not relevant to interop at all (ex logging) 
> then the behavior can be represented by an ignorable assertion or 
> simply left out of the policy.
>
> > and why that semantic should be baked into the framework, rather than 
> be made in remarks made when explaining a policy domain language’s 
> assertions.
>
> An assertion spec can only tell you what a specific assertion means. 
> The Framework has to tell you what a policy alternative means.
>
> > It seems to me that if a specific behavior should be prohibited in 
> order that interoperability occurs,
>
> > that a specific negation of a policy should be present to indicate it 
> must not be combined with the positive assertions.
>
> > Otherwise it becomes somewhat vague as to what range of behaviors it 
> is important not to engage for a given policy alternative.
>
> The IBM proposal makes it explicit that only the behaviors described 
> by a policy alternative should be done in order to interop. No other 
> behaviors relevant to interop should be done.
>
> Engaging a behavior in a web services stack is a very explicit thing. 
> Either the software module implementing the behavior is there or it 
> isn’t. So, in an implementation, not engaging any other behaviors is 
> actually a very straight forward thing to do.
>
> I hope this helps.
>
> Daniel Roth
>
> *From:* Dale Moberg [mailto:dmoberg@us.axway.com]
> *Sent:* Wednesday, May 09, 2007 8:25 AM
> *To:* Sergey Beryozkin; public-ws-policy@w3.org
> *Cc:* David Orchard; Daniel Roth; Christopher B Ferris
> *Subject:* RE: WS-Policy and interopearbility (Was: policy vocabulary, 
> will not be applied, oh my!)
>
> Agreed that ws-policy can indicate something about 
> requirements/capabilities available. My real question was about how 
> adhering to “behaviors other than those implied by policy assertions 
> in a policy alternative will not be engaged” produces 
> interoperability, and why that semantic should be baked into the 
> framework, rather than be made in remarks made when explaining a 
> policy domain language’s assertions. It seems to me that if a specific 
> behavior should be prohibited in order that interoperability occurs, 
> that a specific negation of a policy should be present to indicate it 
> must not be combined with the positive assertions. Otherwise it 
> becomes somewhat vague as to what range of behaviors it is important 
> not to engage for a given policy alternative.
>
> ------------------------------------------------------------------------
>
> *From:* Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> *Sent:* Wednesday, May 09, 2007 3:53 AM
> *To:* Dale Moberg; public-ws-policy@w3.org
> *Cc:* 'David Orchard'; 'Daniel Roth'; 'Christopher B Ferris'
> *Subject:* WS-Policy and interopearbility (Was: policy vocabulary, 
> will not be applied, oh my!)
>
> Hi
>
> > Second, I am also puzzled about the emergence of the concern with 
> interoperability.
>
> IMHO it’s a very legitimate concern. WS-Policy may enhance the chances 
> for the interoperability.
>
> May be it’s not the main goal of the specs, but the positive 
> side-effect can be achieved.
>
> For example, various custom WSDL extensors can be turned into 
> WS-Policy extensors and then even standardized.
>
> Other example is that often the capabilities are sometimes bundled 
> into the (WSDL) endpoint extensors, say, security-related ones.
>
> Extracting such capabilities into standalone WS-Policy extensors can 
> only increase the chance for the interoperability between third-party
>
> clients of a given service
>
> Thanks, Sergey
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Dale Moberg
> *Sent:* 08 May 2007 23:16
> *To:* public-ws-policy@w3.org
> *Cc:* David Orchard; Daniel Roth; Christopher B Ferris
> *Subject:* RE: policy vocabulary, will not be applied, oh my!
>
> First, I prefer Monica and Ashok’s proposed revisions. I can 
> understand their proposal. I share Mr. Orchard’s concerns about trying 
> to finesse the difficulties with the original AIN.
>
> Second, I am also puzzled about the emergence of the concern with 
> interoperability.
>
> Is it the intention that the ws-policy framework somehow ensure that 
> when there exist policy alternatives in common between proposer’s 
> policy and consumer’s policy, then the proposer and consumer will 
> interoperate? It seems that there might be a lot of “behavior” not 
> covered by any policy domain expression that could cause 
> interoperability problems (like extensions, etc), so it will be very 
> difficult to defend the idea that agreeing on the same policy 
> alternative ensures interoperability.
>
> Anyway, isn’t the WS-I organization one primary forum where 
> conformance profiles and promotion of WS interoperability is to occur? 
> Our charter only says that
>
> The Working Group may also:
>
>     * Author a primer that includes guidance on the use of policy
>       expressions to facilitate Web services interoperability and
>       guidelines for authoring policy assertions, and
>
> I don’t see that either the framework or attachment documents are 
> devoted to interoperability. It would be nice if the ws-policy 
> framework provided a general solution to WS interoperability, but I 
> think that is taking on some big problems that are not explicitly in 
> scope. Possibly I misunderstand, however; so I would like to see an 
> explicit statement of the design intent that connects the policy 
> framework ambitions with WS interoperability. Maybe that way we can 
> understand the NOBI option’s rationale.
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *David Orchard
> *Sent:* Tuesday, May 08, 2007 2:46 PM
> *To:* Daniel Roth; Ashok Malhotra; Asir Vedamuthu; Christopher B 
> Ferris; public-ws-policy@w3.org
> *Subject:* RE: policy vocabulary, will not be applied, oh my!
>
> I don't get it. The very precise sentence that you state "If a 
> behavior isn’t implied, then it shouldn’t be applied if you want to 
> interop" says to me AIN.
>
> Now MAYbe you are saying
>
> AIN: "If a behavior isn’t implied, then it MUST not be applied"
>
> and NOBI: "If a behavior isn’t implied, then it shouldn’t be applied "
>
> and someother acronym: "If a behavior isn’t implied, then it may or 
> may not be applied as there is no implied behaviour"
>
> is that where we are at? Then you are disambiguating between AIN and 
> NOBI by MUST vs SHOULD?
>
> Cheers,
>
> Dave
>
>     ------------------------------------------------------------------------
>
>     *From:* Daniel Roth [mailto:Daniel.Roth@microsoft.com]
>     *Sent:* Tuesday, May 08, 2007 2:40 PM
>     *To:* David Orchard; Ashok Malhotra; Asir Vedamuthu; Christopher B
>     Ferris; public-ws-policy@w3.org
>     *Subject:* RE: policy vocabulary, will not be applied, oh my!
>
>     Hi David,
>
>     NOBI simply means that an alternative implies the behaviors that
>     are asserted and No Other Behaviors are Implied. If a behavior
>     isn’t implied, then it shouldn’t be applied if you want to interop.
>
>     Chris’ proposal gets us out of the mess of having to consider
>     policy vocabularies or absent assertions (AIN stuff) in order to
>     understand what an alternative implies you have to do in order to
>     interop.
>
>     Daniel Roth
>
>     *From:* David Orchard [mailto:dorchard@bea.com]
>     *Sent:* Tuesday, May 08, 2007 1:43 PM
>     *To:* Daniel Roth; Ashok Malhotra; Asir Vedamuthu; Christopher B
>     Ferris; public-ws-policy@w3.org
>     *Subject:* RE: policy vocabulary, will not be applied, oh my!
>
>     Dan,
>
>     I'm confused about your terms and language. there are the acronyms
>     NOBI and NOIB, which I think are the same. Assuming that, it seems
>     that there's been a terminology swizzle so that NOBI has become
>     AIN. AFAICT, your "For example" is an example of AIN.
>
>     Can you tell me how NOBI is different than AIN now?
>
>     Cheers,
>
>     Dave
>
>         ------------------------------------------------------------------------
>
>         *From:* public-ws-policy-request@w3.org
>         [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Daniel
>         Roth
>         *Sent:* Tuesday, May 08, 2007 1:35 PM
>         *To:* Ashok Malhotra; Asir Vedamuthu; Christopher B Ferris;
>         public-ws-policy@w3.org
>         *Subject:* RE: policy vocabulary, will not be applied, oh my!
>
>         Hi Ashok,
>
>         Chris’ proposal is actually exactly what I meant by NOBI. An
>         alternative should express exactly those behaviors that are
>         needed for interop and nothing else should be done.
>
>         For example, if I have an alternative that says I require
>         message security, then requesters should not also enable
>         transport security and expect to interoperate.
>
>         Chris’ proposal looks good to me.
>
>         Daniel Roth
>
>         *From:* public-ws-policy-request@w3.org
>         [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Ashok
>         Malhotra
>         *Sent:* Tuesday, May 08, 2007 11:42 AM
>         *To:* Asir Vedamuthu; Christopher B Ferris;
>         public-ws-policy@w3.org
>         *Subject:* RE: policy vocabulary, will not be applied, oh my!
>
>         So, Asir, just to be clear, this position is different from
>         the NOIB (No Implied Behavior) that Dan espoused on last
>         Wednesday’s call.
>
>         All the best, Ashok
>
>         ------------------------------------------------------------------------
>
>         *From:* public-ws-policy-request@w3.org
>         [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Asir
>         Vedamuthu
>         *Sent:* Tuesday, May 08, 2007 9:22 AM
>         *To:* Christopher B Ferris; public-ws-policy@w3.org
>         *Subject:* RE: policy vocabulary, will not be applied, oh my!
>
>         +1
>
>         An alternative with one or more assertions indicates behaviors
>         implied by those, and only those assertions. If a policy
>         alternative does not specify a behavior then the alternative
>         means the behavior is not applied.
>
>         Regards,
>
>         Asir S Vedamuthu
>
>         Microsoft Corporation
>
>         *From:* public-ws-policy-request@w3.org
>         [mailto:public-ws-policy-request@w3.org] *On Behalf Of
>         *Christopher B Ferris
>         *Sent:* Tuesday, May 08, 2007 5:01 AM
>         *To:* public-ws-policy@w3.org
>         *Subject:* Re: policy vocabulary, will not be applied, oh my!
>
>
>         All,
>
>         I've been thinking about this, and possible language that
>         would make things clear to the reader that an alternative's
>         set of
>         assertions implies that ONLY those behaviors implied by those
>         assertions are applied in the context of an interchange
>         governed by that policy alternative.
>
>         Also, since there isn't an issue to go with this thread, and
>         it may well end up with CR edits to the
>         spec, I opened an issue (4544) in Bugzilla:
>
>         http://www.w3.org/Bugs/Public/show_bug.cgi?id=4544
>
>         The first paragraph in section 3.2 of the Framework currently
>         reads:
>
>         [Definition: A *policy alternative* is a potentially empty
>         collection of policy assertions
>         <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion>.]
>         An alternative with zero assertions indicates no behaviors. An
>         alternative with one or more assertions indicates behaviors
>         implied by those, and only those assertions. [Definition: A
>         *policy vocabulary* is the set of all policy assertion types
>         <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion_type>
>         used in a policy.] [Definition: A *policy alternative
>         vocabulary* is the set of all policy assertion types
>         <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion_type>
>         within the policy alternative
>         <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_alternative>.]
>         When an assertion whose type is part of the policy's
>         vocabulary is not included in a policy alternative, the policy
>         alternative without the assertion type indicates that the
>         assertion will not be applied in the context of the attached
>         policy subject. See the example in Section *4.3.1 Optional
>         Policy Assertions*
>         <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#Optional_Policy_Assertions>
>
>
>         I would propose the following change:
>
>         [Definition: A *policy alternative* is a potentially empty
>         collection of policy assertions
>         <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion>.]
>         An alternative with zero assertions indicates no behaviors. An
>         alternative with one or more assertions indicates behaviors
>         implied by those, and only those assertions. No other
>         behaviors are to be applied for the alternative.
>
>         The rest of the edits in the original proposal [1] remain
>         unchanged.
>
>         [1]
>         http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0003.html
>
>
>         Cheers,
>
>         Christopher Ferris
>         STSM, Software Group Standards Strategy
>         email: chrisfer@us.ibm.com
>         blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
>         phone: +1 508 377 9295
>
>         public-ws-policy-request@w3.org wrote on 05/07/2007 09:07:16 AM:
>
>         >
>         > +1,
>         >
>         > (Thanks Chris, for providing an example. Makes it much
>         clearer for
>         > understanding issue.)
>         >
>         > regards, Frederick
>         >
>         > Frederick Hirsch
>         > Nokia
>         >
>         >
>         > On May 2, 2007, at 5:19 AM, ext Sergey Beryozkin wrote:
>         >
>         > > Hi Chris
>         > >
>         > > Would it be possible to post an example which would show a
>         > > realistic scenario where it's obvious the fact that the input
>         > > policy vocabulary is not included in the effective policy's
>         > > vocabulary may cause the problems for a client ? I just
>         find it
>         > > difficult to understand the reasoning when policies A&B are
>         used in
>         > > examples :-)
>         > >
>         > > Also, I don't understand why the client can not use the
>         effective
>         > > policy's vocabulary as the guidance on what assertions can be
>         > > applied. The fact that many more assertions might've been
>         involved
>         > > in the intersection seems unimportant to me, the client can
>         not
>         > > apply what the effective policy has now, that is whatever
>         > > assertions are in the selected alternative. I think this is
>         what
>         > > Monica said in the other email (sorry if misinterpreted
>         that email
>         > > reply).
>         > >
>         > > I hope the practical example will help to understand the
>         problem
>         > > better
>         > >
>         > > Thanks, Sergey
>         > > ----- Original Message -----
>         > > From: Christopher B Ferris
>         > > To: public-ws-policy@w3.org
>         > > Sent: Tuesday, May 01, 2007 9:22 PM
>         > > Subject: policy vocabulary, will not be applied, oh my!
>         > >
>         > >
>         > > There are some related issues/questions/concerns that have
>         been
>         > > expressed by members
>         > > of the WG with regards the framework specification as it
>         relates to
>         > > the "will not be applied" principle
>         > > and the definions for "policy vocabulary", etc. Below, I have
>         > > enumerated these issues
>         > > and suggest a path forward to address those concerns.
>         > >
>         > > 1. The definition of "policy vocabulary" is incompatible with
>         > > intersected policy as regards to
>         > > the "will not be applied" principle because post
>         intersection, the
>         > > resultant policy expression
>         > > does not carry the policy vocabulary of the input policy
>         > > expressions. Hence, if a provider
>         > > had two alternatives, one with Foo and one without Foo, and
>         the
>         > > result of intersection determined
>         > > that the alternative without Foo was compatible with a
>         client's
>         > > policy, then the resultant
>         > > policy expression would not have in its vocabulary (as
>         computed
>         > > using the algorithim
>         > > currently specified) Foo and hence it would not be clear
>         whether
>         > > Foo carries with it
>         > > the "will not be applied" semantic.
>         > >
>         > > Action-283 -
>         http://lists.w3.org/Archives/Public/public-ws-policy/
>         > > 2007Apr/0103.html
>         > > Action-284 -
>         http://lists.w3.org/Archives/Public/public-ws-policy/
>         > > 2007Apr/0106.html
>         > > Ashok email -
>         http://lists.w3.org/Archives/Public/public-ws-policy/
>         > > 2007Apr/0065.html
>         > >
>         > > 2. There is a degree of confusion regarding the "will not be
>         > > applied" semantic as it applies to nested policy.
>         > > This is related to the interpretation of "policy
>         vocabulary" that
>         > > many held prior to the clarification provided by
>         > > Microsoft
>         > >
>         > > Asir's email on nested policy vocabulary -
>         http://lists.w3.org/
>         > > Archives/Public/public-ws-policy/2007Apr/0017.html
>         > >
>         > > 3. As a result, a number of email threads have sprung up that
>         > > question the merits of the "will not be applied"
>         > > semantic.
>         > >
>         > > Ashok - http://lists.w3.org/Archives/Public/public-ws-policy/
>         > > 2007Apr/0065.html
>         > > Dale -
>         http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/
>         > > 0075.html
>         > > Ashok - http://lists.w3.org/Archives/Public/public-ws-policy/
>         > > 2007Apr/0101.html
>         > > Dale -
>         http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/
>         > > 0108.html
>         > >
>         > > It may be that the most prudent course forward would be to
>         drop the
>         > > "will not be applied" semantic as relates
>         > > policy vocabulary. As a result, there is little need of a
>         normative
>         > > definion for policy vocabulary or policy alternative
>         > > vocabulary, as these definitions only served to allow one to
>         > > determine whether the behavior implied by a
>         > > given assertion carried the "will not be applied" semantic.
>         > >
>         > > Instead, we could simply state that the behavior implied by an
>         > > assertion that is absent from a given alternative
>         > > is not to be applied in the context of the attached policy
>         subject
>         > > when that alternative is engaged.
>         > > This would provide clearer semantic (I believe) to borth
>         assertion
>         > > and policy authors.
>         > >
>         > > The attached mark-up of the policy framework specification
>         contains
>         > > the changes that I believe would
>         > > be necessary to affect this change.
>         > >
>         > > Impact analysis:
>         > >
>         > > - The proposed change does not affect the XML syntax
>         > > - Nor does it impact the semantics of the namespace,
>         therefore the
>         > > namesapce URI can remain unchanged
>         > > - It does not affect the processing model (normalization,
>         > > intersection)
>         > > - It does not impact testing results to date
>         > > - It does not affect any of the assertion languages
>         developed to date
>         > >
>         > > The related questsion that needs to be asked should we
>         choose to
>         > > adopt this proposal is:
>         > >
>         > > Does this change affect any implementations?
>         > >
>         > > From analysis of the set of test cases, the answer is not
>         clear,
>         > > because there were no tests that
>         > > excercised either policy vocabulary or the "will not be
>         applied"
>         > > semantic. Thus, it would be important that
>         > > we check our respective implementations to ascertain
>         whether there
>         > > would be any impact. From an IBM
>         > > perspective, this change does not impact our implementation.
>         > >
>         > >
>         > >
>         > > Cheers,
>         > >
>         > > Christopher Ferris
>         > > STSM, Software Group Standards Strategy
>         > > email: chrisfer@us.ibm.com
>         > > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
>         > > phone: +1 508 377 9295
>         >
>         >
>

Received on Thursday, 10 May 2007 05:22:15 UTC