WoT Working Group Charter - Concrete Protocol Bindings

Dear WoT IG/WG,

It was great to meet many of you in person at the WoT Workshop this week.

I’ve been asked to provide a first draft of a sentence for a renewed
Working Group Charter to address the issue of concrete protocol bindings
vs. declarative protocol bindings.

tl;dr: Here it is:

*“Define a mechanism such that Things may share a predefined standard
API/sub-protocol over HTTP/WebSockets for their full set of operations,
rather than require each Thing to self-describe an API in its Thing
Description.”*


For some context, Mozilla’s original feedback on the current WoT Working
Group Charter was that a more focused and prescriptive approach, along the
lines of the Web Thing Model member submission (and now Mozilla’s Web Thing
API proposal), with a standardised REST & WebSockets API, could be a better
basis for a Web of Things. The advantage of that approach is that it would
enable ad-hoc interoperability, such that any WoT client would be able to
talk to any WoT device and would make possible an ecosystem of apps and
services built on a common API. The disadvantage is that it would require
the use of gateways to bridge existing IoT APIs and protocols to this
standard WoT application layer.

At the time the new Working Group instead chose to take the less
prescriptive approach of creating a Thing Description specification which
acts more like an interface description language, in describing a range of
existing APIs and protocols, rather than creating a new one. The benefit of
that approach is that it can be retrofitted to describe existing devices
and services. The disadvantage is that it makes ad-hoc interoperability
more difficult because WoT clients have to deal with an unconstrained
number of protocols and content types and are expected to adapt to custom
APIs at runtime. In practice this means that any given WoT client can only
communicate with a subset of potential WoT devices.

The above proposed section of a new Working Group Charter is an attempt to
redress that balance a little by providing a mechanism such that web thing
developers can choose to use a predefined standard API/protocol if they
want to, rather than requiring each web thing to self-describe an API in
its Thing Description. This will not guarantee full interoperability across
the Web of Things, but could provide a happy path for greenfield IoT
implementations.

There has already been some work along these lines in the Thing Description
specification in the form of some basic defaults for an HTTP protocol
binding. Several potential broader solutions have been proposed for this
problem so the above wording does not prescribe a particular solution.

I am of course hoping for feedback so that we can get the wording right.

Thanks

Ben