• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2013.08.02: Panasonic Corporation has become the Maintenance Lead.

Maintenance Lead: Minoru Okamoto

E-Mail Address: okamoto.minoru@jp.panasonic.com

Telephone Number: -

Fax Number: -

2007.01.22: Alan Kaplan replaced John Buford and Mourad Debbabi as Spec Lead.

Updates to the Original JSR

The following has been updated from the original request.

3/16/05 - Changed JSR name from JAIN^TM Instant Messaging to Instant Messaging.

Original Summary: JAIN^TM Instant Messaging is a protocol agnostic API for Instant Messaging. It provides a standard portable and secure interface to control, manage and manipulate instant messages between clients through the use of presence servers.

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Panasonic Information and Networking Technologies

Name of Contact Person: Dr. Mourad DEBBABI

E-Mail Address: debbabim@research.panasonic.com

Telephone Number: +1 609 734 7329

Fax Number:+1 609 987 8827

Specification Lead: Dr. Mourad DEBBABI

E-Mail Address:debbabim@research.panasonic.com

Telephone Number: +1 609 734 7329

Fax Number: +1 609 987 8827

Initial Expert Group Membership:

o Panasonic Information and Networking Technologies Laboratory.

o Sun Microsystems

o Teltier Technologies

. o Motorola.

Supporting this JSR:

o Panasonic Information and Networking Technologies Laboratory

o Sun Microsystems

o Teltier Technologies

o Motorola

Section 2: Request

2.1 Please describe the proposed Specification:

This JSR aims to elaborate JAIN^TM Instant Messaging, a protocol agnostic JAIN^TM API for Instant Messaging. JAIN^TM Instant Messaging is intended to be the standard API to implement Instant Messaging applications and services for both IP and legacy based networks. It is expected to be bound to a plethora of messaging and transport protocols such as SMS, MMS, WAP, WSP, HTTP, HTTPS, etc. Due to its protocol neutrality, JAIN^TM Instant Messaging will be deployed in the existing and future, wire-line and wireless networks.

As for developers, JAIN^TM Instant Messaging is intended to provide a standard framework for developing and deploying new Java Instant Messaging applications and services without a prior knowledge of the underlying protocol. Moreover, these applications and services can be deployed in any implementation of JAIN^TM Instant Messaging. Furthermore, developers will be able to implement interoperable applications i.e. applications that can run over a wide variety of protocols such as Wireless village, SIMPLE, Jabber, AIM, MSN, Yahoo, etc.

With JAIN^TM Instant Messaging, rather than elaborating multiple Instant Messaging APIs for various protocols, vendors will be in a position to use a single standard API and bind it to multiple protocols. This will result in a significant reduction of the development efforts and an increased customer base.

Instant Messaging service providers could lower their maintenance costs by supporting a single Instant Messaging API. Since the API is to be standardized, this will ensure vendor independence.

JAIN^TM Instant Messaging is defined as a JAIN API because:

o Instant Messaging is a JAIN^TM Community abstraction.

o Instant Messaging correlates to other JAIN^TM APIs to build effective Java^TM communications services.

o The portfolio of JAIN^TM APIs includes protocol specific presence and instant messaging APIs.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The target platforms for JAIN^TM Instant Messaging are both the Java 2 Micro and Standard editions. The Micro Edition is meant to be the platform for thin client devices (primarily handsets). The Standard Edition is meant to be the platform for thick clients (PDAs, laptops, desktops, etc.).

2.3 What need of the Java community will be addressed by the proposed specification?

The main objective of the proposed specification is to provide the community of Java^TM developers with an API that allow them to develop a multitude of JAIN^TM compliant Instant Messaging applications. The protocol-agnostic nature of this API will allow the developers to write these applications without a prior knowledge of the underlying protocols.

Many presence and instant messaging protocols have been recently devised or are currently being designed such as Wireless village, SIMPLE, Jabber, AIM, MSN, Yahoo, etc. Some of these protocols are intended for legacy networks and others for IP telephony networks. There is a need for a high-level and standard API that can be implemented on top of the aforementioned protocols in both legacy and IP based networks.

2.4 Why isn't this need met by existing specifications?

The intent of this initiative is to elaborate a set of protocol neutral specifications for an API that provides capabilities for controlling and managing the use and manipulation of instant messages. As of today, there are no existing Java specifications that fulfill this need.

JAIN^TM SIMPLE Instant Messaging APIs are intended to be the standard APIs for instance messaging for SIP-enabled platforms and IP networks where SIP plays a major role. Industry leaders such as Microsoft and AOL are already committed to the use of SIP for Presence and Instant Messaging purposes. Though SIP and SIMPLE are promised for a bright future, it remains that legacy systems are not IP-based and therefore there is a need for other APIs that could interface with other presence and instant messaging protocols such as Wireless Village, Jabber, AOL, etc. Very special care should be then used in the elaboration of JAIN^TM Instant Messaging so as to make it applicable to both IP and non-IP networks and to both thin and thick devices.

2.5 Please give a short description of the underlying technology or technologies:

PAM is a server-side presence API elaborated by the PAM Forum. That Forum is an independent, non-profit consortium working on API specifications for Presence and Availability management. More specifically, PAM provides APIs for: Digital Identities, characteristics and presence status of agents (representing capabilities for communication and content delivery), capabilities and state of entities (such as location), and availability of entities for various forms of communication and the contexts in which they are available. The PAM specification does not specify any particular protocol for achieving the Presence service.

Wireless Village is an industrial consortium founded by Ericsson, Motorola and Nokia. It was formed to define a set of specifications for mobile Instant Messaging and presence services (IMPS). Those specifications will be used for exchanging messages and presence information between mobile devices, mobile services and Internet-based Instant Messaging services.

Jabber is an open, XML-based protocol for which multiple implementations exist. These implementations have been used mainly to provide Instant Messaging and presence services.

SIP is an IETF standard protocol for IP-communications, enabling IP-Telephony gateways, client endpoints, PBXs and other communication systems or devices to communicate with each other. SIP primarily addresses the call setup and tear down mechanisms of sessions and is independent of the transmission of media streams between caller and callee.

SIMPLE is a set of natural extensions made to the SIP protocol to support presence and Instant Messaging.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The package names being considered is:

javax.im:

This package would contain the capabilities needed to support the control and management of instant messages securely across applications.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.8 Are there any security issues that cannot be addressed by the current security model?

The proposed API needs to enforce the following security properties: authentication, secrecy, authorization and availability. Generally, authentication and secrecy are fully addressed by the Java security model. However, the API should provide guidelines on how to implement a mechanism to enforce authorization and availability. The expert group developing this specification is expected to research these issues and propose appropriate solutions.

2.9 Are there any internationalization or localization issues?

The expert group developing this specification will research the internationalization and localization requirements.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

2.11 Please describe the anticipated schedule for the development of this specification.

The anticipated schedule is:

Requirements: T0 + 4 weeks.

Architecture/design: T0 + 8 weeks.

Detailed design of the API: T0 + 16 weeks.

Reference implementation: T0 + 24 weeks.

Sample applications: T0 + 28 weeks.

TCK: T0 + 36 weeks.

Documentation: T0 + 40 weeks.

where T0 is the time at which the expert group starts working on the elaboration of this proposal.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

The anticipated working model will use:

A dedicated mailing list.

Monthly conference calls.

Quarterly Face-to-face meetings.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The PAM Workgroup. Parlay APIs 3.0: Presence and Availability Management (PAM), Class Diagrams. March 20th, 2002.

The PAM Workgroup. Parlay APIs 3.0: Presence and Availability Management (PAM), Data Definitions. March 20th, 2002.

The PAM Workgroup. Parlay APIs 3.0: Presence and Availability Management (PAM), Interfaces. March 20th, 2002.

The PAM Workgroup. Parlay APIs 3.0: Presence and Availability Management (PAM), Sequential Diagrams. March 20th, 2002.

The PAM Forum. PAM Specification Document Version 1.0. September 11th, 2001.

The Wireless Village Initiative: System Architecture Model. Wireless Village 1.0 Specifications, February 12th, 2002.

The Wireless Village Initiative: Features and Functions. Wireless Village 1.0 Specifications, February 12th, 2002.

The Wireless Village Initiative: Client-Server Protocol. Wireless Village 1.0 Specifications, February 12th, 2002.

The Wireless Village Initiative: Presence Attributes. Wireless Village 1.0 Specifications, February 12th, 2002.

The Wireless Village Initiative: Server to Server Protocol. Wireless Village 1.0 Specifications, February 12th, 2002.

The Wireless Village Initiative: Command Line Protocol. Wireless Village 1.0 Specifications, February 12th, 2002.

J. Miller. Jabber Internet-Draft. February 21st 2002.

K. Minkler. The Jabber Architecture. November 19th, 1999.

JAIN^TM SIMPLE Expert Group. JAIN^TM SIMPLE Presence. Java Specification Request Proposal 164. Java Community Process.

JAIN^TM SIMPLE Expert Group. JAIN^TM SIMPLE Instant Messaging. Java Specification Request Proposal 165. Java Community Process.

Rosenberg et al., SIP Extensions for Presence. IETF Draft of the SIMPLE Working Group, September 24, 2001, Expires: March 2002.

J. Rosenberg, D. Willis, R. Sparks, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, D. Gurle, D. Oran, SIP Extensions for Instant Messaging. IETF Draft of the SIMPLE Working Group, July 18, 2001, Expires: January 16, 2002.

B. Campbell, J. Rosenberg. SIP Instant Message Sessions. IETF Draft of the SIMPLE Working Group, July 13, 2001, Expires: January 11, 2002.

B. Campbell, J. Rosenberg. SDP Extensions for SIP Instant Message Sessions. IETF Draft of the SIMPLE Working Group, July 13, 2001, Expires: January 11, 2002.

SIMPLE WG, J. Rosenberg et al. An XML Based Format for Watcher Information. IETF Draft of the SIMPLE Working Group, July 13, 2001, Expires: January 2002.

SIMPLE WG, J. Rosenberg et al. A SIP Event Sub-Package for Watcher Information. IETF Draft of the SIMPLE Working Group, July 13, 2001, Expires: January 2002.

3.2 Explanation of how these items might be used as a starting point for the work.

Our strong starting point in this initiative is threefold:

Well-defined presence protocols defined by many consortia (e.g. PAM Forum, Parlay PAM Workgroup, Wireless Village, IETF SIMPLE Working Group, Jabber Software Foundation, etc). We intend to take into account the requirements of these protocols in the elaboration of JAIN^TM Instant Messaging API.

Well-defined JAIN^TM SIMPLE APIs. We gained valuable expertise in the elaboration of APIs for presence and Instant Messaging through the JAIN^TM SIMPLE JSRs. We plan to leverage such an expertise to elaborate JAIN^TM Instant Messaging.

Well-specified JAIN^TM Presence and Availability Management APIs (PAM). We participate actively as expert in the JAIN^TM PAM JSR (JSR 123, Service Provider Presence and Availability Management APIs).