 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 120: Wireless Messaging API
Updates to the Original Java Specification Request (JSR) Note that the JSR title was changed to "Wireless Messaging API" from "Wireless Telephony Communication APIs". Maintenance Lead: Marquart Franz E-Mail Address: marquart.franz Telephone Number: +49 89 636 48767 Fax Number: +49 89 636 45450
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Siemens ICM Name of Contact Person: Jan Eichholz E-Mail Address: Jan.Eichholz@mch.siemens.de Telephone Number: +49 89 722 21405 Fax Number: +49 89 722 53164 NOTE that this information has been updated from this original request. Specification Lead: Jan Eichholz E-Mail Address: Jan.Eichholz@mch.siemens.de Telephone Number: +49 89 722 21405 Fax Number: +49 89 722 53164 Initial Expert Group Membership: Siemens Section 2: Request
2.1 Please describe the proposed Specification:The purpose of this JSR is to define a set of optional APIs
that provides standard access to wireless communication resources. This
will allow 3rd party developers to build intelligent connected Java applications.
The following technologies will be addressed:
The CBS API should allow Java applications to receive cell broadcast data. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2ME 2.3 What need of the Java community will be addressed by the proposed specification?The intention of this JSR is to offer a set of reusable components for wireless communications that can be used singly or in any combination within any J2ME profile. 2.4 Why isn't this need met by existing specifications?None of the existing APIs within J2ME and J2SE are addressing the covered functionality. These APIs are completely new within J2ME. 2.5 Please give a short description of the underlying technology or technologies:see 2.1 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)TBD 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?Depends on the availability of the appropriate capabilities of the device. 2.8 Are there any security issues that cannot be addressed by the current security model?This JSR does not cover security issues.
2.9 Are there any internationalization or localization issues?No 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.Q3 2002 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.Java Community Process
system (Phase 2); Numbering, addressing and identification (GSM 03.03 version 4.11.0) (Phase 2+); Unstructured Supplementary Service Data (USSD) - Stage 1 (GSM 02.90 version 7.0.0 Release 1998) (Phase 2+); Unstructured Supplementary Service Data (USSD) - Stage 2 (GSM 03.90 version 7.0.0 Release 1998) (Phase 2+); Alphabets and language-specific information (GSM 03.38 version 6.0.1 Release 1997) (Phase 2+); Technical realization of the Short Message Service (SMS); (GSM 03.40 version 7.4.0 Release 1998) (Phase 2+); Mobile radio interface layer 3 supplementary services specification; Formats and coding (GSM 04.80 version 7.3.0 Release 1998) system (Phase 2+); Unstructured Supplementary Service Data (USSD); Stage 3 (GSM 04.90 version 7.0.1 Release 1998) 3.2 Explanation of how these items might be used as a starting point for the work.TBD |
