Kenny has a great writeup of how we rolled SOAP-free XML messaging into the WCF channel/encoder model.

The short answer is that we normalized POX messages into our model by defining a special MessageVersion -- MessageVersion.None -- that implies the absence of a SOAP envelope. This enables basic POX support in the channel model and removes the need for all that mucking about with the HttpMappingMode knob on the HttpTransportBindingElement (which, while modestly better than the MapAddressingHeadersToHttpHeaders="true" that we used to have in Beta 1, was quite bogus).

Up at the service model layer, the out-of-the-box way of doing POX messaging is by writing a Message/Message/* service, e.g.

[OperationContract( Action="*", ReplyAction="*" )]
public Message ProcessMessage( Message input ){ ... }

All of the underlying HTTP-ness is carried on the HttpRequestMessageProperty on the inbound message (which surfaces all the HTTP headers present on the incoming HTTP request). You can influence the HTTP response by adding an HttpResponseMessageProperty to the response message before you send it back down the stack.

If you want to get a bit fancier, you can levearge some of our dispatcher extensibility points to do things like dispatch locally to different methods based on the HTTP method (you'd implement System.ServiceModel.Dispatcher.IDispatchOperationSelector for this) or map name/value pairs carried in the query string into method parameters (via IDispatchMessageFormatter). We'll have plenty of sample code that shows how to do this in the SDK, too.

There's also an update for the RSS Toolkit in the works based on the July CTP. I'm hoping to get this up ASAP, but I'm pretty swamped with V.Next planning right now so I'm asking for just a little bit more patience :). As always, if you've got feedback send it on -- we'd love to hear it.