These are the final results of the JSR Review Ballot for JSR #190. The Executive Committee for ME has approved this ballot.
JSR190
StageJSR Review Ballot
Ballot durationJul 16, 2002 to Jul 29, 2002
Votes

ME

BEA Systems
Cisco Systems
Ericsson Inc.
IBM
Insignia Solutions
Matsushita Electric Industrial Co., Ltd.
Motorola
Nokia Corporation
PalmSource, Inc.
Philips Electronics UK Ltd
Research In Motion, LTD (RIM)
Siemens AG
Sony International (Europe) GmbH
Sun Microsystems, Inc.
Texas Instruments Inc.
Zucotto Wireless
Vote Log

ME

On 2002-07-29 BEA Systems voted Abstain with the following comment:
We agree with concerns raised by IBM, Motorola, and Matsushita, but feel that the position of this work still needs to be determined (thus agreeing with Sun to some extent).  Coordination with other JSRs for both overlap of scope and consumption of (e.g.) security features, and the comments should be incorporated in the work of the Expert Group should this version of the JSR pass.
------------------------------------------------------------------------------
On 2002-07-29 Sun Microsystems, Inc. voted Yes with the following comment:
Sun is voting 'yes' on this JSR despite sharing many of the misgivings
expressed by other EC members.  We recognize that the JSR as written is
not clear about the problem to be solved or the proposed approach to
solving it.  It will be essential to the future success of the JSR that
this is remedied, but we don't want to set a standard that requires an
idea to be fully worked out prior to formation of an Expert Group.  We
think that the JSR is trying to get at a real concern, and are OK with
the Expert Group refining the charter and proposing details of a solution.
At the same time we recognize that the EC has recourse should no adequate
response be developed.

We also appreciate that this JSR might interact with other JSRs, and that
those interactions aren't detailed in the JSR.  Again, we would need to
see this spelled out for the JSR ultimately to be successful, but don't
want to assume that this has been done fully at JSR submission.

It does seem plausible that, to reduce fragmentation, the best place for
this functionality will be as part of another component of the J2ME stack.
It might be absorbed into a future MIDP version or be part of a stack
recommended by JSR-185.  However, nothing precludes the work from being
done as a separate JSR, and incorporated or referenced later.

We encourage the Spec Lead to be proactive in addressing the various EC
comments made during voting, whatever the outcome of the vote.
------------------------------------------------------------------------------
On 2002-07-29 Sony International (Europe) GmbH voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-29 Motorola voted No with the following comment:
There are several areas that need to be addressed as a part of the Java Technology for the Wireless Industry that we are working on in this group, including the Event tracking, service support, multiple device support etc.  Maybe this proposal should become part of the extension of existing JSRs (e.g. JSR 118, JSR 124, JSR-172).

My concern is that with submission (and approval) of JSRs like 190 which are optional, some handsets and some provisioning systems would support it but not all. This would then increase the fragmentation that we are all trying to prevent.

There is definitely a need for a standardized billing mechanism, but the management of the billing event records needs to be outside of the application itself, ideally integrated with DRM/license management. 

Another area of concern is the potential need to do code injection that will complicate code signing and app deployment.

Perhaps this JSR would be better considered as an LOC/LCC scope proposal. It might also fit into an OAM (Operations, Administration, and Maintenance) based on web services in the future, but as it exists it does not provide sufficient benefit to warrant a separate JSR.
------------------------------------------------------------------------------
On 2002-07-29 Zucotto Wireless voted Yes with the following comment:
Zucotto agrees with the need for the proposed API but is concerned about security issues around storing and transmitting events and this should be well co-ordinated with JSR-177. In addition, there may be some interactions with MIDP 2.0 that should be carefully explored to avoid duplication of functionality.
------------------------------------------------------------------------------
On 2002-07-29 IBM voted No with the following comment:
We would like to see more information and clarifications on the  intent of this JSR and its interaction with other JSRs.  Even with the additional clarifications provided during the review, several issues remain.  As Matsushita pointed out, some events may be more suitable for JAM/AMS.  There may be some overlap here with JSR 118 "MIDP NG".  In addition, we would like more consideration for implementing Event Tracking through Web Services (JSR 172).  Could Event Tracking be done as a Web service (or a set of Web services), using the "notification" and "RPC" interaction models.  In addition, does it make sense to limit Event Tracking to J2ME applications?  Why would this function not also be applicable for J2SE-class applications?  Furthermore, we share the concerns raised about the security of the event data; both RMS persistent storage and the http transport need to be secure.  We hope these issues can be considered and we welcome this JSR to be resubmitted. 
  
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction.   This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
------------------------------------------------------------------------------
On 2002-07-29 Ericsson Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-29 Siemens AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-29 Insignia Solutions voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-29 Matsushita Electric Industrial Co., Ltd. voted No with the following comment:
Matsushita supports the idea that event-tracking provides contents providers with a good solution for the billings, games and the application updating.
 But We have a few concerns about the JSR190.

1) We think that some kind of events like update notification, revocation and even utility time, usage count should be dealt with by JAM/AMS.  MIDP2.0 OTA provisioning specification also supports installation/deletion Status report by using JAM/AMS.  As to update notification it is helpful for user to be notified before starting an execution of application rather than after it.

And as to utility time and usage count, it is questioning that the recorded data with APIs is meaningful.  Because the execution of application may be suddenly stopped by user and interruption from mobile phone's native functions. in that case, application may miss the opportunity of recording events and the data may be not exact. Meanwhile JAM/AMS can collect the exact data rather than application-level collecting.
JSR190 should reconsider the role between JAM/AMS and API for event tracking. And JSR190 should have discussions of this topic with JSR118(MIDP) EG.
    
 2) The second is about the way to store events. The JSR190 APIs plan to store the record of event into a persistent store like RMS of MIDP. But application can also access that area.
 We believe JSR190 should protect the recorded data against applications.
 This kind of security model should be taken into consideration in the JSR190.
 We vote "No" at the moment, but we hope the spec lead clarify the above concerns and resubmit.
------------------------------------------------------------------------------
On 2002-07-25 Cisco Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-23 Research In Motion, LTD (RIM) voted Yes with the following comment:
This JSR seems to come under the view of a few companies standardizing similar Java APIs in the hope that more J2ME app writers will use the standardized API.  The API will be Java-only and will require app writers to explicitly call notification methods, etc.; I'm not sure whether something like this will be successful (widely adopted) but it seems reasonable since the app writer will be motivated to use the API to receive compensation.

I'm including some Q&A I had with the spec lead since this info might be useful to others.
>>>
Q: Is this JSR related to JSR124?
A: Thanks for your feedback.  I'm a member of the JSR124 expert group as well so I can comment on this. 

JSR124 mainly deal with issues surrounding provisioning or downloading of applications.  JSR190 mainly deals with "post-provisioning" issues.  For example, a mobile operator may choose to employ value based pricing (charge end users on a 'per use', 'per time-spent', 'per packet' or 'per game level' basis).  To achieve this, the application itself will need to generate 'events' that the billing system understands.  Another example is collecting user rating and high score of the applications.

Currently provisioning vendors are using their proprietary API to achieve these goals.  Not only does it complicate the provisioning/certification process, it also blots the size of the application significantly.  This specification is attempted to address this need by creating a standard.  

Q: Is this a Java-only solution or will it require access/changes to a device's JAM/AMS which is often written in native code?

A: I envision this to be a J2ME only solution.  Provisioning vendors and application publishers (like Tira Wireless) are already doing this by instrumenting MIDlets in their own proprietary way using existing MIDP/CLDC 1.0 APIs, JSR190 is simply trying to standardize it.
 
As JSR190 deals with application events only, there is no need to integrate with JAM/AMS.
<<<
------------------------------------------------------------------------------