W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2013

RE: Liaison statement from OMA on network efficiency

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Wed, 6 Feb 2013 16:04:39 +0000
To: Dominique Hazael-Massieux <dom@w3.org>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "Frederick.Hirsch" <Frederick.Hirsch@nokia.com>
CC: Mohammed Dadas <mohammed.dadas@orange.com>
Message-ID: <59A39E87EA9F964A836299497B686C3510968166@WABOTH9MSGUSR8D.ITServices.sbc.com>
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.

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) — see attached

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

Frederick, it's probably worth adding to the agenda of our next call
(Feb 6).


Received on Wednesday, 6 February 2013 16:05:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC