- From: Tom Rutt <tom@coastin.com>
- Date: Wed, 28 Feb 2007 19:18:19 -0500
- To: Gilbert Pilz <Gilbert.Pilz@bea.com>
- CC: tom@coastin.com, wsrx <ws-rx@lists.oasis-open.org>, public-ws-addressing@w3.org, ws policy <public-ws-policy@w3.org>
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 00:18:59 UTC