Re: DAP rechartering discussion

Hi Mark,


On Fri, 11 Mar 2011 22:32:09 -0000, Mark Watson <watsonm@netflix.com>  
wrote:

> Matt, Olivier,
>
> The Universal Remote protocol looks great. At what level, though, would  
> you expect there to be a need for standardization ?

Thanks! Our motivation at the BBC is to see an API like this widely  
deployed in TVs and set top boxes (UK and beyond) from multiple  
manufacturers and clients that are able to work with any device, be they  
browser based clients, native apps for desktops/laptops/phones or even  
embedded devices.

What we consider needs to be standardised roughly matches up with what is  
found in our draft spec. In this case that means: the definition of a  
domain/data model, profiled use of a transport layer protocol and  
application protocol (http over IP on our case), and then the structure,  
representation formats and behaviour of a set of HTTP resources; including  
behavioural semantics in relation to the expected effects on the state of  
the device serving the API.

I'd also be keen to see access to the application layer protocol level  
abstracted and simplified for common client environments - such as  
javascript in the browser context. Perhaps this would take the form of  
client side implementations as device APIs, or as pure javascript  
libraries.

Looking at the domain model side: we've been trying hard to strike a  
balance where the domain model can capture key concepts (e.g. "content"  
that comes from "sources") without making too many platform specific  
presumptions (e.g. choice of category/genre schema or mandating particular  
source and content identifier schemes). We wanted to avoid coupling this  
too tightly to any particular TV platform, or forcing substantial  
infrastructure/metadata changes.

> I can presumably implement both client and server side of the protocol  
> using HTML/CSS/Javascript (if I can't then there's a need for  
> standardization right away), so what would remain would be  
> device/application discovery and the initial security aspects.
>
> i.e. how does the Universal Remote client discover that there is a  
> nearby TV supporting the Universal Remote server application (or capable  
> of supporting it) and ask the TV to launch that application (or kick off  
> installation) ?

We address security and discovery in our current spec by several means:

It requires servers implement bonjour/zeroconf (mDNS) for clients that  
support it. Device API access to these kinds of discovery services would  
be nicely complementary and something we'd be keen to see happen.

We also spec a 'pairing code' that is displayed by the server (eg. TV)  
that entropy encodes the IP address (short codes for common home subnet  
IPs) and can be keyed into the client by the user. This can also include a  
few extra digits of one-time-pad/shared-secred to assist in establishing a  
secure relationship between the two devices.

Generally though, for all our use cases, we've considered the server side  
to be a device feature, rather than a application with a transient  
lifecycle. In fact there are specific hook points in the API where we'd  
hope server implementers would make it possible for on-TV applications to  
extend the API and have their lifecycle managed by clients. So this API  
could be a mechanism to achieve what you suggest in your last question, on  
behalf of other applications on the TV.


regards


Matt

>
> ...Mark
>
> On Mar 11, 2011, at 9:48 AM, Matt Hammond wrote:
>
>> Would the Device And Policy APIs WG (DAP) be interested in looking at  
>> APIs
>> not just within the device itself (for accessing on-board device
>> functions) but also defining web style APIs between devices?
>>
>> My personal belief is that the strengths of the TV is as a primary  
>> (though
>> not exclusively!) shared and "lean-back" experience. I think it makes
>> sense to put in place the means to allow web applications on other  
>> devices
>> to interact with the TV. A lot of the functions/user-experience that  
>> might
>> traditionally be considered the domain of an on-screen "widget" could be
>> migrated off the TV screen to more powerful and easier to interact with
>> device, but without losing that connection to the TV content.
>>
>> Our "Universal Control" API work, in the BBC, makes the functionality of
>> the TV queryable and controllable via a high level data model that tries
>> to abstract away from device and service implementation specifics. Its a
>> RESTful web based API intended to be served by the TV (or set-top-box)
>> itself. We'd hope our work so far could be a useful kick start for work  
>> in
>> this area. Components of such an API could be generalised and be useful
>> for other classes of devices.
>>
>> My colleague Olivier posted a few details (including links to our spec
>> docs) just a few days ago:
>>
>>   http://lists.w3.org/Archives/Public/public-web-and-tv/2011Mar/0013.html
>>
>> Could this kind of area be a logical and productive progression for  
>> DAP's
>> mission?
>>
>>
>>
>> Matt
>>
>>
>>
>> On Fri, 11 Mar 2011 16:27:39 -0000, Mark Watson <watsonm@netflix.com>
>> wrote:
>>
>>> [+ Web & TV Interest Group]
>>>
>>> Should the device types mentioned in the new Device And Policy APIs
>>> recharter proposal be expanded to include TVs and other such devices
>>> which increasingly make use of web technologies ?
>>>
>>> ... Mark
>>>
>>>
>>> On Mar 11, 2011, at 5:44 AM, <Ingmar.Kliche@telekom.de> wrote:
>>>
>>>> Deutsche Telekom supports the new DAP charter proposal [1], but asks  
>>>> for
>>>> some clarifications and/or changes.
>>>>
>>>> Chapter 1 "Goals" explicitly mentions security and privacy and  
>>>> proposes
>>>> "... reusing existing browser-based security metaphors where they  
>>>> apply
>>>> and looking into innovative security and privacy mechanisms where they
>>>> don't."
>>>>
>>>> On the other hand section 2.2. "Out of scope" explicitly excludes
>>>> further thinking about a policy framework. This limits the  
>>>> possibilities
>>>> of "innovative security and privacy mechanisms", since one potential
>>>> solution is precluded beforehand. We know about the discussions in the
>>>> past, but we think it should be left up to the discussions during the
>>>> charter period if a policy framework is the right way to go or not.
>>>>
>>>> Furthermore the scope of the work explicitly mentions different types  
>>>> of
>>>> devices ("Devices in this context include desktop computers, laptop
>>>> computers, mobile Internet devices (MIDs), cellular phones.").  
>>>> Therefore
>>>> we think it would be appropriate to add another success criteria which
>>>> requires implementations for different device types before going to  
>>>> W3C
>>>> Rec (especially mobile and desktop devices) to make sure that the APIs
>>>> are implementable in the different environments which are explicitly  
>>>> in
>>>> scope of DAP.
>>>>
>>>> ... Ingmar.
>>>>
>>>> [1] http://www.w3.org/2010/11/DeviceAPICharter.html
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> | Matt Hammond
>> | Research Engineer, BBC R&D, Centre House, London
>> | http://www.bbc.co.uk/rd/
>>
>


-- 
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/

Received on Wednesday, 16 March 2011 02:50:08 UTC