- From: Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com>
- Date: Mon, 9 May 2016 07:05:05 +0000
- To: Chris Needham <chris.needham@bbc.co.uk>, "public-tvcontrol@w3.org" <public-tvcontrol@w3.org>, "public-tvapi@w3.org" <public-tvapi@w3.org>
Hi Chris, W3C has been promoting to diverse devices using web technologies in past 5 years. This is a fundamental issue if device specific capabilities should be exposed as network resource or JavaScript APIs as W3C standards. It would be appreciated if TAG provides a guideline on the two approaches. Also, it is preferable that W3C defines a basic framework to convert W3C standard APIs(Web IDL) to "network resource" approaches using REST and WebSocket. In the era of IoT, it would be good for web application developers to control devices regardless of device location. In terms of TV Control API[1], it should be JavaScript API because it is not only about controlling TV but also for integrating broadcast rendering function (of device) in browser's implementation. TV Control API defines an extension to the HTML5 video in order to support broadcast specific requirements. I found the following two use cases in the TAG's minutes. TV Control API is for UC1 but not UC2. I wonder that the word "Control" may cause some misleading. TV Control API is not designed for UC2. "network resource" approach, e.g. REST, would be good enough to change channel of remote TV device but the TV Control API is required to extend HTML video in addition to such controls. UC1. a TV running FFOS that wants to manipulate internal state through an API that they want to expose. UC2. I'm a generic web browser and I want to connect to a set-top-box and I want a protocol to talk to that device. The other issue of "network resource" is security. Mixed Content[2] requires to use TLS connection to local server on device if a web page is secured, but devices may not be able to have a FQDN server cert. This issue is generic because it applies the case that a web server on IoT devices become a part of Open Web. UC2 has the same issue as discussed at TPAC2015[3] Thank you. [1] http://www.w3.org/2015/tvapi/Overview.html [2] http://www.w3.org/TR/mixed-content/ [3] https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Secure_communication_with_local_network_devices -***---***---***---***---***---***---***---***---***--***---***---***- Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com) Innovative Technology Development Div, System R&D Group Sony Corporation -----Original Message----- From: Chris Needham [mailto:chris.needham@bbc.co.uk] Sent: Friday, May 06, 2016 9:39 PM To: public-tvcontrol@w3.org; public-tvapi@w3.org Subject: TAG discussion on the TV Control WG charter Hi all, The TV Control WG Charter was discussed by TAG at their recent F2F meeting [1]. The minutes from the meeting are at [2] and [3]. In summary, the TAG is wondering whether specific APIs such as ours, and others coming from other groups such as the Automotive WG, could perhaps be best exposed as network resources rather than JavaScript APIs, however they do not currently have specific guidance on which approach to take. There was initially some confusion about the scope of the TV Control API, which Yosuke helped clarify during the meeting. This is understandable as the name could be read to imply a protocol for controlling a TV device on the network, which isn't really the aim of our WG. Nonetheless, the question of whether a network resource based approach would work hasn't been discussed in the CG so far, and we'll need to have a view on this when we start discussion with the TAG. Please share your comments on the mailing list. Thanks, Chris (WG Chair) [1] https://github.com/w3ctag/spec-reviews/issues/111 [2] https://github.com/w3ctag/meetings/blob/gh-pages/2016/03-london/29-03-2016-minutes.md [3] https://github.com/w3ctag/meetings/blob/gh-pages/2016/03-london/30-03-2016-minutes.md
Received on Monday, 9 May 2016 15:02:16 UTC