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

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?

- 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
> 
> 
>