- From: David Hull <dmh@tibco.com>
- Date: Tue, 31 Oct 2006 12:11:41 -0500
- To: Doug Davis <dug@us.ibm.com>
- Cc: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
- Message-id: <454783CD.1070307@tibco.com>
> For #1 we still have a problem because how does can endpoint advertise > that > it only supports WSA Anon and WS-Foo Anon? wsaw:Anon=required won't > allow > WS-Foo's anon, and wsaw:Anon=optional doesn't give the semantics we > want. By that I mean, wsaw:Anon=optional doesn't tell anyone that > www.cnn.com is not allowed. I agree that's a hole in the current WSDL binding -- it's exactly what AddressConstraint is aimed at. But that's a separate issue from CR33. Contrary to the statement of CR33, the current text does /not/ preclude another spec from ever extending WSA to define their own anon URI. The markers wsaw:Anon=optional and wsaw:Anon=prohibited are silent about what other address URI may or may not be allowed -- regardless of whether such URI happen to use a "back-channel". If the WSDL contains wsaw:Anon={optional,prohibited}/and/ (say) wsrm:Anon="optional", then the client knows that RM anon is allowed, and it knows whether or not WSA anon is allowed. It doesn't know whether http://www.cnn.com is allowed, but that's a separate problem. As an aside, wsaw:Anon=prohibited together with wsrm:Anon=optional might seem unlikely, but it could probably be used to require RM even in the anonymous case. In short, a case can be made for closing CR33 with no action, and then going on to wrangle over questions like: * Should we try to fill the hole about cnn.com (i.e., should we define a way of saying what's allowed /besides /anon and none)? * Should we try to make our WSDL markers more policy-friendly? * Should we try to define some general marker describing a "backchannel" or "new connection" or some other form of "sync" vs. "async" distinction? Much of the reason we haven't closed CR33, IMHO, is because we are simultaneously trying to discuss these three other issues, which are proving much more contentious (except the second, which seems to have fairly general support).
Received on Tuesday, 31 October 2006 17:12:14 UTC