Davy Brion and Jef Claes were discussing whether or not you can have REST without HTTP. Is this another peanut butter and chocolate thing? I think it's hard to extract REST from HTTP because that is how it is defined. I mean quite literally how it is defined in Fielding's dissertation. REST, the term, is short for "representational state transfer" but it still specifically describes an architectural style of representing state transfer via the HTTP specification.
But what if we didn't let such a little thing like semantics get in our way here and only took REST for it's literal name definition and not as the specification laid out in Fielding's dissertation? What if REST only meant a representation of state transfers? I'm not much of a protocol geek so I couldn't tell you if other protocols would work well for this, but in this respect I suppose it is theoretically possible to "represent state transfers" using something other than HTTP. I mean why not? The problem is HTTP is arguably quite good for this. In fact, that is the core premise of Fielding's dissertation. HTTP describes "resources" which represent a current state, and provides a standard set of operations (verbs) which can be used to transfer between one state and the next. The request/response style around these operations makes it easy to know which state we are in and HATEOS gives us a convenient way to communicate to clients what state transfers are available to them next.
I think that any attempt to use another protocol for this would result in a more confused architecture. However arguably even HTTP-REST can be confusing. The number of poor REST API implementations out there (my own included) greatly outnumber the examples we have of by-the-book implementations.
In the end I think that the concept of representing a system via an easily understood state transfer mechanism is a strong architectural principle, however I'd generally hope that in time we will develop better, or at least clearer, ways (protocols?) for applying it than HTTP.
my $0.02