Jeffrey Schlimmer gives some thoughts and a mnemonic on MEPs in MEP: Metadata Explains (Message) Properties. I have 2 problems with what Jeff describes.
Firstly, I agree with him that an MEP is independent of underlying protocols - he describes this as a transport but HTTP isn't always a transport protocol. But he misses the 4th case of the simple/complex mep and simple/complex underlying protocol: in the case of complex protocol/complex mep, a rich protocol is typically dumbed down to provide the minimum one-way mep. I wrote about this in depth in Underlying Protocol is a completely leaky abstraction. For example, some folks really want to design applications so that a WSDL one-way operation deployed over HTTP can't ever report an error over the HTTP response, despite the fact that WSDL robust-in-only and SOAP itself are designed for this.
Secondly, he misses a crucial point about intermediaries and MEPs. How does a protocol intermediary know whether a request message is part of a one-way or request-response mep? How long should an HTTP intermediary keep the connection open waiting for a response? If it's request-response over HTTP, then it has to keep it open. If it's one-way over HTTP, then it can close it after sending the message onwards. If you say "look at the ReplyTo" or "look at the Action" then you mean an HTTP intermediary has to be WS-Addressing aware to perform properly. But we actually know that WS-A ReplyTo doesn't fully describe the MEP. And we probably don't want every HTTP intermediary to have the mep metadata for each distinct Action/URI combination for a domain.
Then there's composability problems. WS-ReliableMessaging allows an acksTo=anonymous, which means use the HTTP connection. This can be combined with a one-way MEP. So the HTTP intermediary has to know about ws-a AND ws-reliablemessaging AND the next spec.
Now it can be argued that an ws-rm "reply" is different than an app level "response", but the http intermediary still would like to know whether something is: a) never coming back; b) possibly coming back; c) always coming back.
As it stands, intermediaries such as load balancers and dispatchers can have a tough time without messages being self-describing wrt meps and the http response.