Waka: Paddling a new canoe
As I mentioned in a earlier post Roy Fielding has started a ASF Lab for Web Architecture that is intended to be a place to work on documentation regarding Web Architecture. This includes existing protocol improvements and Waka a new HTTP upgrade. Waka is still in the head of Roy Fielding and the changes have been eluded to over eight years in various ApacheCon presentations; in various Apache 2.0 design notes and emails focused mostly around the IO-layer and request-response processing chains in Apache 2.0; emails to rest-discuss and references to various draft RFC and previous HTTP next generation efforts - rHTTP, W3C’s HTTP-NG and Spero’s HTTP-ng.
From a podcast with Jon Udell, Roy describes Waka thus.
Waka is a binary token based replacement protocol for HTTP. The goal is to create a language independent mechanism for exchanging data oriented messages using the ReST architectural style - the principals and design.
An application protocol that is efficient as any custom protocol yet generally applicable like HTTP. The difference is that we get rid of HTTP syntax, make it possible to interleave meta-data and data in independent streams/frames. Doing this in a way that is efficient as possible without being entirely generic i.e. Waka is not attempting to replace TCP. This means Waka would be suitable to application integration inside the firewall and well as outside.
Why name it Waka? Waka is the Aotearoa (New Zealand) Māori name for Canoe still used for ceremonial purposes. It is one of the few four-letter words suitable for a protocol name. And Roy is part Māori.
From the last substantial presentation Roy gave about Waka the following can be gleaned.
Deployment
Deployable within an HTTP connection via the HTTP/1.1 Upgrade header field with a defined mapping to HTTP/1.1 proxies.
Syntax
A uniform syntax regardless of the message type and direction that also allows for padding for 32/64 bit alignment. There is a discussion in Chapter 6 of Roy’s dissertation covering uniform syntax and numerous discussions about the short-comings of layered encodings and MIME.
Messages are self-descriptive using explicit typing for message structure and fields. An indication of mandate and scope of the fields.
Association of meta-data to control, resource and representation. Allows for Premature termination of request or response.
To be more efficient the protocol will use tokens for all standard elements where a URI reference can be used in place of any token. Macros (client-defined syntax short-hand) can be established per connection. Meta-data delivery can be interleaved with data.
New Request Semantics
RENDER: display/print/speak this representation.
MONITOR: set up a subscription to be notified of resource state changes. Notification are sent to a resource specified as part of the request. Another name commonly used for these semantics is WATCH.
Authoring Method: DAV simplified and by that I would assume removal of the DAV property methods. Elimination of non-resource identifiers and reintroduction of PATCH.
Request control data: request identifier to support request pipelining removing the head-of-line bottleneck in HTTP. A Transaction identifier, a URI, meaning transactions can be treated as resources. And relative priority - relative to requests in a connections pipeline.
New Response Semantics
Self-descriptive binding to the request by echoing the request id, method and target URI. This basically enables an asynchronous transport.
Cache key explicitly described; caches no longer need to save request fields or guess about Vary information.
Unsolicited Responses for cache invalidation messages and multicast event notices.
Written by =Robert Digg this1 Comment so far
Leave a reply

Great write-up.
In March 2007, I asked Roy specifically how waka will solve the head-of-line blocking problem, and he answered:
“By including the entire request line and cache key in every response. A waka client can actually broadcast a request and receive responses from multiple servers (when appropriate).”