W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2006

RE: Proposal for WS-Policy assertions

From: Gilbert Pilz <Gilbert.Pilz@bea.com>
Date: Thu, 9 Nov 2006 09:44:13 -0800
Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C029FA3A1@repbex01.amer.bea.com>
To: "David Hull" <dmh@tibco.com>, "Marc Hadley" <Marc.Hadley@Sun.COM>
Cc: <public-ws-addressing@w3.org>
W/regards to extending NonAnonymousReplies I think we need to be careful.
I'm concerned about how the extensions would play out in nested WS-Policy
assertions. I welcome anyone who knows more about nested policy assertions
than I do (fairly low bar here) to comment.
- gp


From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
Sent: Wednesday, November 08, 2006 8:37 PM
To: Marc Hadley
Cc: public-ws-addressing@w3.org List
Subject: Re: Proposal for WS-Policy assertions

This looks pretty good.  In particular (unless I missed something) it ought
to lay CR33 well and truly to rest.  A couple of questions:

*	Do we mean "replies" or "responses"?  That is, does the policy apply
to [reply endpoint] or to it and [fault endpoint] collectively.  If the
latter, is there any need to slice more finely ("This is OK for replies but
not for faults")?  I don't see an obvious use case, but it seems worth
asking.  If it applies to both, I would recommend changing the name to
reflect that.

*	I'm not greatly bothered if we don't define a means of saying "I can
send replies via email" and such as long as there's clearly room to do so.
I can see at least two with the proposed scheme: 

1.	Allow an {any} extension point for children of NonAnonymousReplies,
so you could say something like <wsaw:NonAnonymousReplies> ... something
that means "email spoken here" ... </wsaw:NonAnonymousReplies>.  The
wsfoo:clause mentioned below might slot in here, too.

2.	Follow the example below for wsfoo: and just define a new clause for
"email spoken here". 

Do you (or does anyone else) have a preference or other possibility?  I'm
not sure which I prefer.  The idea behind (1) is to group all the assertions
about non-anon replies together.  A client that was only interested in anon,
for example, could then just look for the anon marker and know it could
safely ignore anything under non-anon, while it could not safely ignore
other assertions that were siblings to anon/non-anon.

Marc Hadley wrote: 

Gilbert and I took an action to propose some assertions for declaring
WS-Addr requirements/capabilities in WS-Policy. After a bit of discussion we
came up with the following three assertions: 

(i) <wsaw:AddressingRequired/> - the endpoint requires WS-Addressing,
optionality can be conveyed using WS-Policy constructs. 

(ii) <wsaw:AnonymousReplies/> - the endpoint can send replies using WS-A
anonymous; the endpoint can't send to anon if not present. 

(iii) <wsaw:NonAnonymousReplies/> - the endpoint can send replies using
other addresses; the endpoint can't send to other addresses if not present
(unless some other assertion adds a class of supported addresses). 

Assertion (iii) is deliberately vague, its presence means that a non-anon
address might work but doesn't constrain what such an address might look
like - a receiver can still reject an address that it doesn't grok or that
requires a binding it doesn't support. The WG decided against specifying
things like available response bindings so I think this is in line with that

Here are some examples: 


Means that addressing is required and only anonymous replies are 


Means that addressing is required and only non-anonymous replies are 


Means that addressing is required and both anonymous and non-anonymous 
replies are supported. 


Wouldn't be too useful for anything other than a one-way message since
neither anonymous nor non-anonymouse replies are supported. 


Means that addressing is required and that anon replies as defined by
WS-Addr or WS-Foo are supported. 


Marc Hadley <marc.hadley at sun.com> 
CTO Office, Sun Microsystems. 

Received on Thursday, 9 November 2006 17:46:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:15 UTC