Internal settings

Maximum size of MMS

In the S60 implementation, the maximum size for an MMS to be sent through JSR-205 is 300K. This value is specified by MMS Conformance Document 1.2. The creation of any MMS with a size bigger than 300K will result in a SizeExceededException.

MMS store

In the S60 implementation, by default the MMS store is the phone memory (C: drive), but the user can change that to be memory card. In this case, if the memory card is removed and an MMS (or notification) arrives to the phone, it will be saved into the phone's memory, which becomes automatically the new MMS store.

If the user later reinserts the memory card into the phone, the MMSs which were received while the memory card was the MMS store will not be available unless the user resets the memory card as the new MMS store.

Receiving MMS messages

In the S60 implementation, MMSs addressed to registered Java applications are not saved into the Inbox and are not visible through the Messaging UI. These kinds of MMSs are only visible towards the registered Java applications.

In the S60 3rd Edition and 3rd Edition FP1 implementations, in case there is no registered Java application for a certain received MMS, then this MMS will be saved into the Inbox and therefore it will be visible through Messaging UI.

The automatic/manual fetch feature of the S60 3rd Edition and 3rd Edition FP1 phones applies to MMSes received by JSR-205 as well:

• In automatic fetching, the MMSs will be automatically fetched (either into a specific folder if there is a registered Java application for that MMS or into the Inbox if there is no registered Java application for that MMS).

• In manual fetching, a regular notification (with no Java-specific information) about the incoming MMS will be saved into the Inbox and shown to the phone user who can decide whether to fetch the MMS.

From S60 3rd Edition FP2 onward, the following guidelines apply:

In S60 3rd Edition FP2 the automatic/manual fetching has changed so that:

• In automatic fetching, the MMS will be either dispatched to the Java application or discarded (if there is no registered Java application for the received MMS)

• In case of manual fetching:

  • if the fetching of the MMS was successful, then the notification will be removed from Inbox

  • If the fetching of the MMS was not successful (due to e.g. out of memory error) then the notification is kept in Inbox and it contains the name of the existing Java application to which the MMS was addressed. In case there is no registered Java application for the incoming MMS a general name for Java application ("JavaMMSApp") is shown in the notification.

Reply mechanism

The reply mechanism defined in Appendix D of the JSR-205 specification is supported as clarified in the paragraphs below. The reply mechanism is based on the ‘Reply-To-Application-ID’ transport header defined by JSR-205. The reply mechanism means sending a received message back to the sender without specifically setting the recipient’s address (this will be done automatically by the implementation based on the information attached to the message to be sent. Thus, the message to be sent becomes a reply-type of message). The reply-type of the message is a message which came from a sender which is prepared for receiving responses to the sent message. JSR-205 specifies only how the ‘Reply-To-Application-ID’ is set on the sender side in case of a server-type of connection (“when a message identifying an application-id is sent from a server type MessageConnection, the Reply-To-Application-ID in the message is set to the application-id of the MessageConnection”), but JSR-205 does not specify how this header is set on the sender side in case of a client-type of connection and how this header is used on the receiver side. The S60 implementation for this is:

• In case of a client-type of connection JSR-205 mandates that "when a client type MessageConnection is used for sending a message with an application-id, the 'Reply-To-Application-ID' is set to an implementation-specific value". The S60's implementation specific value is '$'. Therefore, the S60 implementation recognizes a reply-type of message as a message which has 'Reply-To-Application-ID' transport header set to something else than '$'

• The ‘Reply-To-Application-ID’ header is visible on the receiver side via getAddress() or getAddress("from") methods. All the other get methods for the address(es) will return the receiver’s own application ID. In case of a non reply-type of message the implementation returns the sender's address without the application ID.

• The receiver makes a reply by simply sending a received message back to the sender without specifically setting the recipient’s address (the receiver is free to modify other fields of the message, but the addresses). In this case the implementation checks if the message to be sent is a reply-type of message or not (by checking the presence of the ‘Reply-To-Application-ID’ info attached to the message).

  • In case the message is a reply-type of message, the implementation will discard all the other recipients of the message and it will only send the message to original sender of the message. In the same time the ‘Reply-To-Application-ID’ header of the message to be sent as a reply is set to be the application ID of the current sender (that is, the message which is sent as a reply is a reply-type of message as well). After being sent, a reply-type of message has only one “to” address set to point to the original sender of the message. All the other addresses have been cleared after sending.

  • In case the message to be sent is not a reply-type of message, the implementation will throw an IllegalArgumentException, informing the receiver that the message to be sent is not a reply-type of message.

• On the other hand, as soon as the receiver of a reply-type of message touched/modified some of the message’s addresses (by calling one of the setAddress() or removeAddress() methods), the message is not a reply-type of message anymore; by calling the send() method with this kind of message, the receiver performs a simple send (to the message's recipients) and not a reply.

Out of memory

In the S60 implementation, there is no difference in handling the lack of memory scenario for MMSs addressed to Java applications and other MMSs (going by default to the Inbox):

• In manual fetching: the notification about the incoming MMS will be put to a failed state and a corresponding error code will indicate the lack of memory

• In automatic fetching: the terminal user will be notified about the lack of memory and the receiving of the incoming MMS will be re-scheduled

In S60 3rd Edition FP2, besides the general handling of the out of memory scenario described above, a special attention has been given to the use case when the MMS (which has been addressed to a Java application) has been fetched from the MMSC but the out of memory error occurs while trying to save the MMS into the MMS store. This case is handled as following in the automatic fetching:

• If the destination MIDlet doesn't have any unhandled MMSs then the new incoming MMS will be rescheduled

• If the destination MIDlet has unhandled MMSes then:

  • If the size of the incoming MMS is greater that the total size of the unhandled MMSes then the new incoming MMS will be rescheduled

  • If the size of the incoming MMS is less than the total size of the unhandled MMSes then the oldest MMSes are discarded in order to free enough space for the incoming MMS

Alert tone

When an MMS addressed to a certain Java application is received by the phone, the same alert tone which is assigned for the receiving of MMS’s (going by default to the Inbox) will be played/heard.

Deploying push MIDlets

In the S60 implementation, Push MIDlets should be installed in a MIDlet suite of their own (which does not contain other MIDlets). The reason for this is that a push MIDlet can not be restarted if a MIDlet (which was installed from the same MIDlet suite with the push MIDlet) is running.

Security settings

The Wireless Messaging API security model implemented is based on the security requirements specified in Mobile Information Device Profile for Java 2 Micro Edition, Version 2.0 and Java Technology for the Wireless Industry Specification.

Briefly, Wireless Messaging API is assigned to Messaging function group with the following user permission settings/interaction modes for the send() method:

In the S60 implementation, there are no user prompts for using the other methods of Wireless Messaging API. The interaction modes, or user permission settings, specify how to prompt the user to grant permissions to a specific API with one of the following modes:

• “Blanket” is valid for every invocation of an API by a MIDlet suite until it is uninstalled or the permission is changed by the user.

• “Session” is valid from the invocation of a MIDlet suite until it terminates. “Session” mode MUST prompt the user on or before the first invocation of the API or function which is protected. When the user re-invokes the MIDlet suite, the prompt MUST be repeated.

• “Oneshot” MUST prompt the user on each invocation of the API or function which is protected.

The S60 implementation shows only the number of recipients to which the MMS is about to be sent. The size of each of the MessagePart can be retrieved separately by using MessagePart.getLength() method. This clarification applies to the following paragraph:

“An Application MUST receive a user permission to send an MMS. The user makes a decision based on the following information provided by the application:

• List of all recipient addresses: all addresses set in the "to", "cc" and "bcc" fields

• The total size of the message, which includes the size of all message attachments and the size of the subject.” (Appendix E, E.2.1 E.2.2 Permissions for Send and Receive Operations; JSR-205 API specification)