Re: [ws-rx] RE: Absence of wsam:NonAnon implies prohibition of non-anon response (was RE: [ws-rx] I just posted a PR comment on MakeConnection Policy assertion) from Christopher B Ferris on 2007-03-01 (public-ws-addressing@w3.org from March 2007)

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Thu, 1 Mar 2007 14:59:43 -0500
To: "Gilbert Pilz" <Gilbert.Pilz@bea.com>
Cc: Doug Davis <dug@us.ibm.com>, public-ws-addressing@w3.org, "ws policy" <public-ws-policy@w3.org>, public-ws-policy-request@w3.org, tom@coastin.com, "wsrx" <ws-rx@lists.oasis-open.org>
Message-ID: <OF444BA191.F9C1CCEE-ON85257291.006D54F6-85257291.006DD699@us.ibm.com>
<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All>
      <wsa:Addressing>
        <wsa:AnonymousResponses/>
      </wsa:Addressing>
    </ws:All>
    <wsp:All>
      <wsa:Addressing/>
      <wsmc:MCSupported/>
    </ws:All>
  </wsp:ExactlyOne>
</wsp:Policy>

I believe that is the policy that you are seeking. One could argue that 
this policy is also
valid (and consistent with what we are trying to express):

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All>
      <wsa:Addressing>
        <wsa:AnonymousResponses/>
      </wsa:Addressing>
    </ws:All>
    <wsp:All>
      <wsa:Addressing>
        <wsa:NonAnonymousResponses/>
      </wsa:Addressing>
      <wsmc:MCSupported/>
    </ws:All>
  </wsp:ExactlyOne>
</wsp:Policy>

Of course, the key is that the nested policy is optional. So, for those of 
you who think that the 
MCanon is inconsistent with wsa:NonAnonymousResponses, then the former 
example might be
more suitable.

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

"Gilbert Pilz" <Gilbert.Pilz@bea.com> wrote on 03/01/2007 02:46:40 PM:

> Except for the fact the WS-RM requires the use of WS-Addr . . .
> 
> - gp
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Thursday, March 01, 2007 10:52 AM
> To: Gilbert Pilz
> Cc: public-ws-addressing@w3.org; ws policy; public-ws-policy-
> request@w3.org; tom@coastin.com; wsrx
> Subject: RE: Absence of wsam:NonAnon implies prohibition of non-anon
> response (was RE: [ws-rx] I just posted a PR comment on 
> MakeConnection Policy assertion)

> 
> I agree - it would not give you the semantics you want.  Now, switch
> the outer "All" with "ExactlyOne" and you'd get it (I think). 
> 
> thanks
> -Doug
> ______________________________________________________
> STSM  |  Web Services Architect  |  IBM Software Group
> (919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com 
> 

> 
> "Gilbert Pilz" <Gilbert.Pilz@bea.com> 
> Sent by: public-ws-policy-request@w3.org 
> 03/01/2007 01:43 PM 
> 
> To
> 
> Doug Davis/Raleigh/IBM@IBMUS 
> 
> cc
> 
> <public-ws-addressing@w3.org>, "ws policy" <public-ws-policy@w3.
> org>, <public-ws-policy-request@w3.org>, <tom@coastin.com>, "wsrx" 
> <ws-rx@lists.oasis-open.org> 
> 
> Subject
> 
> RE: Absence of wsam:NonAnon implies prohibition of non-anon response
> (was RE: [ws-rx] I just posted a PR comment on MakeConnection 
Policyassertion)
> 
> 
> 
> 
> I agree that, at a shallow level, the policy is 'valid'. However, if
> I wanted to indicate to clients that they must use ReplyTo addressesthat 
are 
> either wsa:anon or wsmc:anon, this is an incorrect policy. Agreed? 
> 
> - gp 
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Thursday, March 01, 2007 10:20 AM
> To: Gilbert Pilz
> Cc: public-ws-addressing@w3.org; ws policy; public-ws-policy-
> request@w3.org; tom@coastin.com; wsrx
> Subject: Re: Absence of wsam:NonAnon implies prohibition of non-anon
> response (was RE: [ws-rx] I just posted a PR comment on 
> MakeConnection Policy assertion)
> 
> 
> I believe this is valid from a policy perspective. 
> wsa:ReplyTo must be wsa:Anon   but it allows for other EPRs (just 
> not wsa:ReplyTo/FaultTo) to use MCanonURI. 
> 
> thanks
> -Doug
> ______________________________________________________
> STSM  |  Web Services Architect  |  IBM Software Group
> (919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com 

> 
> "Gilbert Pilz" <Gilbert.Pilz@bea.com> 
> Sent by: public-ws-policy-request@w3.org 
> 03/01/2007 01:14 PM 
> 
> To
> 
> <tom@coastin.com> 
> 
> cc
> 
> "wsrx" <ws-rx@lists.oasis-open.org>, <public-ws-addressing@w3.org>, 
> "ws policy" <public-ws-policy@w3.org> 
> 
> Subject
> 
> Absence of wsam:NonAnon implies prohibition of non-anon response 
> (was RE: [ws-rx] I just posted a PR comment on MakeConnection 
Policyassertion)
> 
> 

> 
> 
> 
> 
> 
> Tom,
> 
> It seems the following policy would be invalid under your model because
> there is no wsam:NonAnonymousResponses assertion yet a ReplyTo that
> contained an instance of the wsmc:anon URI would be a non-anonymous
> response. Do you agree?
> 
> <wsp:Policy wsu:Id="RMResponsePolicy">
> <wsp:All>
>   <wsam:Addressing>
>     <wsp:Policy>
>       <wsp:ExactlyOne> 
>         <wsp:All>
>           <wsam:AnonymousResponses/> 
>         </wsp:All> 
>       <wsp:ExactlyOne> 
>     </wsp:Policy> 
>   </wsam:Addressing>
>   <wsmc:MCRequired/>
> </wsp:All>
> </wsp:Policy>
> 
> - gp
> 
> > -----Original Message-----
> > From: Tom Rutt [mailto:tom@coastin.com] 
> > Sent: Wednesday, February 28, 2007 4:18 PM
> > To: Gilbert Pilz
> > Cc: tom@coastin.com; wsrx; public-ws-addressing@w3.org; ws policy
> > Subject: Re: [ws-rx] I just posted a PR comment on 
> > MakeConnection Policy assertion
> > 
> > I put an example policy which has three alternatives
> > 
> > These cover the CR33 is in my opinion.
> > 
> > The following example shows an equivalent policy expression, 
> > assuming proposed alternative A (wsa:NonAnonymous defined as 
> > any URI value other than
> > wsa:Anonymous) is selected.  This requires use of 
> > MakeConnection to be treated as a special case of 
> > wsam:nonAnonymous reply.
> > 
> > 
> > 
> > <wsp:Policy>  <-- Policy expression for proposed alternative 
> > a) --> ..<wsp:ExactlyOne>
> > 
> > ....<wsp:All>
> > ......<wsam:Addressing>
> > ........<wsp:Policy>
> > ..........<wsp:ExactlyOne>
> > ..........<!-- anon or non-anon responses required--> 
> > ............<wsp:All> ..............<wsam:AnonymousResponses/>
> > ............</wsp:All>
> > ............<wsp:All>
> > ...............<wsam:NonanonymousResponses/>
> > ............</wsp:All>
> > ..........</wsp:ExactlyOne>
> > ........</wsp:Policy>
> > ......</wsam:Addressing>
> > ......<!--  wsmc:MakeConnection is not asserted as part of > this 
> all, thus no statement on its use in this alternative > --.> ....
> </wsp:All>> > > ....<! Addressing required, only use makeConnection 
> for reply -->
> > ....<wsp:All>
> > ......<wsam:Addressing>
> > ........<wsp:Policy>
> > ..........<wsp:ExactlyOne>
> > ..........<!-- non-anon responses required-->
> > ............<wsp:All>
> > ...............<wsam:NonanonymousResponses/>
> > ............<wsp:All>
> > ..........</wsp:ExactlyOne>
> > ........</wsp:Policy>
> > ......</wsam:Addressing>
> > ......<wsmc:MakeConnection/>
> > ....</wsp:All>
> > ..</wsp:ExactlyOne>
> > </wsp:Policy>
> > 
> > 
> > 
> > Tom Rutt wrote:
> > > Comments below
> > >
> > > Tom Rutt
> > >
> > > Gilbert Pilz wrote:
> > >> This discussion really belongs in WS-Addr so I've 
> > cross-posted . . .
> > >>
> > >> I'm very uncomfortable with the idea that the non-presence of the
> > >> wsam:NonAnonymousResponses implies that non-anonymous 
> > reply addresses 
> > >> are
> > >> not supported. Doesn't this just re-open the festering 
> > wound of CR33?
> > >>
> > >> Both the wsam:AnonymousResponses and wsmc:MCResponses assertions 
> > >> refer to
> > >> the use of fairly specific URIs, but wsam:NonAnonymousResponses 
> > >> refers to
> > >> the use of *any* URI other than
> > >> "http://www.w3.org/2005/08/addressing/anonymous". To say that the 
> > >> absence of
> > >> wsam:NonAnonymousResponses implies its negation is to say 
> > that *only*
> > >> wsa:Anon is supported (thus ruling out things like the 
> > wsmc:Anon URI).
> > >> Didn't we spend months figuring out that this wouldn't work?
> > >> 
> > > Since these two policy assetions are nested in Addressing 
> > asssertion, 
> > > any policy maker
> > > who includes the addressing assertion is aware of the 
> > semantics of its 
> > > two nested policy assertion types.
> > >
> > > That policy maker can construct a policy expression which contains 
> > > enough alternatives to
> > > cover all the response mechanisms it wants to use with that 
> > endpoint.
> > > Anyway, lets assume we take out the text about "non presence means 
> > > prohibition".  if someone puts int "AnonymousResponses" nested 
> > > assertion in an addressing assertion and it is a 
> > requirement, that is 
> > > saying that other type of responses cannot be used (since 
> > anonymous is 
> > > required for instances of responses).  Thus to allow use of non 
> > > anonymous responses and anonymous responses would require two 
> > > alternative in the policy expression.
> > >
> > > If we have to deal with alternatives anyway to espress the 
> > necessary 
> > > semantics of replies in a policy expression, I do not see 
> > the problem 
> > > of having "non Presence" of the NonAnonymousResponses
> > > nested assertion in any alternative involving addressing assetion 
> > > implying non-anonymous is prohibited.  Just add another alternative 
> > > which includes the nested assertion you want.
> > >
> > >
> > > Tom Rutt
> > >> - gp
> > >>
> > >> 
> > >>> -----Original Message-----
> > >>> From: Tom Rutt [mailto:tom@coastin.com] Sent: Tuesday, 
> > February 27, 
> > >>> 2007 12:56 PM
> > >>> To: tom@coastin.com
> > >>> Cc: Doug Davis; wsrx
> > >>> Subject: Re: [ws-rx] I just posted a PR comment on MakeConnection 
> > >>> Policy assertion
> > >>>
> > >>> Tom Rutt wrote:
> > >>> 
> > >>>> Tom Rutt wrote:
> > >>>> 
> > >>>>> Doug Davis wrote:
> > >>>>> 
> > >>>> I now understand that your changes are required since make 
> > >>> connection 
> > >>>> can also be used for delivering requests.
> > >>>>
> > >>>> Thus I agree with our changes to my proposal.
> > >>>>
> > >>>> However we still need to discuss the need for a statement on Non 
> > >>>> Presence implying prohibition.
> > >>>> 
> > >>> After talking to some ws-policy experts, it seems that because 
> > >>> MakeConnection is a first level policy assertion type, lack of 
> > >>> presence of this assertion anywhere in a policy alternative says 
> > >>> nothing about its use.
> > >>>
> > >>> The difference with ws addressing nested paramters is 
> > that they are 
> > >>> defined within the context of the first level assertion 
> > "addressing" 
> > >>> .  This for these nested parameters, non presence within an 
> > >>> asseretion of "addressing" policy  implies prohibition of that 
> > >>> alternative.
> > >>>
> > >>> The tricky part is if a policy has two alternatives, and one of 
> > >>> those alternative includes the MakeConnection assertion, 
> > that policy 
> > >>> statement has introduced MakeConnection into the policy 
> > vocabulary. 
> > >>> In such a case, does absence in one of the assertions imply not 
> > >>> using make connection?
> > >>>
> > >>> eg
> > >>>
> > >>> <wsp:Policy>
> > >>> <wsp:ExactlyOne>
> > >>> <wsp:All>
> > >>> <wsmc:MakeConnection/>
> > >>> </wsp:All>
> > >>> <wsp:All>
> > >>> <-- does this alternative prohibit use of MakeConnection?? -->
> > >>> </wsp:All>
> > >>> </wsp:ExactlyOne>
> > >>> </wsp:Policy>
> > >>>
> > >>> 
> > >>>> This discsussion needs to distinguish an endpoint which 
> > has 
> > >>> no policy 
> > >>>> statement attached, from one which has policy attached, 
> > but 
> > >>> does not 
> > >>>> include the makeConnection assertion in any alternative.
> > >>>> 
> > >>>>>> Tom,
> > >>>>>> you proposed:
> > >>>>>> Change lines 327 - 329 from:
> > >>>>>> "
> > >>>>>> The MakeConnection policy assertion indicates that the 
> > 
> > >>> MakeConnection
> > >>> 
> > >>>>>> protocol (operation and the use of the MakeConnection 
> > URI 
> > >>> template in
> > >>> 
> > >>>>>> EndpointReferences) is supported. This assertion has 
> > >>> Endpoint Policy
> > >>> 
> > >>>>>> Subject [WS-PolicyAttachment].
> > >>>>>> "
> > >>>>>> To
> > >>>>>> "
> > >>>>>> The MakeConnection policy assertion indicates that the 
> > 
> > >>> MakeConnection
> > >>> 
> > >>>>>> protocol (operation and the use of the MakeConnection 
> > URI 
> > >>> template in
> > >>> 
> > >>>>>> EndpointReferences) is required for instances of replies. This
> > >>>>>> assertion has Endpoint Policy Subject [WS-PolicyAttachment].
> > >>>>>> "
> > >>>>>> Since MC doesn't talk about any EPR in particular I 
> > think 
> > >>> it would 
> > >>>>>> make more sense to reword as:
> > >>>>>> "
> > >>>>>> The MakeConnection policy assertion indicates that the 
> > 
> > >>> MakeConnection
> > >>> 
> > >>>>>> protocol (operation and the use of the MakeConnection 
> > URI 
> > >>> template in
> > >>> 
> > >>>>>> EndpointReferences) is required for messages from this 
> > 
> > >>> endpoint. This
> > >>> 
> > >>>>>> assertion has Endpoint Policy Subject [WS-PolicyAttachment].
> > >>>>>> 
> > >>>>> your wording removed "required for instances of 
> > replies". Is this 
> > >>>>> because you wish it to be used for requests as well.?
> > >>>>> 
> > >>>>>> "
> > >>>>>> And then you suggested:
> > >>>>>> Change line 334 from:
> > >>>>>> "
> > >>>>>> A policy assertion that specifies that the 
> > MakeConnection 
> > >>> protocol is
> > >>> 
> > >>>>>> supported.
> > >>>>>> "
> > >>>>>> To
> > >>>>>> "
> > >>>>>> A policy assertion that specifies that the 
> > MakeConnection 
> > >>> protocol is
> > >>> 
> > >>>>>> required for instances of replies from an endpoint.
> > >>>>>> "
> > >>>>>> And I would suggest this instead:
> > >>>>>> "
> > >>>>>> A policy assertion that specifies that the 
> > MakeConnection 
> > >>> protocol is
> > >>> 
> > >>>>>> required for instances of messages from this endpoint.
> > >>>>>> "
> > >>>>>>
> > >>>>>> 
> > >>>>> same question, I assumed makeConnection is for 
> > responses, are you
> > >>>>> are pointing out it can also be used for requests?
> > >>>>> Tom
> > >>>>> 
> > >>>>>> As to Paul's question of severity of this change, it 
> > >>> would seem that
> > >>> 
> > >>>>>> your text is still consistent with the intent of the 
> > >>> original text,
> > >>> 
> > >>>>>> as such it seems like a non-substantive change. Would 
> > you agree?
> > >>>>>>
> > >>>>>> thanks
> > >>>>>> -Doug
> > >>>>>> ______________________________________________________
> > >>>>>> STSM | Web Services Architect | IBM Software Group
> > >>>>>> (919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com
> > >>>>>>
> > >>>>>> 
> > >>>>> ----------------------------------------------------
> > >>>>> Tom Rutt    email: tom@coastin.com; trutt@us.fujitsu.com
> > >>>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133
> > >>>>>
> > >>>>>
> > >>>>> 
> > >>>> 
> > >>> -- 
> > >>> ----------------------------------------------------
> > >>> Tom Rutt    email: tom@coastin.com; trutt@us.fujitsu.com
> > >>> Tel: +1 732 801 5744          Fax: +1 732 774 5133
> > >>>
> > >>>
> > >>>
> > >>> 
> > >
> > 
> > -- 
> > ----------------------------------------------------
> > Tom Rutt                 email: tom@coastin.com; trutt@us.fujitsu.com
> > Tel: +1 732 801 5744          Fax: +1 732 774 5133
> > 
> > 
> >
Received on Thursday, 1 March 2007 20:00:01 UTC