Re: Rechartering Device APIs & Policy Working Group

Dom,

Some specific feedback from AT&T is below. I will gather additional feedback
from implementers of the APIs and security policy framework which inspired
the work in DAP (the one submitted by OMTP as BONDI) and which has is now
near release by WAC as the WAC 2.0 release (for which there are several
implementations already, and there will be numerous implementations on the
market in very short order). This work in WAC 2.0 is expected to be
submitted to DAP in the near future, and we intend it to greatly move the
discussion in DAP (both on APIs and policy) back toward the original vision
of DAP as reflected in its current charter (APIs supporting a diverse set of
device types and use cases, with related diversity of requirements and UI
paradigms, for which API designs and security/privacy support may not fit
neatly into the conventional desktop Web browser, design model).

My specific comments so far are that these APIs should remain in scope:
- Application Launcher API should remain in scope.
- Communication Log API should remain in scope.
- Gallery API
- User Interaction API (API to to manage vibration, beeps, and menus)
- A policy framework that would allow using the defined APIs into a
different security environment than the default browser context

These are the major concerns AT&T has with the proposal. Of the APIs and
features above, we now have several implementations of:
- Communication Log API (WAC Messaging API, with inbox read and subscribe
operations)
- User Interaction API
- Security policy framework, including major advancements in privacy (based
upon W3C's POWDER spec and supporting the objectives of the privacy-related
discussions in DAP)

You may ask yourself, OK if these things are done, why were they not done in
W3C? For the same reason that vendors of major Web browsers (which are only
one type of Web-enabled application platform) work on new features prior to
bringing them to W3C. The discussions in W3C can easily veer off-track while
one is actively focused on creating the prototype of an idea in order to
serve real, current market needs. Active work in W3C depends upon resources,
and we did not expect our focus on meeting market needs with an evolution of
the JIL and BONDI specs to create the environment in which DAP could veer
off-course, but that is what has happened. Focusing on the market is exactly
what OMTP did in BONDI (with commercial implementations in the market) and
WAC has done with WAC 1.0 (also in the market) and WAC 2.0. Our focus on
serving the market's needs, *now*, limited our resources for DAP in the last
year. Prior to that, DAP was really just getting off the ground, finding its
feet. As well, in the last year, we supported the open discussion of
alternative API and security design approaches (ala Powerbox and the
HTML-based API designs). We also supported Web browser vendor participation
by accommodating (with clearly expressed reservations) their splitting of
the APIs in the "read" vs "write" (based upon the claimed inability to
express the write function in their UI paradigms).

These accommodations may have been interpreted as a sign that a Web browser
centric design pattern would be adequate (though it will not be). Thus in
the last year we have seen significant erosion of the design of the DAP APIs
relevant to the original vision of the group (as noted above). The time is
right to correct the course, and bring the work to DAP that will restore (or
at least broaden) the API specifications and work on security/privacy to the
original vision we had for DAP.

I will reach out to the numerous web runtime (WRT) vendors who will be
implementing the WAC specs to provide W3C firm evidence of market support
for the API functionality design and security/privacy concept of WAC. I ask
that you also provide the specific feedback that you received from vendors
(presumably desktop Web browser vendors) which has resulted in such a shift
in the DAP charter as you propose. Or at least, I hope these vendors can
provide comments on the DAP list which substantiate their positions
(including what market segments / use cases they are basing those positions
on).

There is a wider Web beyond the browser, and our vision for DAP was to
develop specifications that can serve it. We hope that W3C will share this
vision, but at least will provide evidence that the market will, as you will
see for yourself very soon in the market as WAC 1.0/2.0, and can already see
with the commercially available BONDI and JIL implementations.

Bryan Sullivan | AT&T


On Wed, Feb 2, 2011 at 6:09 AM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> Hi,
>
> The current charter [1] of our Working Group will expire at the end of
> June this year; it is pretty clear that our work will not be done by
> then and thus will need to extend or renew our charter.
>
> Given that our understanding of the work that needs to be done has
> evolved quite a bit, and also due to the lack of involvement of
> potential implementors of our work in the group, the Chairs and Staff
> Contacts are suggesting that we should try to refine our charter and
> have it reviewed by W3C Advisory Committee.
>
> To that end, I've been working on a proposed new charter for the group:
> http://www.w3.org/2010/11/DeviceAPICharter.html
>
> This charter introduces several important changes — which are all up for
> discussion.
>
> The most important change is the removal of the Policy Framework as a
> deliverable of the group. That proposed change is motivated by the
> following reasons:
> * the work has only had limited traction in the group so far,
> * the policy framework is architecturally independent of the APIs, while
> its bundling with our work on APIs has been the source of
> misunderstandings from potential implementors.
>
> To reflect the removal of the said framework, we're proposing to rename
> the group to "Device APIs Working Group" — although the group would
> still be referred as DAP since that's now a well-known moniker.
>
> The removal of the Policy Framework doesn't mean that the group would
> stop working on security. On the contrary, the new charter puts a strong
> emphasis on the needs surrounding security and privacy (privacy which
> was actually missing from the previous charter.) We've already received
> feedback that the current wording around security isn't satisfying and
> welcome proposed changes to the text.
>
> Finally, the new charter tightens the scope of our APIs to reflect the
> ones we've actually been working on — the very broad scope of our
> current charter has been an explicit showstopper for some W3C Members to
> join the group.
>
> You can see a diff between the two versions of the charter at:
> http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2009%
> 2F05%2FDeviceAPICharter&doc2=http%3A%2F%2Fwww.w3.org%2F2010%2F11%
> 2FDeviceAPICharter.html
>
> We very much welcome feedback and suggestions on this new charter, which
> will also be discussed during our F2F in Seoul.
>
> Dom
>
> 1. http://www.w3.org/2009/05/DeviceAPICharter
>
>
>
>