I spent some time last weekend playing with BEA's WebLogic Server 9.0 to test WS-RM interoperability with Indigo. One problem I encountered was the fact that when presented with a WSDL generated by a BEA endpoint, Indigo's SvcUtil.exe generates a .config file with the mapAddressingHeadersToHttpHeaders attribute set to true on the httpTransport element. What this means is that all WS-Addressing headers (headers such as Action, To, From, MessageID, and ReplyTo) get stripped from the message and some (such as the Action header) get moved to the header on the HTTP request. This setting should only be on in the case Indigo is talking to a "V1" web service - a web service that doesn't support WS-Addressing. However, this wasn't the case with my BEA endpoint so this conversion was clearly incorrect.
It turns out there currently isn't an official policy assertion that indicates an endpoint's support for WS-Addressing. In Beta 1, Indigo simply uses the presence of a wsa:EndpointReference element inside the wsdl:port element to determine this. If it doesn't find one (which is the case with the BEA WSDL and nearly every other non-MS WSDL out there at this point) it will assume WS-Addressing is not supported and generate a client proxy that will have the previously mentioned setting set to true. Interestingly enough, this will happen even if the endpoint's policy declares a requirement for WS-RM (through the RMAssertion policy assertion) and SvcUtil.exe generates a WS-RM enabled client proxy (WS-RM requires support for WS-Addressing). The only thing a user can do at this point is manually update the generated .config file and explicitly set the setting to false.
The good news is there is currently an official proposal in the works that will make determining support for WS-Addressing a standard.