Re: New Alternative G to resolve LC comment on WS addr metadata

<snip />

> 2) wsa:Addressing assertion (by itself) is stated as having no 
> restriction on the endpoint (wrt anon/non-anon). This could be 
> interpreted to mean that the endpoint is claiming to accept both anon as 

> well as non-anon replyTos. Perhaps that is not intended, but I like the 
> model where no nested assertion means no claim is made about the 
> accepted values.
> 
> Section 3.1.1 says:
> "The wsam:Addressing assertion does not indicate any restrictions on the 

> use of WS-Addressing unless otherwise qualified by assertions in its 
> nested policy expression."
> 
> Suggestion -- add this:
> "In the absence of a nested policy expression, no claim is made about 
> requirement or acceptance of either the anonymous or non-anonymous URI 
> as the value of the [address] property contained in the response EPR of 
> the request message."
> 
> (or something like that).

But then how do you indicate positive support/requirement of the split 
response
usecase? I though the ability to support the split response usecase was 
based
on the former interpretation not the latter.
David

> -Anish
> --
> 
> 
> Marc Goodner wrote:
> > I agree with Tom that nested expressions is the way we should go to 
> > resolve this issue. We?ve been working on a slightly different variant 

> > to handle this that is attached.
> > 
> > 
> > 
> > It proposes the following changes:
> > 1.        States that the Addressing assertion applies to the endpoint 

> > subject
> > 2.        Prohibits abstract (interface/portType) attachment points
> > 3.        The Addressing assertion without any qualifiers (nested 
> > assertions) means that the use of WS-Addressing is required and has no 

> > restrictions.
> > 4.        The AnonymousResponses and NonAnonymousResponses assertions 
> > indicate that anonymous or non-anonymous responses respectfully are 
> > required.
> > 5.        The AnonymousResponses and NonAnonymousResponses assertions 
> > cannot be used in the same alternative.  There semantics conflict with 

> > each other.
> > 6.        Removes wsp:Ignorable example
> > 7.        Editorial work to clean up the examples to be consistent 
with 
> > the assertion semantics.
> > 
> > This proposal has the following benefits
> > 
> > ·         The simplest case (addressing is required and may be used 
> > without restrictions) is represented by just the Addressing assertion
> > 
> > ·         The assertions express requirements as suggested by the 
> > WS-Policy WG
> > 
> > ·         An endpoint can clearly indicate what response are and are 
not 
> > allowed
> > 
> > ·         No new assertions added.  A subject that requires mixed-mode 

> > responses can use the Addressing assertion with no qualifiers
> > 
> > ·         Authoring policies that work with Intersection is 
> > straight-forward to do
> > 
> > ·         The assertions compose well with other assertions that 
depend 
> > on addressing (ex. MakeConnection would be used in conjunction the 
> > Addressing assertion qualified by the NonAnonymousResponses assertion)
> > 
> > 
> > 
> 






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

Received on Monday, 2 April 2007 19:59:52 UTC