• 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.07.30: 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 Presence to Presence.

Original Summary: JAIN ^TM Presence is a generic and protocol agnostic API for Presence. It provides a standard portable and secure interface to control, manage and manipulate Presence information between Presence clients and 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 defines an API for presence. Presence is the notion of an entity being a part of a network. The entity can be a mobile device, a PC, a telephone, etc. Concepts important to Presence would be when an entity enters and exits a network, and relevant information about the entity such as location, duration, relationship to other entities, etc.

This JSR addresses Presence as viewed from the entity, that is, when and how a device enters and exits a network. JSR 123 - Presence, Availability, and Management (JAIN^TM PAM) address the needs and concerns of Presence for a server within a network. This JSR addresses the interfaces required for a client.

There are several industry specifications defining Presence based on protocols such as Wireless village, SIMPLE, Jabber, AIM, MSN, Yahoo! Etc. This JSR will define an interface agnostic to protocols. JAIN Presence is intended to be the standard API to write presence 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 Presence will be deployed in the existing and future wire-line, wireless, Internet, and broadband networks.

As for developers, JAIN^TM Presence is intended to provide a standard framework for developing and deploying new Java Presence applications without a prior knowledge of the underlying protocol. Moreover, a Java application that invokes JAIN^TM Presence can be deployed in any JAIN Presence compliant implementation. Furthermore, developers will be able to implement interoperable applications and services that can run over a wide variety of protocols as mentioned earlier.

Rather than elaborating multiple Presence APIs for various protocols, with JAIN Presence, 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.

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

JAIN Presence is defined as a JAIN API because:

o Presence is a JAIN^TM Community abstraction.

o Presence correlates to other JAIN APIs to build effective Java communications services.

o The portfolio of JAIN 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 Presence 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 client devices such as (PDAs, desktop and laptop computers, 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 developers with an API that allows them to develop a multitude of JAIN compliant presence applications and services. The high level nature of this API will allow the developers to rapidly write and deploy presence based applications and services without an in depth knowledge of networks and protocols. A protocol specific API is useful for architecting networks.

A high level protocol-agnostic API is useful for architecting services that run on top of networks.

Many Presence protocols have been 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. The need for high-level standard APIs that can be implemented on top of the aforementioned protocols is growing in proportion to the number of devices that are being added to both legacy and IP based networks.

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

The intent of this API is to provide capabilities for controlling and managing the use and manipulation of presence information between clients and servers. As of today, there are no existing Java specifications that fulfill this need.

JAIN^TM PAM (JSR 123) is a suite of server-side and protocol neutral APIs that are used to control the use, dissemination and availability of Presence information in a secure and safe environment. The PAM forum, the Parlay PAM Workgroup as well as the JAIN^TM PAM expert group did an excellent work in the development of these server-side protocol-agnostic presence APIs. Nevertheless, as mentioned before, PAM deals only with the server-side aspect of presence. In a real-life deployment, we need APIs that deal with both clients and servers.

JAIN^TM SIMPLE APIs are intended to be the standard APIs for Presence and Instance Messaging APIs for SIP-enabled platforms and IP networks where SIP plays a major role. The 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 promise a bright future, it remains that legacy systems are not IP-based and therefore there is a need for new APIs that could interface with other Presence protocols such as Wireless Village, Jabber, AOL, etc. Very special care should be then used in the elaboration of JAIN Presence 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:

As described before, this API will be agnostic to the underlying protocol, transport, or device. However, the JAIN^TM Presence implementations will be built on systems such as Wireless Village, Jabber, SIP, SIMPLE, and other presence based systems. The following is a description of the known industry presence standards, which will be a source of inspiration in the elaboration of JAIN^TM Presence:

* 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.presence

This package would contain the capabilities needed to support the dissemination and management of presence information securely across applications. This includes support for Presence user clients (buddy and buddy list manipulations, sending subscriptions, receiving notifications, etc.).

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 SIMPLE Expert Group. JAIN 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 Presence.

* Well-defined JAIN 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 Presence.

* Well-specified JAIN 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).