- From: SULLIVAN, BRYAN L <bs3131@att.com>
- Date: Mon, 14 Jul 2014 20:56:17 +0000
- To: "'Natasha Rooney'" <nrooney@gsma.com>, "'Arthur Barstow'" <art.barstow@gmail.com>, "'Dominique Hazael-Massieux'" <dom@w3.org>, "'public-web-mobile@w3.org'" <public-web-mobile@w3.org>
Hi Natasha, Unfortunately I have a standing conflict with the WebMob meetings, otherwise I would attend this one for sure. FYI I've initiated a followup discussion in the OMA on W3C mail list comments (e.g. principally comments that the APIs are not "RESTful"... aargh!). But whatever, ideas about how web APIs *should* be designed do evolve over time, and I'm sure that if OMA needs to it will catch up with the current philosophy. The principle deviation appears to be in the definition of "fixed resource names or hierarchies" for resources, something I guess that comes from the ingrained tendency toward ensuring interoperability through deterministic / fully-specified client-server interfaces, which I guess one could argue can be achieved without "fixed resource names or hierarchies". On coop opps, I do spend a lot of time ensuring that OMA technologies and related services where possible are (a) based upon web technologies; (b) compatible/integratable with web technologies; (c) accessible to the web. So in OMA enablers you will see a lot of references to web specs, WebIDL, and API design patterns (where again it's hard to keep up with W3C, but oh well). Almost every service enabler we work on in OMA has both a protocol-based (e.g. SIP/IMS) and web-based/compatible (e.g. "RESTful" network APIs) exposure, and some APIs (e.g. the "RESTful Network API for WebRTC Signaling" [1]) are explicitly designed for integrating traditional telco services with the web. And as telecom services get re-imagined/deployed as cloud services under network function virtualization, we are likely to see even more synergy between OMA (and even 3GPP) and W3C. [1] http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/rest_netapi_webrtcsignaling_v1_0 Thanks, Bryan Sullivan | Service Standards | AT&T -----Original Message----- From: Natasha Rooney [mailto:nrooney@gsma.com] Sent: Thursday, July 10, 2014 7:59 PM To: Arthur Barstow; Dominique Hazael-Massieux; public-web-mobile@w3.org Subject: Re: OMA liaison statement on network APIs activities Thanks Dom! And thanks Mark and Art for the comments. Mark - given youšve read the documents and have some comments, would you mind presenting these on our monthly webmob call next Wednesday? https://www.w3.org/wiki/Mobile/Meetings Thanks! Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org 7th Floor, 5 New Street Square, London EC4A 3BF On 2014/07/10 2:52, "Arthur Barstow" <art.barstow@gmail.com> wrote: >On 7/9/14 9:22 AM, Dominique Hazael-Massieux wrote: >> These 3 new work items are: >> * a template for RESTful network APIs >> * guidelines for RESTful network APIs >> * the OMA service exposure framework >> (detailed in the liaison statement) >> >> In particular, we are requested to investigate opportunities for >> cooperation on these, and to provide an update of W3C activities >> potentially linked to them. > >Re the later ("update"), the closest connection I can think of is the >Network part of your mobile-web-app-state document ><http://www.w3.org/Mobile/mobile-web-app-state/#Network>. > >The only other thing that comes to mind is the new(ish) Push Protocol >work (f.ex. see ><http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0063.html>) > >but since Bryan's involved with at least API side of that (as well as >OMA (I think)), that may be `old news` to them. > >Re the former ("opps for coop"), of course if they have any feedback on >the "network" specs, that feedback would be welcome (via the comment >list mentioned in each spec). > >-AB > > This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.
Received on Monday, 14 July 2014 20:57:32 UTC