Re: [ws-rx] I just posted a PR comment on MakeConnection Policy assertion

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:52 UTC