- 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>
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:45 UTC