These are the final results of the JSR Review Ballot for JSR #120. The Executive Committee for ME has approved this ballot.
JSR120
StageJSR Review Ballot
Ballot durationApr 17, 2001 to Apr 30, 2001
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.
WindRiver Systems
Zucotto Wireless
Vote Log

ME

On 2001-04-30 Zucotto Wireless voted No with the following comment:
While Zucotto Wireless acknowledges the need and importance of an API to allow Java application interfaces to cellular telephony features and messaging we don't believe the current proposal is complete enough at this time. We encourage a rework and resubmission with Siemens using their extensive Java and cellular expertise and working to include other industry leaders to ensure the proposal is generic enough to cover multiple wireless technologies not just GSM variants or is resubmitted clearly indicating it is a profile for GSM and GSM evolution (ex. 3GPP)devices. 
 
In addition we would encourage the proposers (of both JSR 120 and JSR 118) to consider the security framework proposals in the MExE working group. The resubmission should ideally also outline plans for co-operation between JSR 118 and JSR 120 and include details on timelines. 

We do also thank Siemens for the submission and raising of these important issues and look forward to working together on a Wireless API.
------------------------------------------------------------------------------
On 2001-04-30 WindRiver Systems voted No with the following comment:
* unclear relationship to MIDP NG JSR
* unclear whether profile will be available on CLDC, CDC or both
* not enough details for target dates for spec, RI, and TCK
* impacted also by uncertainty around JSR 68 - should the JSR be a profile, an optional component or a building block? A full profile effectively specs a platform which would be an unnecessary fragmentation of APIs even within one device category
------------------------------------------------------------------------------
On 2001-04-30 IBM voted No with the following comment:
We recommend that the spec lead refine the proposal to specifically outline the scope of the activity, and, assuming handsets are the main target, further address the WAP and MExE activities explicitly.  If there is any content related to network interconnections, then references to the appropriate function and JAIN JSRs should be included.
------------------------------------------------------------------------------
On 2001-04-30 Philips Electronics UK Ltd voted No with the following comment:
We believe what is needed is a JavaPhone-like API for J2ME/CLDC, which would work in perfect harmony with MIDP and with a fine-grain security model
supporting security domains, certificate management and authentication (as defined by the 3GPP MExE specification).

The JSR-120 does not fullfill these needs since it only proposes a limited set of APIs to support GSM SMS, GSM Broadcast Services (not supported by
Operators except in the UK) and GSM USSD (only used in Asia). Further, JSR-120 does not seem to want to address the security issues associated with these APIs (they would directly connect to some of the phone functionalities).

Since this API would not be complete as far as telephony functionalities are concerned, other APIs would probably be defined and we therefore believe that the adoption of JSR-120 would only lead to more complexity and confusions in the requirements from our the operators due to an
excessive fragmentation of the Java specification defined for mobile phone handsets.
------------------------------------------------------------------------------
On 2001-04-30 Nokia Corporation voted No with the following comment:
- now unclear whether generic or GSM specific (now in between!)
- should be named accordingly (generic/GSM specific)
- we should have generic API first to enable better (protocol etc.) specific ones
- if generic API, then it should follow MIDP NG framework
- security model specification must not be tied to specific devices -must be in line with MIDP NG
(- even if not requirement by JCP, all wireless device API RI/TCK should follow same licensing principles)
------------------------------------------------------------------------------
On 2001-04-29 Motorola voted No with the following comment:
This JSR, as written, does not answer Motorola's issues raised in the ME-EC mailing list.  Until these issues are addressed, or at least a workable plan is formed, we believe that it is not appropriate to vote yes on this JSR.

In addition, scope of the JSR is not properly defined with respect to networks (GSM only? GPRS, TDMA?, etc).
------------------------------------------------------------------------------
On 2001-04-27 Sun Microsystems, Inc. voted Yes with the following comment:
Sun acknowledges the thoughtful and constructive comments sent by several ME EC representatives, and agrees that many of these issues merit attention.  At the same time, we are confident that those issues local to JSR-120 can be handled appropriately by the expert group, and that the ME EC will have sufficient opportunity to monitor progress.  We do not think that issues outside the scope of this JSR should hold up its initiation.
------------------------------------------------------------------------------
On 2001-04-27 Siemens AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-04-23 Research In Motion, LTD (RIM) voted No with the following comment:
- application is very thin on details
- no mention of TCK development goals
- not clear in the application that this will
  be a general API applicable to any wireless connectivity
- is there an existing implementation the spec will be based on?
------------------------------------------------------------------------------
On 2001-04-18 Matsushita Electric Industrial Co., Ltd. voted Yes with no comment.
------------------------------------------------------------------------------