- From: Sullivan, Bryan <BS3131@att.com>
- Date: Fri, 16 May 2008 16:07:41 -0700
- To: "MWI BPWG Public" <public-bpwg@w3.org>, "Jo Rabin" <jrabin@mtld.mobi>
Moving to the public list. Jo, that it may be impractical to attach to services of 350+ GSM Operators it itself irrelevant and a distraction, in that most Content Providers have a much narrower focus (national in most cases, due to langauge issues). Many Operators have large international Operations and though there are 350+ (or more) a Content Provider can focus on one, a few, or the top 10 and hit the 80%. Even if that were not the case, there are aggregators that make this simpler for Content Providers, as I have said. There are many BP's that may be beyond the reach (by technical expertise, system capabilities, or policy) of some Content Providers to leverage, but that doesn't mean they aren't perfectly valid and useful when they can be. So without adding much in the way of advice on this (which seems like it would be questioned anyway), we can state that use of Push as a means to optimize over-the-air traffic (and also for it's more immediate benefit in creating great web applications, to enable alert-based services) is supported by most Operators and can be leveraged by inquiring as to how the specific Operators of interest (or the aggregators that work with them) expose this capability to the Content Provider. Best regards, Bryan Sullivan | AT&T -----Original Message----- From: Jo Rabin [mailto:jrabin@mtld.mobi] Sent: Friday, May 16, 2008 1:53 PM To: Sullivan, Bryan Cc: Sean Owen; member-bpwg@w3.org Subject: Re: Questions/Plans for BP2 >As far as being practice, I don't know what more I need to say, as the list of MNO's supporting Push for content download etc covers probably 80% or more of the world's mobile population, and that Push is a key method in a variety of browser-based services that they offer. It doesn't take much research to find this out, but I understand that not being in that side of the business, that this may not be so clear to you. Bryan fwiw I think this point is frankly irrelevant and a distraction from the overall point that it is in practice impossible for a content provider to sign up to 80% of the worlds 350+ gsm operator programmes to send PSMS, WAP Push or whatever. So let's not include advice saying that it in any sense practical to do this, and let's make sure we say that if you find a way to do it, in your budget etc. then it's definitely good practice. Though on reflection, if this advice appeared without suitable caveats then I would think that it was really not helpful. Jo Sullivan, Bryan wrote: > Sean, > The BP "[USE_PUSH_METHODS] Use Push Methods to Reduce Pull Traffic" is > already included. Certainly I can provide further info on "how to do it" > but ultimately there is a task of discovery that a developer needs to > fulfil, like any technical aspect of a web application. Beyond the basic > education that "this is a good technique to use", the developers will > need to research and reach out if they need help. > > As far as being practice, I don't know what more I need to say, as the > list of MNO's supporting Push for content download etc covers probably > 80% or more of the world's mobile population, and that Push is a key > method in a variety of browser-based services that they offer. It > doesn't take much research to find this out, but I understand that not > being in that side of the business, that this may not be so clear to > you. > > Best regards, > Bryan Sullivan | AT&T > > -----Original Message----- > From: Sean Owen [mailto:srowen@google.com] > Sent: Friday, May 16, 2008 11:06 AM > To: Sullivan, Bryan > Cc: Bruno von Niman; member-bpwg@w3.org > Subject: Re: Questions/Plans for BP2 > > Yes I'm not trying to invent some rule that one can only speak of things > here that are free or open or what have you. There's no such > restriction. I imagine "free" and "open" correlates with "widely used in > practice by many developers", and the latter *is* important to us, we do > have a rule about talking about "best practices" of course. > > My concern is not so much whether it is open but whether it is > frequently used, whether it's practice. I'm not saying it isn't and I > think it's a legitimate area for a best practice. I do think we need to > think about the audience, which is Joe Q. Developer, primarily. We can > write a BP on this, but if Joe can't implement it, well, it's not > harmful but not useful. But here I personally am quite open to the idea > that some non-trivial subset of developers out there can and do use the > technology, that it is in fact accessible, and therefore I'd welcome a > written BP on this. > > On Fri, May 16, 2008 at 1:32 PM, Sullivan, Bryan <BS3131@att.com> wrote: > >> Sean, >> There are many things that Joe Q. Developer would not have access to >> unless he was a member of some community/partnership (e.g. have their >> web application signed so that it gets certain privileges on >> Operator-provided mobile devices, or have their server trust >> established so it can participate in an Identity Management >> framework). If we limit ourselves to just what the guy off the street >> can do, we do not serve the majority of the Content Providers out >> there that actually do have relationships with Service Providers >> (whether Mobile Network Operators or Internet Portal Operators). I >> think BP2 should support the notion of community, not just anarchy. >> With community comes access to tools and services. And there are many >> types of community, not just those of MNO's. >> >> Also there are Service Providers that offer WAP Push service (and SMS, >> > > >> MMS, etc) to unaffiliated developers, and may act as aggregators for a >> > > >> variety of MNO's, according to the business relationship of the >> Service Provider with the MNO. The service provided may be limited by >> policy, but that goes for almost any function that is useful but needs >> > > >> to be managed (e.g. location API's on devices). >> >> Best regards, >> Bryan Sullivan | AT&T >> > >
Received on Friday, 16 May 2008 23:08:27 UTC