Clarifying the scope and motivation for binding templates

[draggett]

An important point is to clarify in our published report whether we are defining a general means to describe existing protocol usage, e.g. current devices and IoT standards, or we are prescribing how to use IoT protocols in a way that maps to the abstract interaction model for the web of things. I suspect we are trying to do both, which could be very confusing to readers.

A further consideration is that in general, a fully declarative description of protocol usage is going to be very challenging as there is so much freedom in how applications layer on top of the underlying protocols. We should acknowledge that and make it clear that that isn’t our objective. Rather, we plan to focus on specific IoT standards suites that prescribe how to use the underlying protocols.

Our work also allows for applications that produce things to handle the IoT device protocols themselves. This is the approach that Benjamin Francis (Mozilla) and I have followed in our respective NodeJS implementations. Applications installed on a home gateway act as producers and consumers of things. Such applications can also act as suppliers of things to cloud based application servers as a basis to provide access to applications running on platforms external to the home firewall. Producer applications on the home gateway can make use of platform specific networking modules to work with specific devices, e.g. those for Apple Home Kit, and Android Things, as well as Bluetooth and Zigbee based devices.

This shows that standards for binding templates is a nice to have feature, rather than being required. So we need to acknowledge that and clearly show the benefits of binding templates. A clear priority should be prescriptive protocol binding between application platforms and platforms for user interfaces such as web browsers and native apps on smart phones. For me at least, this means we should give a high priority to Web protocols like HTTP and WebSockets.

[zolkis]

If we do have an application platform, then in my understanding the binding templates are actually needed.

Of course, a black box with a TD and WoT interface is possible, but I was under the impression we are trying to make it easier to make those black boxes by standardizing a WoT application platform.

If apps handle the protocols themselves, and if they are not black boxes, then there is an interface between apps and protocols that need to be described in WoT, in order to be able to make WoT interactions, but you just made the point that such generic interface should not be in scope (and I agree).

To summarize,

1. a WoT device can be a black box that present a TD and a WoT interface and encapsulate all protocol handling (provisioning, security, configuration is out of scope as well).
2. the black box is broken into apps and app platform, with a narrow scope protocol support as interface. This makes the apps reusable from platform to platform.
3. the black box is broken into apps, a WoT app platform, and protocol bindings to lower level platform, saying e.g. "if you already support CoAP, here is how you can support WoT". This makes the apps, and the WoT servient stack reusable from platform to platform.

I think all the above may have deployment examples. You are right the Binding Templates doc should make clear it addresses option 3. from above.

However, where do we describe what is the scope of option 2.? i.e. how apps are going to use which protocols so that it's WoT compliant (define that, too).

For having a cleaner pile of tasks ahead, I suggest:

• we (as WoT WG) focus on option 3, including the Binding Templates deliverable,
• leave option 1 optional (just read the architecture doc, implement the TD and you're good), and
• leave option 2 out of scope for now, or describe it shortly in the architecture doc.

[draggett]

To enable open markets of applications, I think the priority should be on web protocol usage between application platforms, including web browsers and native apps. App platforms could provide libraries that simplify support for Home Kit, Android Things, Bluetooth etc. The WoT WG should focus on standards for the business opportunities for applications that produce and consume things.

[zolkis]

Web protocol usage (standardized in WoT WG) is definitely the goal, but we can do it in the 3 ways mentioned before. So which way are we doing it?

The WoT WG should focus on standards for the business opportunities for applications that produce and consume things.

"Standards for the business opportunities for applications" makes no practical sense to me, it's too abstract, we need to clarify on that.

[draggett]

Essentially, we already have standards for the IoT protocols together with platform libraries such as node-coap that simplify using them. Further simplifying this won't have much of a business impact. By contrast, we lack standards for applications to produce and consume services, so that entrepreneur A can easily write a service that builds on top of the service provided by entrepreneur B, and which makes it easy to integrate devices whether these are using proprietary protocols or are standards compliant.

For every producer, we can expect multiple consumers, so we really need to focus on the protocols that support communication between application platforms including web browsers, home gateways and cloud based systems for cloud to cloud services. In other words, rather than focusing on OCF and oneM2M etc. we should be focusing on application developers.

[egekorkan]

I think after 2 years, this discussion is settled and the clear converge of this document is explaining how different protocols and payload formats can be described. Meanwhile, some of this discussion can be done in architecture. I would be thus closing this issue but feel free to reopen or open a new issue by concentrating on what is not clear at the moment.