RE: Liaison statement from OMA on network efficiency

Hi Bryan, Dominique and all,

I fully support Bryan's opinion and would like to make the network more visible and easy to use for WebApps for it to be able to use network resources more efficiently. Privacy and security issues are very critical; therefore must be handled carefully, but we have several tools to manage them. OMA, GSMA and 3GPP are working on network efficiency in different forms and areas. W3C should interwork with them since network efficiency is achieved by end-to-end. I'm wondering how we can move it forward...

Regards,
--
Hidetoshi

>Hi Dom,
>
>(cc'ing Mohammed as OMA's liaison champion for W3C)
>
>Your comments are on-target. This effort in OMA, which we support, is focused on enabling apps to use network resources more efficiently and effectively. This is kind of a meta-objective of the use cases behind the DAP Network Info API, and as you said further detailed info along with network status could be used by apps (e.g. with the help of JavaScript libraries) to manage both pull and push operations more efficiently. But in W3C (esp for browser-based apps) there has been reluctance to expose such detailed info to apps for privacy reasons - I have been not so concerned about that, as I think the issues are manageable, but I understand the conservative approach of browser vendors.
>
>The approach in DANE would address those privacy issues, as well as provide the more robust end-goal-oriented capabilities that I mention above, i.e. the approach is *service-oriented* rather than *info-oriented*, meaning that apps can directly achieve the efficiency objectives without having or needing access to the detailed network info used to manage the content delivery service. Further, DANE will integrate additional network capabilities e.g. QoS which are coming in IMS/LTE mobile network environments.
>
>I have suggested a similar "service" oriented approach in discussions at W3C, e.g. during our "Smarter Webapps for Smarter Phones" discussion at TPAC. I think that idea has resonated with some W3C members, but there has been no specific followup action yet. But I believe that a JavaScript API which addresses similar objectives as DANE would be valuable, both in DANE-enabled devices (when those appear) and in other devices. 
>
>The goal of OMA members (especially Operators) in DANE is to promote a better experience for all mobile network users through optimizing network usage for as many users as possible, and extending advanced capabilities e.g. QoS to apps where possible for the new use cases that QoS will enable. The industry is doing everything it can to handle the continued explosion of mobile network usage, and this service enabler concept is one example of that effort.
>
>Thanks,
>Bryan Sullivan 
>
>-----Original Message-----
>From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
>Sent: Friday, January 25, 2013 8:15 AM
>To: public-device-apis@w3.org; SULLIVAN, BRYAN L; Frederick.Hirsch
>Subject: Liaison statement from OMA on network efficiency
>
>Hi all,
>
>We have received a liaison statement from OMA on a new acitivity they're
>starting, called Device Apps Network Efficiency (DANE) &#8212 see attached
>document.
>
>The Device APIs Working Group is specifically called out as one of the
>targets of the document.
>
>They are asking a review from their proposed work, as well as a summary
>of existing W3C work in this space.
>
>My own reading of the liaison statement is that at the very least, our
>work on the Network Information API has some relevance to that work (one
>could imaging that browsers would use DANE to get information about e.g.
>the available bandwidth).
>
>We have also discussed several times (but without any concrete proposal
>that I know of) providing more advanced capabilities to optimize Web
>apps usage of network capabilities &#8212 it would be useful if someone could
>summarize our existing discussions to date, esp. if they could be source
>of requirements for that work.
>
>Brian, I believe you're active in OMA, so if you have further input /
>insight on useful input we could gather for OMA here, that would be
>welcome.
>
>Frederick, it's probably worth adding to the agenda of our next call
>(Feb 6).
>
>Thanks,
>
>Dom

Received on Thursday, 7 February 2013 05:31:11 UTC