Re: Corrected Proposed Alternative A for resolution of ws addr metadata LC comment

I see your point, but if there are two alternatives for the nested 
policy, either of them apply to
"any" of the resonse EPRs.  Thus two eprs in the same request could have 
values which
obey any of the policy alternatives.

Tom

Katy Warr wrote:
>
> Tom,
>
> This sentence implies a requirement on the request message:
>
> "The appearance of this element within a policy alternative indicates 
> that the
> subject requires any request message that has responses to include 
> response
> endpoint EPRs that contain the anonymous URI
> ("http://www.w3.org/2005/08/addressing/anonymous") as the value of 
> [address]."
>
> Whereas, this sentence implies that the requirement is scoped to the 
> response message:
>
> "In other words, the subject requires that response instances are sent 
> using the
> anonymous URI."
>
> I personally think that explaining the requirement in terms of what is 
> required by the client request message is preferable because the whole 
> point of this service policy is for client<->service policy 
> negotiations. The client needs to narrow the available service 
> policies to a single alternative prior to sending the request.  
>
> If we agreed that nested policies apply to client requests (rather 
> than responses), we can still fix the problem of  mixing replyTo-anon 
> and faultTo=nonAnon.  As the proposal stands, 
> AnonymousResponse/NonAnonymousResponse contradict each other so cannot 
> exist together within a single alternative. This could be fixed by:
> 1) adding a 3rd nested assertion indicating that the request message 
> must contain differing values for replyTo and faultTo (one anon, the 
> other non-anon).  Eg 'AnonymousAndNonAnonymousResponses'.  This has 
> the benefit of allowing service providers to omit this assertion if 
> they were unable to support this more complex mixed-response type 
> scenario.  
> 2) alternatively, we could revert back to specifying support rather 
> than requirement thus allowing the nested assertions to co-exist 
> within a single alternative.  This has the benefit that it makes the 
> nested assertions composable, but it goes against the direction 
> indicated by the wsp team.
>
> thanks,
> Katy
>
>
>
> *Tom Rutt <tom@coastin.com>*
> Sent by: public-ws-addressing-request@w3.org
>
> 04/03/2007 22:20
> Please respond to
> tom@coastin.com
>
>
> 	
> To
> 	Katy Warr/UK/IBM@IBMGB
> cc
> 	WS-Addressing <public-ws-addressing@w3.org>, ws policy 
> <public-ws-policy@w3.org>
> Subject
> 	Re: Corrected Proposed Alternative A for resolution of ws addr 
>  metadata LC   comment
>
>
>
> 	
>
>
>
>
>
>
> Well that case can still be handled by having two or more nested
> alternatitves.
>
>
> Remember the alternatives are for responses not requests.  Each reply to
> and fault to
> is a separate response.
>
> However, I still in more in favor of alternative D) to delete the nested
> policy assertions
> for Addressing assertion
>
>
> Tom
>
> Katy Warr wrote:
> >
> > Tom
> > We have discussed scenarios in previous wsa meetings where a client
> > may need to mix anon/non-anon on a single request:
> > - e.g.  replyTo=anon, faultTo=nonAnon
> > As wsam:AnonymousResponses and wsam:NonAnonymousResponses are
> > contradictory requirements, there does not appear to be a way for a
> > service indicate that it could accept this combination on a single
> > request (as these assertions specify a single hard requirement which
> > applies to both replyTo and faultTo).
> > regards,
> > Katy
> >
> >
> >
> > *Tom Rutt <tom@coastin.com>*
> > Sent by: public-ws-policy-request@w3.org
> >
> > 02/03/2007 20:36
> > Please respond to
> > tom@coastin.com
> >
> >
> >                  
> > To
> >                  WS-Addressing <public-ws-addressing@w3.org>, ws policy
> > <public-ws-policy@w3.org>
> > cc
> >                  
> > Subject
> >                  Corrected Proposed Alternative A for resolution of 
> ws addr metadata
> > LC  comment
> >
> >
> >
> >                  
> >
> >
> >
> >
> >
> > I never posted a complete change proposal for Alternative A (which
> > defines the nested assertions of Addressing assertion as requirements,
> > with absence implying Prohibition.
> >
> > I post this for completeness.
> >
> > --
> > ----------------------------------------------------
> > Tom Rutt                 email: tom@coastin.com; trutt@us.fujitsu.com
> > Tel: +1 732 801 5744          Fax: +1 732 774 5133
> >
> >
> > [attachment "ws-AddrMetadataPolicyEdits-altA.pdf" deleted by Katy
> > Warr/UK/IBM]
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU/
> >
> >
> >
> >
> >
> >
>
> -- 
> ----------------------------------------------------
> Tom Rutt                 email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU/
>
>
>
>
>
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Monday, 5 March 2007 17:14:47 UTC