RE : RE : WS-Addressing

Jacques,
You seem to be mixing programming model issues with issues of the underlying runtime.
This is correct, but I am not sure I want to apologize since these are in fact intertwined in real life  :-)

What client programming model are you using in this situation?
JAX-WS

However, I don't think the shortcomings in the client programming model should be a reason to make the SOAP/JMS spec more than it is intended to be... that would confuse the issues more than it would clarify them, in my opinion.    I'm sure my SOAP/JMS WG colleagues will correct me if I'm wrong, but my opinion of the SOAP/JMS spec is that it is mostly intended to guide web service runtime vendors to enable them to provide a runtime that can interoperate with other runtimes when exchanging SOAP messages over JMS.       It does not, however, touch on the client programming model nor is it intended to.
Considering that JMS does not interoperate between vendors (no protocol), SOAPonJMS will not interoperate either.
So IMHO, the WG work should also care about facilitating / enabling portability of the user code, even if I understand that APIs (such as JAX-WS) are not directly a WG issue.
Whatever the WG recommend, even if non normative, can be used as an indication to the toolkit implementors and would help avoiding the differences we are seeing to-day as soon as you get out of the beaen track (SOAP RPC on http), which plague developer's life and hamper WS-* rise to the Gartner plateau of productivity.
Then, in a future release of the spec, or in another W3C spec,  what is non normative could become normative when best practices will emerge.

My 2 cents
Jacques