- From: Tom Rutt <tom@coastin.com>
- Date: Wed, 28 Feb 2007 20:25:10 -0500
- To: tom@coastin.com
- CC: Doug Davis <dug@us.ibm.com>, Gilbert Pilz <Gilbert.Pilz@bea.com>, public-ws-addressing@w3.org, ws policy <public-ws-policy@w3.org>, public-ws-policy-request@w3.org, wsrx <ws-rx@lists.oasis-open.org>
By the way, the proposal should state "absense on nonAnonReplies within an addressing assertion means nonAnonReplies are prohibited" If it says otherwise that is a typo. Tom Rutt wrote: > > > > Doug Davis wrote: >> >> Tom, >> What does it mean if neither wsam:Anon nor wsam:nonAnon appear under >> a wsam:Addressing element? > That means no replies are allowed. > > One ways only with no response >> In your proposal you say the absence of wsam:Anon means it Anon can't >> be used. >> In your proposal you say the absence of wsam:nonAnon means Anon must >> be used. >> So we have contradictory statements when neither appear, no? >> >> thanks >> -Doug >> ______________________________________________________ >> STSM | Web Services Architect | IBM Software Group >> (919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com >> >> >> *Tom Rutt <tom@coastin.com>* >> Sent by: public-ws-policy-request@w3.org >> >> 02/28/2007 07:18 PM >> Please respond to >> tom@coastin.com >> >> >> >> 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> >> 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 >> >> >> >> > -- ---------------------------------------------------- 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 01:25:53 UTC