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.

If an Operator is interested in providing an API which enables web browsers to ask questions of the form:

"Please send me a rate schedule (cost per megabyte and megabyte bucket edges, and my current status) for <network destination list>" where the response is:

[
 {destinationHostName:"0.facebook.com", currentUsageInMb: 20, rates: [
  {minInMb:0, maxInMb: Inf, feePerGbInCur: 0, feeCur: "USD"},
  validUntil: Date("2012-07-13 13:02 UTC")
 ]
 },
 {destinationIPMask:"10.0.0.0/23", destinationIPv6Mask:"...", currentUsageInMb: 400, rates: [
  {minInMb:0, maxInMb: 499, feePerGbInCur: 10, feeCur: "USD"},
  {minInMb:500, maxInMb: 2999, feePerGbInCur: 20, feeCur: "USD"},
  ...
 ],
  validUntil: Date("2012-09-13 23:52 UTC")
 },...
]

And then promise to provide that API as a RestFul JSON at say http://network-rates/? or something like that, and promise not to charge for datapackets to "network-rates", then perhaps we could do something.

However, JSON Services in general do not need to be standardized by W3. Nor did WSDL APIs before them. In order for W3 to standardize something, existing APIs need to exist so that we can look at them and see how they work.

If you Tomoyuki represent an operator, and Jean Francois represents an operator, and a few other people representing operators get your operators to create this API and implement it in a similar fashion and then show that it's useful, then maybe we can see about standardizing it. Note that reserving "network-rates" as a magic name, just as "example.*" are magic names would be an IETF domain element, not W3C. The API itself could be defined as being owned by W3 if you like, but first, you should implement and deploy it.

Note that "http://network-rates" would really be network-rates.[dns-suffix] or similar, so possibly network-rates.att.net or network-rates.orange.fr, the browser would do a dns lookup for network-rates, and the DNS service would resolve that automatically based on the network to the right thing. Such a system would work equally well for Cellular or Cable or Satellite or any other network provider. 

The API unfortunately would probably be much more complicated, as some providers charge differently for inbound v. outbound, and you'd also want to provide speed details.

But my point is that this isn't in the scope of anyone at W3C until a couple of operators implement something like this and then say "hey, we have this thing, you can try it, we're committed to it, and to improving it".

Until you do that, there's absolutely nothing anyone can do. It requires a number of operators to implement this. Browser vendors can't do anything to help here. The fact that operator fee schedules are incredibly complicated makes it all the more essential that the operators figure this out and commit to it first. From the browser side, XMLHttpRequest and JSON exist and are all any browser or web app needs in order to handle such an API. Note that while such an API would be nice, it isn't clear that browsers would want to provide direct access to it to all web apps, as they might later want to reserve some bandwidth for other web pages than the one that's interested in knowing about available resources. So once you, the operators, provide this API, we, the W3 (including Browser vendors) can work on deciding how to expose that data.

I'm not sure if GSMA or OMA or some other group is best for operators to use to talk about such things, in principle, I'm not opposed to /some/ w3 resources being allocated to this task, but it isn't a Core Mobile item, and I'd really like you to talk to Cable and Satellite vendors as well. Creating a CG @w3 is cheap, so you could create a "network-rates" CG if you'd like.

Disclaimer: The above do not represent the opinions of my employer, nor of w3.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Thursday, 5 July 2012 16:13:30 UTC