Re: Call for DAP Liason

Rich,

thanks a lot for taking on this task - really appreciated.

Reading through your input, I think the WG should spend some time 
understanding
* the privacy reqs developed by DAP
* if the configuration parts of the Capture API can be used
and
* if/what role there would be for a Network Info API (and what reqs we 
should put on it in that case).

Stefan for the chairs

On 2011-06-20 12:17, Rich Tibbett wrote:
> 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 @
> http://dev.w3.org/2009/dap/.
>
>
> ***
>
>
> - General: Device API Privacy Requirements
> http://dev.w3.org/2009/dap/privacy-reqs/
>
> 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
> http://dev.w3.org/2009/dap/camera/Overview-API.html
>
> 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 @ http://dev.w3.org/2009/dap/camera/ (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
> http://dev.w3.org/2009/dap/netinfo/
>
> 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
> http://dev.w3.org/2009/dap/contacts/
>
> 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
> http://dev.w3.org/2009/dap/messaging/
>
> 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)
> http://dev.w3.org/2009/dap/communications-log/
>
> 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)
> http://dev.w3.org/2009/dap/system-info/
>
> 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 @
> http://dev.w3.org/2009/dap/system-info/battery-status.html.
>
>
>
> ***
>
> 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 11:05:18 UTC