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

I prefer alternative G to alternative F, as I don't like alternative F's 
requirement that absence of nested assertion means replies are not allowed.

I do have 2 comments on proposal G:

1) The proposal has the following restriction --
"A policy expression containing the wsam:Addressing policy assertion 
MUST NOT be attached to a wsdl:portType or wsdl20:interface. The 
wsam:Addressing policy assertion specifies a concrete behavior whereas 
the wsdl:portType or wsdl20:interface is an abstract construct."

How/why does the wsam:Addressing specify a concrete behavior? We have 
core and soap-binding spec. The proposal does not make it clear (I hope 
I didn't miss it) as to compliance to which spec is made by the 
assertion. We should spell that out.

For example, what happens when the assertion is made on an endpoint that 
does not use SOAP. I imagine that the conformance to only the core spec 
is made (and not to some additional WS-Addressing binding that may have 
been defined for the protocol that is being used).

What happens when the assertion applies to an endpoint that uses SOAP, 
is the claim about conformance to core+SOAP-binding or just core?

Furthermore, WS-Addressing Core is an abstract spec. It would be very 
useful to make an assertion on the portType/interface to say that all 
bindings/endpoint for this portType/interface must use ws-addressing 
(because the abstract contract depends on the MAP values). This is 
especially true if one views ws-addressing as a bidning-independent 
"core" spec on which applications and abstract contracts will have 
dependencies.

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

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

Received on Monday, 2 April 2007 19:53:07 UTC