Re: Getting browser vendors involved prior to basing work on their products/ideas

OK, that would be useful, as it would remove roadblocks to us working faster
on these APIs.

Is that something Google could do for Web Introducer and Sensors at least
(e.g. if hypothetically the DAP Sensor API was inspired by the Android
Sensor API)?

How would their willingness to do that be determined? Would they "submit"
the specs to W3C for use by groups of which they are not a member, or to
specific groups?

On Wed, Apr 20, 2011 at 8:19 AM, Appelquist, Daniel, VF-Group <
Daniel.Appelquist@vodafone.com> wrote:

> Hi Bryan --
>
> I absolutely agree with you with regard to the IP provenance of inputs into
> the group.  Ideally these organizations should join the group.  However, if
> APIs are coming from non-(group)-members or even from non-w3c-members there
> is a precedent for submitters to make a separate royalty-free commitment
> regarding their submissions.
>
> Dan
>
> On 20/04/2011 16:10, "Bryan Sullivan" <blsaws@gmail.com> wrote:
>
> > In the call today during the discussion of the Web Introducer draft
> > (http://web-send.org/introducer/), I made the following points that it
> might
> > be useful to have email list discussion on.
> >
> > In the rechartering we are trying to create an environment attractive to
> > participation of the browser vendors, both in API scope/design and in
> > security/privacy approaches. We are making a good faith effort to address
> > their concerns. Hopefully actions are taking place in the W3C background
> to
> > promote participation of the browser vendors, as a result.
> >
> > However basing DAP APIs on APIs of non-members is problematic. This goes
> for
> > Web Introducer and Sensors as well.
> >
> > At this point there is an available API draft for sensors
> > (http://bondi.omtp.org/1.5/PWD-2/sensor.htm) which is RF (as part of the
> BONDI
> > project).
> >
> > I would like to consider the Google APIs as baselines but we need
> Google's
> > involvement in the group to move forward on that, IMO.
> >
> > For sensors, hopefully in the meantime we can find some neutral approach
> to
> > begin drafting an API.
> >
> > Bryan | AT&T
> >
> >
>