W3C home > Mailing lists > Public > public-ws-policy@w3.org > March 2007

New Proposed Alternative D to resolve WS addr metadata LC comment

From: Tom Rutt <tom@coastin.com>
Date: Fri, 02 Mar 2007 16:38:17 -0500
To: WS-Addressing <public-ws-addressing@w3.org>, ws policy <public-ws-policy@w3.org>
Message-id: <45E89949.6010606@coastin.com>

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 

has a null intersection with one that has no empty nested alternative (e.g

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 

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:27 UTC