Re: DAP rechartering discussion

Hi Giuseppe,

On Mon, 14 Mar 2011 11:11:54 -0000, Giuseppe Pascale <>  

> On Fri, 11 Mar 2011 23:32:09 +0100, Mark Watson <>  
> wrote:
>> Matt, Olivier,
>> The Universal Remote protocol looks great. At what level, though, would  
>> you expect there to be a need for standardization ?
>> 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) ?
> This would fit nicely in the "home networking" discussion we started in  
> Berlin and presumably we will continue to discuss here soon.
> @Matt, Oliver
> Honestly, I haven't had time to look into your work yet.
> How do you think it would fit into a more generic work around "home  
> networking API", that is devices discovery and control inside the home  
> network (UPnP-like)?
> /g

I think there is a lot of potentially useful overlap. It would be useful  
if there were common mechanisms for discovery and simple security (e.g.  
establishing pairing relationships) directly between devices.  
Standardisation of this at both the protocol level and as higher level  
device APIs would be really useful.

We already tried in our API to address these. Perhaps there are parts that  
could be taken independently of this particular application and reused for  
others. I'm specifically thinking of our pairing code mechanism here.

At the same time, our spec doesn't try to specify additional browser  
features to support zeroconf/bonjour or UPnP discovery mechansisms. The  
lack of these is something that could be rectified.


>> ...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:
>>> 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 <>
>>> 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, <> 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]
>>> --
>>> | Matt Hammond
>>> | Research Engineer, BBC R&D, Centre House, London
>>> |

| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London

Received on Wednesday, 16 March 2011 03:02:32 UTC