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

I didn't quite see it that way. Our nested assertions are not crafted to 
supported the split usecase. Some time ago we decided against the split 
usecase. If we change our mind, we need to provide explicit support for 
that. The current proposal G regardless of the interpretation of what it 
means to not have a nested assertion does not support the split usecase.

IIRC, Dave Hull had sent a proposal to support the split usecase.

-Anish
--

David Illsley wrote:
> <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 20:07:40 UTC