Re: DAP rechartering discussion

Hi Matt,

Thanks for the explanation.

My main comment is that I would not expect standardization to reach so high in the stack. Or at least we should decouple the discovery, connectivity and security aspects (which are generically useful) from aspects such as content search and metadata, which IMO are service-specific (or source-specific in your terminology).

For example, I would find it very difficult to see how a service such as Netflix's could fit into the model you've defined: we have our own metadata, including categories, and would expect to have our own User Interface on both the TV and the remote: they need to discover each other and communicate but after that their communication probably needs to be proprietary, since standards cannot anticipate the ways we will want to innovate with respect to the Remote<->TV interaction and their respective user interfaces (and nor can I).

I should say that this ability to independently innovate in terms of User Interface and service features has been, and we expect will continue to be, essential to our business. Indeed this is one of the great advantages of integrating web technology into CE devices. The science of content discovery within very large content catalogs has a long way to go: we have had some success with this at Netflix but this is just the beginning. It's not just about good recommendation engines, but about the whole user experience, which is why we need flexible presentation environments on the devices presenting user interfaces and the interaction between them.

A few more comments below...

...Mark



On Mar 15, 2011, at 7:49 PM, Matt Hammond wrote:

> 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.

Javascript libraries would provide a lot more flexibility, unless you thought there might be performance concerns. If there was, for example, an open source client-side library that people could use for their UC implementation you have all the advantages of ease-of-use, avoid (some) problems with divergence features supported by different devices and avoid the difficulty in upgrading devices to support new features. The baked in device APIs would be kept to the lower layer stuff (Zeroconf etc.) that would hopefully be more static.

> 
> 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.

Yep, we do something like this which we call "rendezvous". It should certainly be one of the options for establishing secure remote<->TV pairings.

> 
> 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.

I don't see an advantage in making things a device feature which could easily be implemented as a web app, given the appropriate platform APIs.

> 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.
> 
> 

For this aspect, you could also standardize platform APIs that enable people to develop apps (cooperating with remotes or otherwise) for management of other apps, although it is much less obvious that enabling innovation in that space has much value.

> 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 04:34:14 UTC