These are the final results of the Community Draft Reconsideration Ballot for JSR #177. The Executive Committee for ME has approved this ballot.
JSR177
StageCommunity Draft Reconsideration Ballot
Ballot durationJun 17, 2003 to Jun 23, 2003
Votes

ME

BEA Systems
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 Ericsson Mobile Communications AB
Sony International (Europe) GmbH
Sun Microsystems, Inc.
Symbian Ltd
Texas Instruments Inc.
Vote Log

ME

On 2003-06-23 Nokia Corporation voted No with the following comment:
Unfortunately this JSR does not include the basic cryptography API which is needed to implement encryption in CLDC devices.
We have very much concern about the proposed solution to include JCE crypto API into the JSR-219 - Foundation Profile for CDC devices. We do not think that this provides a solution for CLDC/MIDP.  JSR-219 does not commit to provide that - only "to consider a subset of JCE". And even if it were there in JSR-219 it is not said to be as a separate optional package. Furthermore, the availability (commercial and technical) of the TCK for this API for CLDC/MIDP environment has not been committed nor indicated, which does not promise timely availability of it. We think that JSR-177 is the right place to include CLDC/MIDP focused crypto specifications, to target both configurations, not CDC specifications.
Nokia's vote is based on the technical merits of this JSR and not on the licensing terms.  Still, Nokia wants to express 
its support for license models that foster an open environment for and wide acceptance and adoption of Java specifications. 
Nokia believes that competition in implementation of Java technologies is best served through license models that are simple, predictable and affordable for a wide range of implementors. 


------------------------------------------------------------------------------
On 2003-06-23 Sony Ericsson Mobile Communications AB voted No with the following comment:
We see a lack of cryptography API in this JSR.
We see that it is very unclear how this can be better delivered by the JSR-219.

Our "No" vote is based on technical merits even though we also agree with Nokia that the best licensing terms for an open standard is ensured by having simple, predictable and affordable licensing terms.

We acknowledge the fact that Sun has made an effort in terms of licensing even though it is not enough to make simple, predictable and affordable licensing terms.
------------------------------------------------------------------------------
On 2003-06-23 Insignia Solutions voted No with the following comment:
Insignia is voting "no" on this JSR primarily given the concern with the lack of implementation of crypto APIs for CLDC and the unclear method (due to 219 langauge) of shifting that effort to 219. "No" votes from Nokia and SE, two of the major phone vendors, also affect our position.

Although progress has been made toward more predictable business models, the hybrid language of this JSR's business terms leaves the terms more unclear than before. 
------------------------------------------------------------------------------
On 2003-06-23 Philips Electronics UK Ltd voted Yes with the following comment:
I also share the concern about the absence of a crypto library in this JSR and believe there is a good case to do such a library in this JSR and not in -219. However, I don't see this flaw as being serious enough to vote against this JSR at this point since as far as I can see, if the JSR fails this vote it is dead & work must re-start with a new JSR.
------------------------------------------------------------------------------
On 2003-06-23 Matsushita Electric Industrial Co., Ltd. voted Abstain with the following comment:
About this JSR's matter, I do not necessarily think that work must re-start with a new JSR.
However, we also share the concern about cryptography library in this JSR, as to implementation of APIs for CLDC especially.
------------------------------------------------------------------------------
On 2003-06-23 Motorola voted No with the following comment:
Motorola votes no on this JSR because the crypto API issues are not resolved in a manner that ensures a solution suitable for CLDC as raised by Nokia and IBM.
JSR-177 does not include the basic crypto API necessary for CLDC devices and JSR-219's commitment to provide a suitable solution is not defined. It is probably a worse action to approve this JSR in its current state with only a partial solution then to re-address the issues now. The securities and trust JSR should completely define the implementation and include the comprehensive TCK rather than to separately address a fundamental part of the implementation through another JSR. Motorola supports a licensing model that facilitates a wide acceptance of Java standards. We believe this is best served through affordable license models focused on cost recovery of the TCK efforts. 

------------------------------------------------------------------------------
On 2003-06-23 Siemens AG voted Yes with the following comment:
Siemens votes "Yes" but shares the concerns regarding the basic cryptography API and JSR-219. We also think that JSR-177 should include CLDC/MIDP focused crypto specifications. 
Our vote is based on the technical merits and to let the JSR go on to address the given concerns by the EC until the final approval ballot. 
We welcome the update of the license terms. However, for the final approval ballot we would like to see simpler and clearer licensing terms of this JSR, terms being predictable and affordable.


------------------------------------------------------------------------------
On 2003-06-23 PalmSource, Inc. voted Yes with the following comment:
PalmSource votes "Yes" but shares the same concerns mentioned by nearly every other EC member: there is no allowance for a basic crypto API, and there needs to be one before the FAB. JSR 219 is not the correct vehicle for a CLDC-related security change. 
------------------------------------------------------------------------------
On 2003-06-23 Texas Instruments Inc. voted Yes with the following comment:
We are confident that the Spec Lead understands the issues with the current spec that have been identified in the Community Review and will address them prior to the Final Draft. We are concerned about the management and development of the crypto API and urge the spec lead to reconsider the decision not to include this in JSR-177. The Spec Lead should insure that options other than JSR-219 are considered for development of the crypto API and that community consensus is achieved for this.
------------------------------------------------------------------------------
On 2003-06-23 BEA Systems voted Abstain with the following comment:
We share the concerns of the CLDC consumers that JSR 219 would need to serve both CDC and CLDC while defining APIs for its profile.  These would seem to complicate the work and the extremely agressive planned schedule of JSR 219. We are also uncomfortable with profile JSRs defining new APIs.

On the whole, if the JSR 177 EG does not want to do the security APIs that much of the EC expected, alternative solutions need to be explored rapidly for the good of the J2ME community.

We also note that the name of this JSR is misleadingly broad, and suggest consideration of renaming.

------------------------------------------------------------------------------
On 2003-06-18 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-06-20 Research In Motion, LTD (RIM) voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-06-21 Symbian Ltd voted Yes with the following comment:
Symbian is concerned about the scope of this JSR. 

We are approving the JSR on the basis that (1) JSR219 will deliver a crypto library suitable for CLDC 1.1, (2) The specification is reworded to clarify its independence from a particular storage element, and in line with the aspirations stated in the Reconsideration Ballot Release Note and the Community Review Note.

We also strongly recommend that the specification include appropriate use cases and examples.

------------------------------------------------------------------------------