but... REST is like a protocol isn't it?

Came across one of Roy Fielding's blog posts while researching the latest on how to build REST services/clients and read this:

REST is an architectural style, not a protocol

 So, I get what he's saying... REST doesn't depend on HTTP 1.1 per se, it's a conceptual framework. but REST the conceptual framework itself behaves like a protocol in some key aspects, doesn't it?:

• REST takes a unlimited space of interaction and constrains it to a handful of verbs.
• As you walk up the OSI stack, 'verbs' start out very constrained and then expand to anything possible (i.e. compare the number of verbs at the data link layer with verbs expressible in the application layer.)  By this metric (number of verbs), REST feels "lower" than an Application-layer framework.

The argument isn't about lack of verbs... the datalink layer in OSI is fully capable of transmitting any possible state over the wire.  The question is whether Applications consume that representation directly or by conversion to higher-level construct.

• Applications often "tunnel" their true data and method expressions through REST, like a protocol.  Hence client and server code often (always?) has to box/unbox its application-level semantics from the 'lower level' REST semantics including:
• exception handling
• instance vs. collection
• query vs. control

If so, then REST needs to clearly define how objects at the layer above are framed over a RESTful transport. Restful Objects is one such attempt that is gaining a little traction in that area, but it feels very complex.

In fact, I was in the process of considering writing a Ruby implementation of that spec, when it struck me that the complexity of Restful Objects isn't about the native POJO objects and interactions, it's about boxing/unboxing them into and from the REST layer... 

Well in that context, REST sure smells like a protocol, doesn't it?