Chris nails it…

I assume you'd agree that a pub/sub application needs to be dependent on pub/sub semantics, right? e.g. a SOAP developer using WS-Notification would need to be aware of those semantics when subscribing or publishing, right? Well, suppose we created a thing which included SOAP, these application semantics, and the WS-Addressing headers. In Internet-land, that would be called an application protocol and you'd expect applications to be dependent upon it. Tell me how that differs from an application depending upon HTTP?

I respectfully suggest that you're getting stuck on HTTP (and SMTP, and ..) being called a "protocol", since your mental model of a protocol can't accomodate them having operations. According to your mental model (hey, I recognize it - I used to have the same one!) they end just below that, ala IIOP. That's why "protocol independence" makes complete sense to you, yet the exact opposite to me! One word, multiple meanings.

But we agree on the architectural style! Standardized identifiers - EPRs or URIs, take your pick. Standardized uniform semantics - GET/POST or Subscribe/Publish, take your pick. etc...

This is an off-the-cuff response, and I have been drinking beer this evening...

I don't have a mental problem accomodating a protocol that has operations. I think I've been involved in my fair share of protocols that have operations.

I think a difference in our viewpoints is that I don't generally think of SOAP as being an HTTP application. Or an SMTP application. Or a POP3 application.

When I happen to send a SOAP message over HTTP, I use POST. And I put an appropriate request URI and Host header in the right place in the HTTP request. But the request URI/Host header don't necessarily match the value of the wsa:To header. I'm not sure why this is construed as an abuse of HTTP. I'm not sure why HTTP cares about the value of the wsa:To header. But you seem to be telling me it does. Or that you do...