Re: Call for DAP Liason

Stefan Håkansson LK wrote:
> Reminder: anyone that is in DAP and could monitor for webrtc?

I'm more than happy to do this. I hope to have support from the W3 Staff 
Contacts wrt W3C Process Announcements (e.g. Working Draft or Last Call 
Publication Announcements).

As an introduction, DAP has some work that may be relevant to WebRTC on 
the following specs. The full list of specs in DAP can be found @


- General: Device API Privacy Requirements

DAP has also done a lot of work wrt privacy by design for web-based 
Device APIs. The derived requirements document should make for some best 
practice that we might like to follow in the WebRTC group.

- The Media Capture API

I personally consider this superseded through a combination of the 
WHATWG getUserMedia proposal (for embedding real-time a/v) and the HTML 
Media Capture specification @ (for 
uploading recently captured, UA-assisted real-time a/v).

This spec should, however, at least be considered available for input 
and transfer to the WebRTC WG as part of the recent Request for 
Proposals from this group.

- The Network Information API

It has already been pointed out on the DAP mailing list that this is 
likely to be useful to the WEBRTC WG, though the actual content of such 
an API is up for discussion. If the web application is required to 
switch between different bit-rate a/v as part of a peer connection then 
this API, of a variation thereof, may be suitable for inferring network 
bandwidth capabilities. Whether it actually allows that is for further 
discussion in both groups.

- The Contacts API

Whether the Contacts API has any role to play in the WebRTC UCs is open 
for debate. The Contacts API provides telephony details for different 
contacts, which could be dialed directly in the UA, for example.

- The Messaging API

Whether the WebRTC group is also considering messaging channels as part 
of the peer-to-peer work is not clear. If so then the Messaging API is 
an attempt to define such cross-service messaging with additional 
capabilities (such as appending attachments).

- Communications Log API (abandoned)

An inactive (and entirely blank page :/) specification that took, 
apparently, 8 editors to write ;) This is included in this list as a way 
for the user to view their usage of communications channels. An API 
would be up for discussion.

At Opera, in envisioning WebRTC APIs, we're considering logging all a/v 
communication in an effort to provide users with transparency on who 
they communicated with (and when). A Comms Log API seems unnecessary 
though IMO.

- The System Information API (abandoned)

Provided a means to get a host of network, power, thermal, CPU and 
sensor information, etc. This spec was considered too broad to 
reasonably expect user-friendly UX and so the group has recently decided 
to split the APIs in to smaller pieces such as the Network Information 
API (see above) and Battery Level API @


In terms of the status of the above documents (except those marked as 
abandoned), they are all at the Working Draft phase with the Contacts 
API currently planned for Last Call publication.

I'll keep the group updated on anything else that may become relevant in 
the future. I'd appreciate others to help also and it would be good to 
discuss the applicability of any of the above specs to the WebRTC group 
on this list.

- Rich

Received on Monday, 20 June 2011 10:17:54 UTC