W3C home > Mailing lists > Public > public-ws-addressing@w3.org > April 2007

Re: Non-anon extensibility and policy intersection

From: Tom Rutt <tom@coastin.com>
Date: Mon, 23 Apr 2007 18:14:52 -0400
To: David Hull <dmh@tibco.com>
Cc: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-id: <462D2FDC.2050906@coastin.com>

This is similar to the use case expressed by anish:  (see below:

David Hull wrote:
> A while ago I suggested that we have a way of saying things like
> "non-anon response endpoints must be mailto: (or fit some other
> pattern)".  Our decision was to leave this out of scope, which is fine
> with me, but we want to be sure not to disallow it.
>
> Suppose I make an assertion, basically "the service support non-anon",
> generically.  Later, you want to refine that by saying, "Well, actually,
> the service only supports mailto: non-anon".  As I understand it, policy
> intersections are aimed at this sort of thing.
>
> However, if I intersect a policy that says "non-anon allowed" with one
> that says "mailto: only", I get the empty set, since the two assertions
> are different.  I would like to get "mailto: only".
>   
If you tread MailTo:only as a further constraint on the usage of NonAnon 
, you might be able to use the
same composition method as would be used with wsrm make connection.

I copy an earlier email on compostion with ws rm and its make connection

---
>
>   
Anish Karmarkar wrote:
 >
 > Below is the usecase that I mentioned on the call:
 >
 > The endpoint can only send messages on the 'back-channel' it will not
 > open a new connection to send messages (firewall does not allow it).
 > The endpoint also supports (but does not require) WSRM. What this
 > means is:
 >
 > 1) When wsrm is not used it requires the anon URI for responses.
 > 2) When wsrm is used, it requires the MC template (non-anon URI per
 > ws-addr) for responses.
 >
 > -Anish
 > --
 >
Response senders's Policy:
Policy.for.Anish.Use.case.using.Alterntative.G
......(explicit.support.claims,.empty.=.full support, nested assertion 
implies constraint)

<Policy>
...<ExactlyOne>
......<All>
.........<wsa:Addressing>...<--.Addressing.required,.Constrained to 
nonymous.responses.-->
............<Policy><wsa:AnonymousResponses./></Policy>
.........</wsa:Addressing>
......</All>
......<All>  <-- use addressing, nonAnon constrained with addiional 
requirment of Make Connection and use of RM )
.........<wsa:Addressing>..<--Addressing.required,.Constrained to 
NonAnon.Responses.-->
............<Policy><wsa:NonAnonymousResponses./></Policy>
.........</wsa:Addressing>
.........<wsrmp:RMAssertion.>..<--.RM.required.-->
............<wsp:Policy>.
...............<--..any.nested.policy.is.asserted.here.-->
............</wsp:Policy>.
.........</wsrmp:RMAssertion>
........<wsmc:MCSupported/>..<--.Make.Connection.URI.required.for.responses-->
......</All>
...</ExactlyOne>
</Policy>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133
Received on Monday, 23 April 2007 22:15:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:17 GMT