From: Sun Microsystems, Inc.

To: SMG4 MExE

Subject: "Followup to JavaPhone LS to MExE"

Sun Microsystems appreciates the consideration of Java Technologies for MExE standardization. Thank you for the request for clarification in the 4M99-085 correspondence. The questions are answered below:

  • MExE would like to suggest that JavaPhone reference JTAPI and JTAPI mobile, and also specify what parts are mandatory.
  • The JavaPhone APIs specify that the JTAPI core interfaces are required including the corresponding events, capabilities, and exception interfaces. The capabilities framework provides implementations with broad latitude in selecting the features that are supported. Applications use that information to determine what capabilities are available.
    • The JTAPI packages for call control, and phone are specified as being optional for JavaPhone.
    The call center and media packages are not expected to be immediately relevant to mobile terminals.
  • The JTAPI mobile package contains mobile equivalents for the basic objects in the JTAPI core for provider, terminal, and address. These are required for wireless devices. The objects supporting network selection and radio functions are required only for GSM environments.
  • JTAPI has several ways to do the same thing, and it is difficult for application developers to know how to use JTAPI. It would be beneficial if applications can make assumptions about the implementation of JTAPI and JTAPI mobile within the context of JavaPhone.
  • JTAPI is defined as an interface between the application and implementation and makes few requirements or assumptions about the implemention of either. This provides applications with great flexibility in how they are designed. Specific recommendations for design patterns and application use of JTAPI have not been established at this time. We may be able to make suggestions if the circumstances of the alternatives are described.
  • The task of simplifing the usage options would need to be undertaken by the ECTF. The surest path to simplify or identify terminal specific profiles will be to participate in the ECTF.
  • MExE may send further comments on the liaison statements, e.g. about the "required", or "optional" fields in Sun's Annex A: Personal Java 1.1.1 API Packages. It is our intention to have fully considered comments back to JavaPhone by the end of June.
  • Specific feedback about the applicability of the options in the wireless would be valuable input. In the current JavaPhone API schedule, these comments can be considered through the public review period currently planned to be open through mid July, 1999.
  • MExE security relies critically on secure interaction between the JVM and user profiles within the MExE terminal and the user. There are certain operations that applications should only be able to perform if they have been authorised explicitly by the user or implicitly by the user profile. Strict access control to the user profile for applications is also required. MExE will make their requirements in this area clear in an update to MExE API requirements doc, but for the present wish to give SUN advance notice on this issue. SUN are asked to inform MExE of their plans for developments providing the type of API functionality described above.
  • The Java Security manager provides a framework for checking some authorized functions. Current implementations of the PersonalJava specification do not have the ability to distinguish between various kinds of trusted applications. The framework does not support a generalized fine grained permission mechanism.
  • Several implementation techniques are available and can be used by equipment manufacturers to protect sensitive functions. Each subsystem implementing a sensitive function can perform its own checks as necessary. For example, if all calls made by a JTAPI based application required explicit user confirmation. The JTAPI implementation can include code to prompt the user before placing the call. If all JTAPI calls required confirmation then no additional information would need to be available.
  • Future PersonalJava releases will include a configurable fine grained security mechanisms.
  • MExE would like to see a more detailed description of the Datagram API.
  • This Datagram API provides for transport independent addressing and delivery of messages. Applications send and receive messages using addresses consisting of service name and service location. This allows applications to be developed independently of the physical network or bearer supported by the device. The physical network or bearer used to deliver the message is selected by the device when the message is to be sent. For example, on a wireless phone the WDP protocol can be used with the short message service can be used. The mapping between the service name, service address combination and the transport and physical address are maintained separately in the implementation of the Datagram API.
  • how SIM functionality, such as the pin code feature and SIM presence, is supported by JavaPhone?
  • The context of the question is unclear but it is expected that the implementation of the security mechanisms on a mobile terminal will utilize the SIM to verify the user before providing trusted functions. JavaPhone does not specify the details required of the various implementations. For example, the JTAPI implementation might utilize the normal CHV1 verification or equivalent before a call is placed.
  • how SIM phonebook, and associated call barring/activation, is supported by JavaPhone?
  • The SIM phonebook is expected to be made accessible through the AddressBook API as one of the selectable addressbooks. The details are implementation specific.
  • It is expected that the JTAPI implementation on the terminal will utilize the same verification and checks for call barring/activation used for any calls.
  • is mobile telephony network support optional, mandatory, or not supported?
  • The interfaces in JTAPI Mobile for network selection and radio functions are optional in non-GSMterminals.
  • how data calls are supported?
  • Data calls can be supported through the serial communications API with an implementation supporting modem functions.
  • Data calls can be supported for TCP/IP access using the existing java.net.
  • A specific data call API is not currently specified by JTAPI or JTAPI mobile.
  • does mobile telephony include SMS point to point and cell broadcast?
  • Work is continuing on specific interfaces to support SMS and is expected to support both point to point and cell broadcast.
  • The Datagram API can support basic short message services.
  • the meaning of "additional" Personal Java packages in Sun's Annex A: Personal Java 1.1.1 API Packages?
  • The packages identified with "additional" contain a few additional functions that are not included in the specification of JDK1.1. For example, in awt there is a provision for information for double buffered displays. See the specification for the complete list of additions. Look for the "PJAE specific" notes in http://java.sun.com/products/personaljava/
  • the security restrictions placed on the user profile?
  • The user profile information provided is expected to be restricted to trusted applications but specific security policy is expected to be specified elsewhere and it is up to the implementation must enforce them.
  • whether Sun Microsystems is considering the introduction of a smartcard API?
  • At this time there are no plans to introduce or require a Smartcard API as part of JavaPhone. Sun is participating in and supports the OpenCard Forum API for terminal access.
  • whether the "Power Management API" includes power state notification?
  • The power APIs support two kinds of monitoring and notification. The Power Monitoring API allows the application to respond to changes in the battery level, estimated time remaining and whether the mobile terminal is plugged into a wall socket. Power state management allows applications to respond to changes in the power states including full-power, managed power, suspend, sleep, and off. These are more appropriate for desktop systems and are optional in wireless devices.
  • whether Sun Microsystems is considering an API for geographical location?
  • MExE would like to suggest that the user profile API should be abstracted from the issue of the location of the data.
  • There is an overloading of terminology that may cause confusion. In JavaPhone the User Profile API provides addressbook type data about the owner or current user of the system.
  • The term user preferences is used for information specific to an application or java class. Sun is participating in another effort to develop an API for user preference information that would be a better match for the bulk of the requirements. That API does not specify the location of the data.
    • Please let us know if there is additional information or clarifications we can provide.