New Proposed Alternative D to resolve WS addr metadata LC comment

while changing the examples for both proposals A and C I noticed a 
troublesome aspect
of the nested addressing assertions with respect to the default 
intersection algorithm..

In either alternative C, where absence of a nested assertion means 
nothing, it
seems troublesome that an addressing assertion with no nested policy 
alternatives:

<wsp:Policy>
    <wsam:Addressing>
        <wsp:Policy/>
    </wsam:Addressing>
</wsp:Policy>
 
has a null intersection with one that has no empty nested alternative (e.g
<wsp:Policy>
    <wsam:Addressing>
        <wsp:Policy>
            <wsp:ExactlyOne>
                <wsam:AnonymousResponses/>
                <wsam:NonAnonymousResponses/>
            </wsp:ExactlyOne>
        </wsp:Policy>
    </wsam:Addressing>
</wsp:Policy>

This intersection outcome makes a little more sense with Proposed 
alternative A (where absence implies prohibition), but I am not sure why 
anyone would every want to prohibit both kinds of response.  Thus the 
example with no nested assertions seems useless for if Proposed 
alternative A is accepted.   In fact, another problem with Proposed 
option A is that there seems to be no difference in an alternative with 
AnonymousResponses absent and one with NonAnonymousResponses present!

If a response sender is not behind a firewall, then it is of little 
value to be able to signal
a requirement for either non anon or Anon Replies, since the cost of 
supporting both is small.
such a response sender would most lkely always have both alternatives in 
their nested Addressing assertion.

The more typical case is the response receiver is behind a firewall.   
It can indicate the need for anonymous responses by only including 
anonymous URI in its response EPRs.  It does not need a policy for this.  

However we have defined these nested assertions as being attached to the 
response sender.  I am having trouble coming up with realistic use cases 
for a response sender needing to assert requirments on the types of 
response EPRs the request sender must use.

After thinking how to resolve the difficulties cited above for either 
Alternative A or C, I came up with a sudden realization for a new 
alternative proposal D.

Alternative proposal D is to simply delete sections 3.2.1 thru 3.1.5.

That is, do not define any nested policy assertions for the Addressing 
assertion.


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

Received on Friday, 2 March 2007 21:40:43 UTC