The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy
JSR #180
SIP API for J2ME^TM
JSR Review Ballot
Ballot duration: 2002-03-26 to: 2002-04-08
These are the final results of the JSR Review Ballot for JSR #180. The Executive Committee for ME has approved this ballot.
Votes

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
Icon Legend
Yes
No
Abstain
Not voted
View Vote Log

On 2002-04-08 Zucotto Wireless voted Abstain with the following comment:
Zucotto abstains from voting on JSR 180 and echos the comments of other EC members that the work on SIP related activities must be well co-ordinated to ensure compatibility. It does seem that there are issues surrounding existing SIP JSRs and incompatible approaches between big and little Java editions (SE / ME). While expert groups are the right place to resolve these, there are a plethora of JAIN expert groups in place now and we hope JSR-180 will work with these groups to not only ensure compatibility, but to educate them to the unique requirements of resource constrained wireless devices if required.

This JSR also highlights two aspects of process the we believe the EC must address:

* JSRs that span big and little Java must be voted on and guided by both ECs and should have equal representation from each Java edition in the expert group
- it may be decided by the Expert group to split into separate sub-working groups due to very different target platforms, but interop and compatibility must be strived for

* EC members should have visibility into the JSR expert groups to monitor JSR progress to ensure deliverables are on track with respect to the original JSR goals and proposals voted on by the EC at the outset
------------------------------------------------------------------------------
On 2002-04-08 Motorola voted Yes with the following comment:
Motorola votes yes for this JSR, but shares many of the concerns others have raised. JSR-180 should be coordinated with the remaining JAIN technology community JSRs. This is a very active community with 26 JAIN related JSRs, so it's crucial that everything interfaces well. Nokia has indicated their commitment to work with other spec leads to resolve the issues. 
I hope we can all work together in the EC to develop a plan to better address technologies that overlap multiple Java editions.
------------------------------------------------------------------------------
On 2002-04-08 Sun Microsystems, Inc. voted Yes with the following comment:
It appears to Sun that the submitters of JSR-180 might have identified
gaps in the ability of existing SIP-related JSRs to meet the needs of
resource-constrained wireless devices (for example, using footprint-
intensive design concepts such as interfaces and factories).  Questions
have also been raised such as whether JAIN Lite is properly aligned with
CLDC/MIDP.  On some of these issues there appears to be true disagreement
between experts.  We think that questions like these are best resolved by
an expert group.

As we approve of JSR-180 to fill gaps in the existing portfolio of SIP
support, and not as a clean slate, we are very concerned at the lack of 
clarity about the positioning of JSR-180 vis a vis other SIP APIs.  We
think it is critical and necessary for the success of JSR-180 that first
priority be given toward effective communication between the JSR-180
proponents and the JAIN and J2ME communities.  Those parties should help
the JSR-180 expert group to clarify and communicate the relationship
between its work and that of JSRs 125, 164, and 165.  Certain technical
issues need to be resolved as well, for instance whether the API
suggested by JSR-180 is at an appropriate level for maximum flexibility
of implementation.
------------------------------------------------------------------------------
On 2002-04-08 IBM voted Abstain with the following comment:
We see SIP as important to J2ME. We would like to see progress made on resolving/converging the different Java/JCP activities around SIP.
------------------------------------------------------------------------------
On 2002-04-08 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-04-08 Texas Instruments Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-04-08 PalmSource, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-04-08 Ericsson Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-04-08 Siemens AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-04-05 Insignia Solutions voted No with the following comment:
Matsushita & Philips raise significant concerns 
over the relationship to a number of other JSRs
and these should be considered in more detail
and the JSR proposal amended and re-submitted.
------------------------------------------------------------------------------
On 2002-04-05 Philips Electronics UK Ltd voted No with the following comment:
The core of the argument in the JSR proposal form for JSR-180 is that all the existing JSR's for SIP (125, 164 and 165) are wrong for CLDC or don't have quite the right features. This may or may not be true - I'm not sufficiently familiar with the domain to have a really solid opinion on several of these arguments. What is however apparent from the Matsushita comments when voting 
against JSR-180 (and from private discussions with several parties) is that the arguments in the JSR proposal do not seem to have been really discussed with the people working on these existing JSRs.

If JSR-125 is believed to be too big for CLDC then perhaps this should be raised there before designing a whole new API from the ground up. JSR 125 has just had it's community draft ballot and in the comment log, the Nokia comment makes this observation but then goes on to say that "this is fine" because the main target of 125 is J2SE/EE. Personally I would have found a comment along these lines rather more constructive - "please either address this or indicate that it will not be addressed so that a JSR for a SIP API for CLDC can be submitted".

If JSR's 164/165 are too protocol specific then IMHO structuring those as a protocol independent part and a protocol dependent part should be discussed there before designing a whole new API from the ground up.

This does not mean that I agree with all Matsushita's points and reject all of Nokia's. The community draft version of JSR-125 does feel a little large to me for CLDC. It's quite possible that it requires a more fully featured SIP protocol stack than is reasonable for CLDC. I certainly agree with the Nokia concern about 164/165 being overly protocol specific given 
that there are a variety of protocols used for IM.
------------------------------------------------------------------------------
On 2002-04-04 Matsushita Electric Industrial Co., Ltd. voted No with the following comment:
1)  JSR 180 is a SIP API for J2ME. Therefore it overlaps with the charter of  JSR 125 (JAIN SIP Lite). The latter targets also a Java SIP API for 
J2ME as well.

2) Such an overlapping could have been handled via a fruitful discussion with the Spec Lead and the Expert Group of JSR125. 

3) JCP is a community process. So far, all the SIP APIs are within the JAIN community. From a community perspective, this should have been 
socialized and positioned in collaboration with the JAIN Team and the JAIN Community to have a consistent picture and perspective of all the 
JAIN SIP APIs.

4) From a technical standpoint  JSR 180 has the same  aim as JSRs 125 and 32. They all aim to provide an API for a SIP protocol stack. The 
technical problem with the proposal of JSR 180 is that the proposed API is very low level (at the transaction level). The proposal aims to mimic the HTTP connector model of J2ME. However, SIP stacks generally come with high level APIs. Therefore, there is a problem with the abstraction level of the proposed API. Hence, its  usefulness and applicability are 
questionable.

5)  JSRs 164 and 165 are also strongly related to SIP. The proposal does 
not take into account the requirements of these 2 JSRs in terms of  SIP 
for J2ME. The proposal could have benefited by talking to the  expert 
groups of JSRs 164 and 165 before advancing such a proposal.
------------------------------------------------------------------------------
On 2002-04-02 Research In Motion, LTD (RIM) voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-03-29 Nokia Corporation voted Yes with no comment.
------------------------------------------------------------------------------