W3C home > Mailing lists > Public > public-coremob@w3.org > July 2012

RE: Network Information Use Cases

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Thu, 5 Jul 2012 17:20:16 +0000
To: Josh Soref <jsoref@rim.com>, Core Mobile <public-coremob@w3.org>
Message-ID: <59A39E87EA9F964A836299497B686C350FF35E60@WABOTH9MSGUSR8D.ITServices.sbc.com>
Comments inline.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Josh Soref [mailto:jsoref@rim.com] 
Sent: Thursday, July 05, 2012 9:13 AM
To: Core Mobile
Subject: RE: Network Information Use Cases

Tomoyuki SHIMIZU wrote:
> I want to show another use case of network information such as
> below:
> 
> * International Roaming: Almost all smartphones can access the web when we
> go anywhere in the world, by applying international 3G roaming. Roaming
> services require much higher fee, so eliminating data traffic and offline
> functionality are desired when 3G roaming is being applied and no wi-fi
> connection is available. It's useful to detect which 3G carrier is currently
> connected to, as well as to detect/switch the type of connection.

As DAP developed the Network Information API, and then its replacement proposal, we have meetings and minutes which cover items relating to this.

What was raised (I can get the references later) was that roaming costs aren't fixed. It's possible for you to be roaming to a neighboring country where the cost is the same as not roaming. Or you could be roaming to a place where it's very expensive. Or you could have activated a plan where roaming to the country may be cheap for a day.

[bryan] I remember and was involved in those discussions. It is complicated to definitively determine roaming status, and also the implication of it. That being said, devices already support a reliable-enough awareness of roaming (otherwise how could they provide a system-level option for data use when roaming), and a simple roaming=true|false indicator made available to Webapps would be valuable. I don't think it takes GSMA etc to prove this through a network API first, when the fact that it's a common device feature has already proven it. The ask is here (and was before) to simply expose this through an API provided by the user agent. I could build a pretty reliable network API for this myself, but the biggest hurdles for such, as anyone involved in them knows, is API discovery (how do developers learn of this?) and ubiquity/interoperability (sure I can do it, but if it isn't available somewhere or differs from other APIs, what good is it?). These hurdles inhibit the chance that such capabilities make it into developer hands. A user-agent provided API puts it directly into their hands. That's the difference.
Received on Thursday, 5 July 2012 17:21:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:47 UTC