- From: Gilbert Pilz <Gilbert.Pilz@bea.com>
- Date: Fri, 2 Mar 2007 04:24:05 -0800
- To: "Christopher B Ferris" <chrisfer@us.ibm.com>
- Cc: "Doug Davis" <dug@us.ibm.com>, <public-ws-addressing@w3.org>
- Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C034B4B3B@repbex01.amer.bea.com>
(trimmed the CC-list as this is really homing in on WS-Addr specific stuff).
I agree that the second of your two policies would work (mod the changes
Ashok suggested in WS-RX). The first policy really illustrates the point I
am trying to make. IF we define the absence of wsam:NonAnonymousResponses to
mean "senders must not send messages with ReplyTo and/or FaultTo addresses
that are not wsa:Anon" then your first policy won't get me what I want. I
want to send messages to this endpoint with a ReplyTo that contains
wsmc:Anon so that later, I can retrieve the response using
wsmc:MakeConnection. But wsmc:Anon != wsa:Anon so I would be violating the
wsam:Addressing assertions.
I think we need to either make a special case for the absence of
wsam:NonAnonymousResponses OR we have to document the fact that you will
almost always need to have it present if you don't want to rule out the
possibility of "other things" like WS-MC.
- gp
_____
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, March 01, 2007 12:00 PM
To: Gilbert Pilz
Cc: Doug Davis; public-ws-addressing@w3.org; ws policy;
public-ws-policy-request@w3.org; tom@coastin.com; wsrx
Subject: 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)
<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 Friday, 2 March 2007 12:26:13 UTC