Is a binding template specification necessary?

[benfrancis]

What is the reason that an abstract template binding specification is necessary? Would it not be simpler to just create specification(s) with concrete bindings to the small number of web protocols that are needed?

For example:

• HTTP binding
• WebSocket binding (which extends the HTTP binding)
• CoAP binding (which is very similar to the HTTP binding but adds a pub/sub mechanism).

Note that MQTT is not a web protocol and therefore I see it as existing at a different level of abstraction to the Web of Things, requiring a gateway to bridge MQTT to a Web Thing protocol.

I understand there could be different serialisations to deal with like JSON and CBOR, but hopefully the number of those is small too. Formats which don't converge on a W3C standard serialisation (like SenML, OCF and LWM2M) could also be bridged to the W3C format using a gateway.

The reason I ask this is that trying to come up with an abstract specification which can be applied to any protocol (including non-web protocols) and any data format creates a huge amount of complexity which I'm not convinced is going to achieve the intended outcome.

I would argue that an abstract specification which can be applied to hundreds of combinations of protocols and data formats is not going to make ad-hoc interoperability possible. Interoperability will require converging on a very small set of web protocols and data formats, but with software which can bridge the Web of Things to other protocols. This is what has happened with the web of pages which has converged on HTTP and HTML, but can provide a layer of abstraction on top of services using other underlying protocols like SMTP, IRC, CalDAV etc.

[draggett]

I very much agree with #benfrancis that it would be easier to define a very small number of protocol bindings (just one would be sufficient) as this is all that we need for an open market of services on application platforms on the Internet. Other protocols can be interfaced to via application platforms that act as gateways, where the application that exposes a thing is also responsible for IoT protocol needed to access the sensor or actuator, e.g. Bluetooth, LoRa, SigFox, CoAP, ZigBee, enOcean, KNX, and so forth.

The sheer number of the IoT protocols, and the variation in how they work, makes it impractical to fully describe their use in a declarative machine interpretable way. Instead, I envisage application platforms evolving to provide easier to use APIs for access to the more common IoT protocols. NodeJS, for instance, has lots of modules for a broad range of protocols, along with a thriving community of developers.

We would have a much greater rate of commercial uptake if we were to focus on specifying just one protocol binding and showing how it can address a broad range of use cases in conjunction with the corresponding stakeholders. HTTP is great for accessing metadata (thing descriptions) and for authentication, but less so for bi-directional asynchronous messaging. Using HTTP for server-sent events addresses that weakness, but WebSockets is even better, and makes it straightforward to specific a message exchange protocol covering thing property updates, action requests and responses, and events, including updates to metadata.

We should be working on identifying the range of requirements for this message exchange protocol, for instance, the need to be able to send a sequence of property value updates as a single block for efficient streaming, e.g. for sensors that send thousands of readings a second. We would also need a means to address structured data, e.g. through a path syntax for addressing sub-properties or array indices. For me this stresses the critical importance of a thorough study of use cases and their requirements. This would make it easier to recruit new people and organizations to work on developing the corresponding standards.

[mkovatsc]

In the real world, we have several IoT protocols deployed, which cannot simply be ignored. Over the time we might see convergence. Yet for now the WG consensus has been to describe what is out there, and not prescribe how yet another platform could be built.

Furthermore, the WoT Binding Templates are there to define a common extension point, not a "abstract specification which can be applied to any protocol". The Binding Templates are an Informative Deliverable, as the extension point will become part of the TD, and the templates only show how it is used: Loading protocol-specific contexts that define the vocabulary (within the currently called form node).

Again, it is something anyone can opt out of.

It is highly likely that the http and coap vocabularies become part of the default TD context. WebSockets are not very useful in this context, as they are merely a transport protocol. They can only function as data pipe (which might be enough to push Event data structures). If you want more protocol features, you would need to define your flavor of WebSockets and provide a vocabulary for it; ideally you make your WebSocket-based protocol an RFC.

[benfrancis]

In the real world, we have several IoT protocols deployed, which cannot simply be ignored. Over the time we might see convergence. Yet for now the WG consensus has been to describe what is out there, and not prescribe how yet another platform could be built.

I don't understand this rationale. Describing all the different protocols that are used in IoT is not the same thing as defining a standard. I'm not suggesting that non-web IoT protocols should be ignored, but rather that non-web protocols are out of scope for the Web of Things and should be bridged with a gateway, rather than trying to shoehorn the same data model into all IoT protocols (and non-IP protocols), which IMO is completely infeasible.

Furthermore, the WoT Binding Templates are there to define a common extension point, not a "abstract specification which can be applied to any protocol". The Binding Templates are an Informative Deliverable, as the extension point will become part of the TD, and the templates only show how it is used: Loading protocol-specific contexts that define the vocabulary (within the currently called form node).

Again, it is something anyone can opt out of.

My point is that I think this activity is counter-productive for interoperability. Encouraging people to "embrace and extend" the same data model to be used across hundreds of different protocols does not help with converging on a standard Web of Things protocol. The Web of Things should instead use a very small set of data formats and web protocols and act as a layer of abstraction on top of non-web protocols.

[benfrancis]

WebSockets are not very useful in this context, as they are merely a transport protocol. They can only function as data pipe (which might be enough to push Event data structures). If you want more protocol features, you would need to define your flavor of WebSockets and provide a vocabulary for it; ideally you make your WebSocket-based protocol an RFC.

A webthing WebSocket sub-protocol would be a very useful thing to define, whether that happens at the W3C or elsewhere like the IETF. That could be built on top of or inspired by something existing like WAMP or MQTT, or something new which better fits the Web of Things data model of properties, actions and events.

[mkovatsc]

Describing all the different protocols that are used in IoT is not the same thing as defining a standard

Once upon a time also Dave was proclaiming that WoT is a standard for metadata, including communications metadata. This is what the WG is chartered for.

You might be aware that there were many ftp links in the early Web. We still have mailto. All this is very useful, as it takes time to converge. When you look around, you will find that "let's make another IoT alliance that everyone should use" does not help to this end.

A webthing WebSocket sub-protocol would be a very useful thing

Yes, as long as everyone understands that it is a new protocol that only builds on top of the WebSocket transport and needs a proper specification; the IETF would be the right place for this; the WoT WG is not chartered for this. Too many people do not understand that WebSockets are not an application layer protocol and they are defining a new protocol on top when sloppily defining meaning for the sent JSON structures.

[draggett]

In this case, I think W3C is a good venue for working on the use cases and requirements for the Web of things in respect to a message exchange protocol over Web Sockets. There is no demarcation agreement that the IETF does protocols whilst the W3C does data formats, and we can expect plenty of review from both organisations.

[benfrancis]

WoT is standard for metadata, including communications metadata.

Communications metadata for the web, yes. But how does communications metadata for existing non-web protocols have anything to do with the Web of Things?

You might be aware that there were many ftp links in the early Web. We still have mailto. All this is very useful, as it takes time to converge.

Just because web clients also provide functionality for ftp:// and mailto: hyperlinks doesn't make SMTP part of the web itself. The SeaMonkey client also supports newsgroups and IRC but they're not the web either.

When you look around, you will find that "let's make another IoT alliance that everyone should use" does not help to this end.

That is not the reaction we've seen in the developer community and the press this week in reaction to Mozilla's messaging around the Web of Things around our recent release. I understand XKCD standards wisdom, but people are crying out for a common standard application layer for IoT. The web is in a unique position to provide this, not by competing with existing protocols or trying to get them all to use the same data model, but by providing a common layer of abstraction on top of them and allowing those diverse underlying protocols to continue to exist and compete. If the web doesn't provide this, I think it's very likely we'll see IoT continue to be locked into incompatible commercial silos.

This is what the WG is chartered for.

The charter may well be the problem, and is definitely why Mozilla, and I suspect others, have not joined the Working Group. Formal objections from Mozilla and Google were not sufficiently addressed.

How long is it until the charter can be re-reviewed, within W3C process?

You may be right that the IETF may be a better home for at least some of this work.

I am personally very keen not to do anything to fragment Web of Things standardisation, but I worry we still haven't reached a common understanding between web companies and device makers on the basic definition of the Web of Things.

I suppose I'm proposing an alternative way forward, to apply the lessons learned from the World Wide Web to the Internet of Things, drastically reduce the scope of this effort, and aim to converge on a much smaller set of formats and protocols in the interests of interoperability.

[draggett]

Note that we need to start planning for rechartering the Web of Things WG as the charter runs out later this year. This will be a good opportunity to refocus on what companies believe are the most salient work items for commercial deployment opportunities.

[mkovatsc]

I am personally very keen not to do anything to fragment Web of Things standardisation, but I worry we still haven't reached a common understanding between web companies and device makers on the basic definition of the Web of Things.

Yes, but ignoring the requirements of device makers is not a fruitful way forward; we are putting effort in aligning and simplifications, yet I cannot see any movement, nor openness to understand on your side. I have seen and worked in both worlds and am not happy with several IoT developments either. Yet I am convinced that if we provide a convenient "Web pickup", the IoT can perform a similar evolution as the Web did. Sadly this means to repeat something adjacent to the browser wars, as it is part of the evolution.

[benfrancis]

Yes, but ignoring the requirements of device makers is not a fruitful way forward; we are putting effort in aligning and simplifications, yet I cannot see any movement, nor openness to understand on your side.

I'm sorry if that's the impression I've given because that certainly isn't my intention. I want to see the Web of Things become a commercial reality, not just an academic research project. As Mozilla's experimental work starts to encompass software libraries for building web things themselves as well as our gateway implementation, hopefully this will help us to better understand the requirements of device makers.

But I do still strongly hold the opinion that the scope of the current WoT WG charter is too large, that the Binding Templates and Scripting API specifications are probably unnecessary, and that people are trying to shoehorn requirements into web specifications which should instead be addressed at a different layer of the technology stack. This is also based on lessons learned from past mistakes in the System Applications Working Group.

I'm hopeful that we can find a way forward that satisfies everyone's needs.

[zolkis]

I would argue that it is useful to consider TD design with the goal to be able to describe every existing IoT deployment. So the IG was not wrong about this.

However, for the sake of standardization in a WG, I very much agree in scoping the efforts to HTTP/S and WebSockets, and RESTful interactions, at least to start with this. This would constitute the core level/layer of WoT standardization.

There could be another level/layer where optionally we add support for other protocols and the optional scripting support.

[draggett]

We need to start discussing aims for 2019 and beyond given that the current WoT IG and WG charters run out towards the end of this year. We should emphasise the involvement of companies that are interested in deploying the Web of things as a solution to pressing interoperability problems and a means to enable open markets of services based upon open rather than proprietary standards.

I think that it is entirely reasonable to charter work on how to use HTTP and WebSockets. A precedent is the work W3C did on the Linked Data Platform, where access and update on RDF graph's is defined in terms of a RESTful API over HTTP. The IETF isn't the only venue for work on protocols, and in this case, it makes sense to have the same people work on both the metadata vocabulary and format for thing descriptions, and the use of HTTP and WebSockets for secure messaging between Web of Things application platforms. Splitting this into one group at W3C working on metadata and another group at the IETF working on protocols would only complicate matters.

[mkovatsc]

The Linked Data Platform uses HTTP, and thereby builds on a well-defined protocol.

Defining a protocol on top of WebSockets is a completely different story. Personally, I cannot see enough successful real protocol definitions in the W3C; the WebSocket-based protocols in the Automotive group, for me, are more an example not to do such work in the W3C.

[mkovatsc]

I want to conclude this, as a running Working Group cannot stop its work just because a person not participating thinks it is not necessary. Conluding points:

• W3C WoT was explicitly not chartered to invent yet another IoT platform, but to define building blocks that counter the fragmentation in the IoT and help to bring existing IoT platforms to the Web.
• WoT Binding Templates are not a specification. The deliverable is informative and explains how the Thing Description and its vocabulary is used to describe Things.
  • This is required for HTTP(S) and CoAP(S), as Web APIs have a certain noise. The existence of OpenAPI shows that.
  • It is also required to describe Things of specific and relevant IoT platforms/ecosystems such as OCF, oneM2M, and OMA LWM2M.
  • It shows how the vocabulary and mechanism can be used to describe future IoT platforms.
• To become part of the Web of Things, Things Interactions (resources) must be identifiable and addressable through URIs (we are using href which takes a URI in the TD!). IoT protocols that do not have URI schemes defined cannot be used.
  • IoT protocols that are fit for WoT can be "promoted" by defining and registering a URI scheme, e.g., MQTT where URIs identify topics and the set of methods is well defined.
• Intentions to leave out URIs in the TDs and let the client construct them based on an implicitly assumed resource structure are inherently wrong for the Web.

[benfrancis]

OK, in that case I suggest we re-visit this topic when discussing the renewal of the Working Group Charter.

[Citrullin]

Hey, I just read this thread. Just a comment from an outsider: It makes sense to describe the status quo and include widely used protocols. (MQTT, JSON for example) Since there are standards by the IEEE and IETF, the industry is more and more moving to them. Namely CoAP, 6LoWPAN (IPv6) and cobr. So, the W3C should not have an opinion which standard is used. You may prefer IETF and IEEE ones. Which also makes totally sense. The platform provider can choose which underlying protocols they support. I think, they will tend to use the standards defined by the IETF and IEEE first.