Re: WoT Working Group Charter - Concrete Protocol Bindings

References:

   - Mozilla's original
   <http://lists.w3.org/Archives/Public/www-archive/2016Oct/0004.html>
   feedback
   <https://lists.w3.org/Archives/Public/public-wot-ig/2016Oct/0025.html>
   - Web Thing Model
   <https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/> member
   submission
   - Mozilla's Web Thing API <https://iot.mozilla.org/wot/> proposal
   - W3C Thing Description HTTP Protocol Binding
   <https://w3c.github.io/wot-thing-description/#http-binding-assertions>


On Thu, 6 Jun 2019 at 13:08, Benjamin Francis <bfrancis@mozilla.com> wrote:

> 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
>