- From: Tom Rutt <tom@coastin.com>
- Date: Wed, 28 Feb 2007 18:19:13 -0500
- To: Gilbert Pilz <Gilbert.Pilz@bea.com>
- CC: Doug Davis <dug@us.ibm.com>, wsrx <ws-rx@lists.oasis-open.org>, public-ws-addressing@w3.org
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 Wednesday, 28 February 2007 23:19:45 UTC