Re: updates for the TPAC plugfest

Thanks for the slides and for the focus on bridging the NAT/firewall boundaries between the network edge and the Internet.

 https://lists.w3.org/Archives/Public/public-wot-ig/2017Sep/att-0017/update_Issues_for_TPAC_plugfest_170927a.pdf <https://lists.w3.org/Archives/Public/public-wot-ig/2017Sep/att-0017/update_Issues_for_TPAC_plugfest_170927a.pdf> 

I have a few points.

First: I think we should also consider the role that web pages can play.  Web pages can include a web of things library module that creates scriptable objects that function as proxies for things exposed by servients. The local origin security policy acts to limit web pages to accessing servients with the same origin as the web page.  For that reason, my servient embeds a web server for HTTP and WebSockets. This allows applications installed on the servient to present a user interface that runs within a web browser whether on a desktop, smart phone or tablet. On your slide 5, this is loosely equivalent to replacing the application servients at the top by web pages.

Second: on slide 16, I’ve used a different approach that avoids the need for binding templates for what you call legacy devices.  My solution uses a servient that acts as an application platform.  These applications may produce (expose) or consume things. An app that produces a thing embeds the code needed to communicate with the IoT device.  This is easy for NodeJS as there are plenty of networking modules to choose from.  In my case, I was easily able to write a few lines of code to use CoAP to get and put the state of a device and to subscribe to a stream of updates to the state. It would be straight forward to use other Node modules for Bluetooth, Zigbee and so forth. This essentially means that we only need to focus on the protocols used by servients to expose things, in my case, a messaging protocol over Web Sockets.

Third: when a servient behind a NAT/firewall boundary wants to publish a thing on an Internet server, it can push the thing description to that server. In my case, this is done via an HTTP request that is also used for authorisation, and returns a security permit that is then used in the WebSocket connection the servient behind the firewall opens to the Internet server. I use a similar request when an app requests an object as a proxy for a thing. Here the HTTP request is for the thing description. The response also contains the security permit. This is then passed over WebSockets when registering a consumed thing.

Fourth: there can be multiple URIs for the same thing, depending on which network interface is used (e.g. localhost or WiFI), whether using IPv4 or IPv6, and the difference between the IP address within a LAN and the corresponding external address on the Internet. A work around for this multiplicity is for each servient to use local identifiers for the things it exposes. This can be included in the thing description, and used within the messaging protocol.

Fifth: I would prefer us to discontinue the term “legacy device” as this doesn’t help us when we are trying to explain what W3C is doing, to people involved in other IoT standards development organisations.  It is better to say that the Web of Things focuses on the application layer, exposing things as objects independently of the underlying protocol standards. We thus complement the work by those  IoT standards development organisations, firstly through reducing the costs and risks for developing applications, and secondly, by enabling the use of semantic descriptions of things and their relationships as a basis for open markets of services encompassing many different IoT protocol standards.

Many thanks,

Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C champion for the Web of things & W3C Data Activity Lead