W3C home > Mailing lists > Public > public-bpwg@w3.org > May 2008

RE: Questions/Plans for BP2

From: Sullivan, Bryan <BS3131@att.com>
Date: Fri, 16 May 2008 16:07:41 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD09B3F185@BD01MSXMB015.US.Cingular.Net>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:58 UTC