W3C

Messaging API

W3C First Public Working Draft 16 May 2013

This version:
http://www.w3.org/TR/2013/WD-messaging-20130516/
Latest published version:
http://www.w3.org/TR/messaging/
Latest editor's draft:
http://www.w3.org/2012/sysapps/messaging/
Editors:
Eduardo Fullea, Telefonica
Jose M. Cantera, Telefonica
Zoltan Kis, Intel

Abstract

This specification defines a System Level API which offers a simple interface to get access to mobile messaging services. A typical use case of the Messaging API is the implementation of a messaging client application that allows the user to send SMS and MMS messages as well as to access and manage the received SMS and MMS messages.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document defines a System Level API for access to mobile messaging services including SMS and MMS messages. This can be contrasted with the earlier and discontinued draft messaging specification for the regular browser context.

This document was published by the System Applications Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-sysapps@w3.org (subscribe, archives). All feedback is welcome.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction

This section is non-normative.

The Messaging API provides operations to get access to the primitives offered by mobile messaging services (send, receive) as well as those that allow to manage a mobile messaging client inbox (delete, store, mark as read)

An example of use is provided below:

Example 1
navigator.messaging.sms.send ( '+1234567890', 'How are you?').done(
  function(message) { window.console.log('Message with identifier  ' +
                      message.messageID + ' sent at ' + message.timestamp); },
  function(error) {   window.console.error('Error: ' + error); } )

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].

This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces that it contains.

Implementations that use ECMAScript to implement the APIs defined in this specification MUST implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL], as this specification uses that specification and terminology.

3. Terminology

The EventHandler interface represents a callback used for event handlers as defined in [HTML5].

The concepts queue a task and fire an event are defined in [HTML5].

The terms event handler and event handler event types are defined in [HTML5].

4. Security and privacy considerations

This API must be only exposed to trusted content

6. MessagingManager Interface

The MessagingManager interface represents the initial entry point for getting access to the mobile messaging services, i.e. SMS and MMS.

interface MessagingManager {
    readonly    attribute SmsManager sms;
    readonly    attribute MmsManager mms;
    Future findMessages (MessagingFilter filter, FilterOptions options);
    Future findConversations (DOMString groupBy, MessagingFilter filter, FilterOptions options);
    Future getMessage (DOMString messageID);
    Future deleteMessage (DOMString messageID);
    Future deleteConversation (DOMString conversationID);
    Future markMessageRead (DOMString messageID, optional boolean value = true);
    Future markConversationRead (DOMString conversationID, optional boolean value = true);
};

6.1 Attributes

sms of type SmsManager, readonly
Provides access to the SMS service's specific functionality.
mms of type MmsManager, readonly
Provides access to the MMS service's specific functionality.

6.2 Methods

findMessages
This method makes a request to retrieve the messages matching the filter described by the filter parameter and according to the filtering options described in the options. It returns a new Future that will be used to notify the caller about the result of the operation, which is a MessagingCursor to access the set of messages.
Parameter Type Nullable Optional Description
filter MessagingFilter Filter that identifies the set of messages that are requested to be retrieved
options FilterOptions Indicates the filtering options (i.e. sorting criteria, sorting order, limit of results).
Return type: Future
findConversations
This method makes a request to retrieve the list of conversations in which the messages can be grouped using the criteria defined by the groupBy parameter. Only those messages matching the filter described in the filter parameter SHALL be included in the resulting conversations, what can be useful for instance to filter just a specific type of messages (e.g. SMS) or to implement message search in a conversational messaging client. It returns a new Future that will be used to notify the caller about the result of the operation, which is a MessagingCursor to access the set of conversations.
Parameter Type Nullable Optional Description
groupBy DOMString Indicates the criteria used to define the conversations. It may have the values 'participants' if a conversation is to be defined as the set of messages exchanged among the same set of parties, and 'subject' if a conversation is to be defined as the set of messages with the same subject.
filter MessagingFilter Filter that identifies the set of messages that are requested to be included in the resulting conversations.
options FilterOptions Indicates the filtering options (i.e. sorting criteria, sorting order, limit of results) to be aplied when filtering the messages to be included in each of the resulting conversations.
Return type: Future
getMessage
This method makes a request to retrieve the message identified by the messageID parameter. It returns a new Future object which allows the caller to be notified about the result of the operation.
Parameter Type Nullable Optional Description
messageID DOMString Identifier of the message that is requested to be retrieved
Return type: Future
deleteMessage
This method requests the deletion of the message with identifier equal to the messageID parameter. A new Future is returned in order to notify the request result (success or error) to the caller.
Parameter Type Nullable Optional Description
messageID DOMString Identifier of the message that is requested to be deleted
Return type: Future
deleteConversation
This method requests the deletion of all the messages in the conversation with identifier equal to the conversationID parameter. A new Future is returned in order to notify the request result (success or error) to the caller.
Parameter Type Nullable Optional Description
conversationID DOMString Identifier of the conversation whose messages are requested to be deleted
Return type: Future
markMessageRead
This method requests to mark as read or unread the message with identifier equal to the messageID parameter. The method returns a new Future that will allow the caller to be notified about the result (success, error) of the operation.
Parameter Type Nullable Optional Description
messageID DOMString Identifier of the message that is requested to be marked as read or unread
value boolean = true Indicates whether the message is to be marked as read ('true', which is the default) or unread ('false')
Return type: Future
markConversationRead
This method requests to mark as read or unread all the messages in the conversation with identifier equal to the conversationID parameter. The method returns a new Future that will allow the caller to be notified about the result (success, error) of the operation.
Parameter Type Nullable Optional Description
conversationID DOMString Identifier of the conversation whose messages are requested to be marked as read or unread
value boolean = true Indicates whether the messages in the conversation are to be marked as read ('true', which is the default) or unread ('false')
Return type: Future

6.3 Steps

The findMessages method when invoked MUST run the following steps:

  1. Make a request to the system to get the message(s) matching the filter included in the filter parameter and according to the filtering options described in the options parameter.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Let messagingCursor be a new MessagingCursor object providing access to the results of the retrieval, i.e. the set of SmsMessage and/or MmsMessage elements.
    2. Call resolver's accept(value)method with messagingCursor as value argument.

The findConversations method when invoked MUST run the following steps:

  1. Make a request to the system to get the set of conversations in which the messages can be grouped, according to the set of participants or the subject as indicated in the groupBy parameter, and filtering the messages included in those conversations according to the filter included in the filter parameter and the filtering options described in the options parameter.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Let messagingCursor be a new MessagingCursor object providing access to the results of the retrieval, i.e. the set of Conversation elements.
    2. Call resolver's accept(value)method with messagingCursor as value argument.

The getMessage method when invoked MUST run the following steps:

  1. Make a request to the system to get the message with identifier equal to the messageID parameter passed in the request.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Let message be the SmsMessage or MmsMessage whose identifier matches the messageID parameter.
    2. Call resolver's accept(value)method with message as value argument.

The deleteMessage method when invoked MUST run the following steps:

  1. Make a request to the system to delete the message with identifier equal to the messageID parameter passed in the request.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Let messageID be the messageID parameter passed in the request
    2. Call resolver's accept(value)method with messageID as value argument.

The deleteConversation method when invoked MUST run the following steps:

  1. Make a request to the system to delete the messages in the conversation with identifier equal to the conversationID parameter passed in the request.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Let conversationID be the conversationID parameter passed in the request
    2. Call resolver's accept(value)method with conversationID as value argument.

The markMessageRead method when invoked MUST run the following steps:

  1. Make a request to the system to mark as read/unread (depending on the value parameter being respectively 'true' or 'false') the message with identifier equal to the messageID parameter passed in the request.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Let messageID be the messageID parameter passed in the request
    2. Call resolver's accept(value)method with messageID as value argument.

The markConversationRead method when invoked MUST run the following steps:

  1. Make a request to the system to mark as read/unread (depending on the value parameter being respectively 'true' or 'false') the messages in the conversation with identifier equal to the conversationID parameter passed in the request.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Let conversationID be the conversationID parameter passed in the request
    2. Call resolver's accept(value)method with conversationID as value argument.
Note
It is FFS whether the methods deleteMessage() and markMessageRead() should also accept an array of message identifiers as input parameter.

7. SmsManager Interface

The SmsManager interface represents the SMS messaging service manager.

interface SmsManager : EventTarget {
    readonly    attribute MessageType  type;
    readonly    attribute DOMString[]  serviceIDs;
    SmsSegmentInfo segmentInfo (DOMString text, optional DOMString serviceID);
    Future         send (DOMString to, DOMString text, optional DOMString serviceID);
    Future         clear (DOMString serviceID);
                attribute EventHandler onreceived;
                attribute EventHandler onsent;
                attribute EventHandler ondeliverysuccess;
                attribute EventHandler ondeliveryfailure;
                attribute EventHandler onserviceadded;
                attribute EventHandler onserviceremoved;
};

7.1 Attributes

type of type MessageType, readonly
MUST return the type of the messaging service manager. It can have the following values: 'sms' or 'mms'.
serviceIDs of type array of DOMString, readonly
MUST return the identifier of the different services for this type of messaging service (e.g. 'sms_sim1').
onreceived of type EventHandler,
Handles the received event of type MessagingEvent, fired when a new message is received on this messaging service manager.
onsent of type EventHandler,
Handles the sent event of type MessagingEvent, fired when a new message is sent using this messaging service manager.
ondeliverysuccess of type EventHandler,
Handles the deliverysuccess event of type DeliveryReportEvent, fired when a new succesful delivery report is received on this messaging service manager.
ondeliveryfailure of type EventHandler,
Handles the deliveryfailure event of type DeliveryReportEvent, fired when a new failure delivery report is received on this messaging service manager.
onserviceadded of type EventHandler,
Handles the serviceadded event of type ServiceChangeEvent, fired whenever a new messaging service is enabled on this messaging service manager.
onserviceremoved of type EventHandler,
Handles the serviceremoved event of type ServiceChangeEvent, fired when an existing messaging service is disabled on this messaging service manager.

7.2 Methods

segmentInfo
This method returns an SmsSegmentInfo object including information on the number of concatenated SMS segments needed to send the text in the text parameter, the number of characters available per segment and the maximum number of available characters in the last segment.
Parameter Type Nullable Optional Description
text DOMString Text intended to be sent as an SMS, whose segmentation information is checked by this method.
serviceID DOMString Identifier of the service through which the message is would be sent.
Return type: SmsSegmentInfo
send
This method issues a request to the messaging system to send an SMS message with the text of the text parameter to the destination number indicated in the to parameter. A Future object will be returned in order to notify the result of the request.
Parameter Type Nullable Optional Description
to DOMString Destination number for the SMS message.
text DOMString Content of the SMS message to be sent.
serviceID DOMString Identifier of the service through which the message is requested to be sent.
Return type: Future
clear
This method makes a request to delete all the messages associated to the messaging service passed as parameter.
Parameter Type Nullable Optional Description
serviceID DOMString Identifies the messaging service all whose messages are requested to be deleted.
Return type: Future

7.3 Steps

The send method when invoked MUST run the following steps:

  1. Create a new instance of SmsMessage:
    1. Generate a identifier for this message that is globally unique within the implementation, i.e. there cannot be any other message with the same identifier.
    2. Set the messageID of the SmsMessage to the generated identifier.
    3. Set the type of the SmsMessage to 'sms'.
    4. Set the serviceID of the SmsMessage to the identifier of the service used to send the message, i.e. the one passed in the serviceID parameter, if provided, or otherwise to the first element in the serviceIDs attribute of the SmsManager.
    5. Set the from of the SmsMessage to the number of the mobile subscription used to send this SMS message.
    6. Set the read of the SmsMessage to 'true'.
    7. Set the to of the SmsMessage to the value of the to parameter.
    8. Set the body of the SmsMessage to the value of the text parameter.
    9. Set the messageClass of the SmsMessage to 'class1'.
    10. Set the state of the SmsMessage to 'sending'.
    11. Set the deliveryStatus of the SmsMessage to 'pending' if a delivery report has been requested or to 'not-applicable' otherwise.
    12. Make a request to the system to send an SMS message with text passed in the text parameter to the number of the recipient indicated in the to parameter, using the proper service as described above.
    13. Queue a task to monitor SMS submission process.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs run these substeps and terminate these steps
    1. If a delivery report had been requested set the deliveryStatus of the SmsMessage to 'error'.
    2. call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Set the state of the SmsMessage to 'sent'.
    2. Set the timestamp of the SmsMessage to the timestamp when the SMS message reached the Short Message Center, i.e. the value of the TP-Service-Centre-Time-Stamp (TP-SCTS) parameter returned in the SMS-SUBMIT-REPORT Protocol Data Unit [GSM-SMS].
    3. Call resolver's accept(value)method with the sent SmsMessage as value argument.
    4. Queue a task to fire an event named sent with the message attribute set to the sent SmsMessage.

The segmentInfo method when invoked MUST return a SmsSegmentInfo object that contains the following elements:

  1. A segments element indicating the number of concatenated SMS segments needed to send the text passed in the text parameter using the service with identifier equal to the one passed in the serviceID parameter, if provided, or otherwise to the first element in the serviceIDs attribute of the SmsManager. Note that the application SHOULD NOT split the text in a set of strings that fit each into a single SMS segment as it would result in different independent SMS messages being sent, but SHOULD instead send the full message in a single sendSMS request. However having information on the number of SMS segments may be required by the application in order to inform the user (e.g. in case the length of the text impacts on the price charged for sending the message).
  2. A charsPerSegment element indicating the number of characters available per SMS segment. This number depends on the encoding to be used to send the SMS message, which in turn depends on the language / special characters included in the text.
  3. A charsAvailableInLastSegment element indicating the maximum number of available characters in the last segment that would be needed to send the input string. This provides useful information to the user on the number of characters that can type without requiring an additional SMS segment to send the text.

Upon a new SMS message being received, the user agent MUST:

  1. Create a new instance of SmsMessage.
  2. Generate a identifier for this message that is globally unique within the implementation, i.e. there cannot be any other message with the same identifier.
  3. Set the messageID of the SmsMessage to the generated identifier.
  4. Set the type of the SmsMessage to 'sms'.
  5. Set the serviceID of the SmsMessage to the identifier of the service at which the message has been received.
  6. Set the from of the SmsMessage to the sender of the SMS message, i.e. the value of the TP Originating Address (TP-OA) field of the SMS message [GSM-SMS].
  7. Set the timestamp of the SmsMessage to the timestamp of the SMS message, i.e. the value of the TP-Service-Centre-Time-Stamp (TP-SCTS) parameter received in the SMS DELIVER Protocol Data Unit [GSM-SMS].
  8. Set the read of the SmsMessage to 'false'.
  9. Set the to of the SmsMessage to the recipient of the SMS message, i.e. the value of the TP Destination Address (TP-DA) field of the SMS message [GSM-SMS].
  10. Set the messageClass of the SmsMessage to the message class indicated in the TP-Data-Coding-Scheme (TP-DCS) field of the SMS message [GSM-SMS].
  11. Set the body element to the text of the received SMS message, i.e. the value of the SM element contained within the TP User Data (TP-UD) field of the SMS message [GSM-SMS].
  12. Set the state of the SmsMessage to 'received'.
  13. Set the deliveryStatus of the SmsMessage to 'not-applicable'.
  14. Queue a task to fire an event named received with the message attribute set to the newly created SmsMessage instance.
  15. Queue a task to fire a system message named received of type ReceivedMessage with the message attribute set to the newly created SmsMessage instance.

Upon a delivery report of a previously sent SMS message being received, the user agent MUST

  1. Set the deliveryStatus parameter of the SmsMessage to 'success' or 'error' depending on the reported result.
  2. Queue a task to fire an event named deliverysuccess or deliveryfailure respectively if the delivery was successfull or not, with
    1. the messageID attribute set to the identifier of the SmsMessage to which this confirmation is related,
    2. the serviceID attribute set to the identifier of the service used to send such message, and
    3. the recipients attribute set to the recipient of such message.
  3. Queue a task to fire a system message of type DeliveryReportnamed deliverysuccess or deliveryfailure respectively if the delivery was successfull or not, with
    1. the messageID attribute set to the identifier of the SmsMessage to which this confirmation is related,
    2. the serviceID attribute set to the identifier of the service used to send such message, and
    3. the recipients attribute set to the recipient of such message.

The clear method when invoked MUST run the following steps:

  1. Make a request to the system to delete all the messages associated to the messaging service with identifier equal to the serviceID parameter.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Let serviceID be the serviceID parameter passed in the request
    2. Call resolver's accept(value)method with serviceID as value argument.

7.4 Event handlers

The following are the event handlers (and their corresponding event types) that MUST be supported as attributes by the SmsManager object.

event handler event name event type short description
onreceived received MessagingEvent handles received messages
onsent sent MessagingEvent handles sent messages
ondeliverysuccess deliverysuccess DeliveryReportEvent handles successful delivery reports
ondeliveryfailure deliveryfailure DeliveryReportEvent handles failure delivery reports
onserviceadded serviceadded ServiceChangeEvent handle new messaging services
onserviceremoved serviceremoved ServiceChangeEvent handle disabled messaging services

8. SmsSegmentInfo Dictionary

The SmsSegmentInfo dictionary contains information about the segmentation of a given text to be sent as SMS.

dictionary SmsSegmentInfo {
    long segments;
    long charsPerSegment;
    long charsAvailableInLastSegment;
};

8.1 Dictionary SmsSegmentInfo Members

segments of type long
MUST return the total number of SMS segments needed to send the input string, taking into account the encoding to be used to send such message as well as the overhead associated to concatenated SMS messages.
charsPerSegment of type long
MUST return the number of characters available per SMS segment as per the encoding to be used to send the SMS message. In case the variable length encoding, the value of this element MUST be calculated asumming the minimum length for all the characters.
charsAvailableInLastSegment of type long
MUST return the maximum number of available characters in the last segment needed to send the input string. In case the variable length encoding, the value of this element MUST be calculated asumming the minimum length for all the remaining characters.

9. MmsManager Interface

The MmsManager interface represents the MMS messaging service manager.

interface MmsManager : EventTarget {
    readonly    attribute MessageType  type;
    readonly    attribute DOMString[]  serviceIDs;
    FetchMode getFetchMode (optional DOMString serviceID);
    void      setFetchMode (FetchMode fetchMode, optional DOMString serviceID);
    Future    send (MmsContent mmsContent, optional DOMString serviceID);
    Future    fetch (DOMString messageID);
    Future    clear (DOMString serviceID);
                attribute EventHandler onreceived;
                attribute EventHandler onsent;
                attribute EventHandler ondeliverysuccess;
                attribute EventHandler ondeliveryfailure;
                attribute EventHandler onserviceadded;
                attribute EventHandler onserviceremoved;
};

9.1 Attributes

type of type MessageType, readonly
MUST return the type of the messaging service manager. It can have the following values: 'sms' or 'mms'.
serviceIDs of type array of DOMString, readonly
MUST return the identifier of the different services for this type of messaging service (e.g. 'sms_sim1').
onreceived of type EventHandler,
Handles the received event of type MessagingEvent, fired when a new message is received on this messaging service manager.
onsent of type EventHandler,
Handles the sent event of type MessagingEvent, fired when a new message is sent using this messaging service manager.
ondeliverysuccess of type EventHandler,
Handles the deliverysuccess event of type DeliveryReportEvent, fired when a new succesful delivery report is received on this messaging service manager.
ondeliveryfailure of type EventHandler,
Handles the deliveryfailure event of type DeliveryReportEvent, fired when a new failure delivery report is received on this messaging service manager.
onserviceadded of type EventHandler,
Handles the serviceadded event of type ServiceChangeEvent, fired whenever a new messaging service is enabled on this messaging service manager.
onserviceremoved of type EventHandler,
Handles the serviceremoved event of type ServiceChangeEvent, fired when an existing messaging service is disabled on this messaging service manager.

9.2 Methods

getFetchMode
This method requests to retrieve the fetch mode associated to a specific service (the one identified by the serviceID attribute, if provided, or the first element in the serviceIDs attribute of the MmsManager otherwise).
Parameter Type Nullable Optional Description
serviceID DOMString Identifier of the service whose fetch mode is queried.
Return type: FetchMode
setFetchMode
This method issues a request to the messaging system to set to manual or automatic the MMS message fetch mode of the specific service, the one identified by the serviceID attribute, if provided, or all services otherwise).
Parameter Type Nullable Optional Description
fetchMode FetchMode Fetch mode that is requested to be set for a specific service.
serviceID DOMString Identifier of the service whose fetch mode is requested to be set.
Return type: void
send
This method issues a request to the messaging system to send an MMS message with the content and recipients included in the mmsContent parameter. A Future object will be returned in order to notify the result of the request.
Parameter Type Nullable Optional Description
mmsContent MmsContent Content and recipients of the MMS message to be sent.
serviceID DOMString Identifier of the service through which the message is requested to be sent.
Return type: Future
fetch
This method requests to fetch an MMS message with identifier equal to the indicated in the messageID parameter from the URL indicated in the MMS notification. The method returns a new Future that will allow the caller to be notified about the result (success, error) of the operation.
Parameter Type Nullable Optional Description
messageID DOMString Identifier of the MMS message that is requested to be download.
Return type: Future
clear
This method makes a request to delete all the messages associated to the messaging service passed as parameter.
Parameter Type Nullable Optional Description
serviceID DOMString Identifies the messaging service all whose messages are requested to be deleted.
Return type: Future
Note
It is FFS whether MMS settings (e.g. fetch mode, creation mode) needs to be managed through the MmsManager interface.

9.3 Steps

The send method when invoked MUST run the following steps:

  1. Create a new instance of MmsMessage and:
    1. Generate a identifier for this message that is globally unique within the implementation, i.e. there cannot be any other message with the same identifier.
    2. Set the messageID of the MmsMessage to the generated identifier.
    3. Set the type of the MmsMessage to 'mms'.
    4. Set the serviceID of the MmsMessage to the identifier of the service used to send the message, i.e. the one passed in the serviceID parameter, if provided, or otherwise to the first element in the serviceIDs attribute of the MmsManager.
    5. Set the from of the MmsMessage to the number of the mobile subscription used to send this MMS message.
    6. Set the read of the MmsMessage to 'true'.
    7. Set the to of the MmsMessage to the to in the mmsContent parameter.
    8. Set the cc of the MmsMessage to the cc array in the mmsContent parameter.
    9. Set the bcc of the MmsMessage to the bcc array in the mmsContent parameter.
    10. Set the subject of the MmsMessage to the value of the the subject parameter in mmsContent.
    11. Set the smil of the MmsMessage to the value of the the smil parameter in mmsContent.
    12. Set the attachments of the MmsMessage to the value of the the attachments array in mmsContent parameter.
    13. Set the state of the MmsMessage to 'sending'.
    14. Add a new element in the deliveryStatus array of the MmsMessage for each of the addresses included in the to, cc and bcc parameters, with value 'pending' if a delivery report has been requested or with value 'not-applicable' otherwise.
    15. Make a request to the system to send an MMS message with the content passed in the content parameter to the number(s) of indicated in the to parameter, using the proper service as described above.
    16. Queue a task to monitor MMS sending progress.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs run these substeps and terminate these steps
    1. If a delivery report had been requested set the different elements in the deliveryStatus array of the MmsMessage to 'error'.
    2. call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Set the state of the MmsMessage to 'sent'.
    2. Set the timestamp of the MmsMessage to the timestamp when the MMS message was sent, i.e. the date when the M-Send.req Protocol Data Unit was send from the MMS Client to the MMS Server.
    3. Call resolver's accept(value)method with the sent MmsMessage as value argument.
    4. Queue a task to fire an event named sent with the message attribute set to the sent MmsMessage.

The reception of an MMS message is a two-step process: Firstly, an MMS notification encapsulated in a WAP Push OTA message [OMA-PUSH] is received by the device. This MMS notification contains limited information about the MMS message and a URL where the device can retrieve the full MMS message from. Secondly, the MMS message is retrieved either automatically, i.e. performed right after the reception of the MMS notification, or manually, i.e. invoked manually by the user.

Upon a new MMS notification being received, the user agent MUST:

  1. Create a new instance of MmsMessage.
  2. Generate a identifier for this message that is globally unique within the implementation, i.e. there cannot be any other message with the same identifier.
  3. Set the messageID of the MmsMessage to the generated identifier.
  4. Set the type of the MmsMessage to 'mms'.
  5. Set the serviceID of the MmsMessage to the identifier of the service at which the message has been received.
  6. Set the read of the MmsMessage to 'false'.
  7. if the fetch mode is manual:
    1. Set the from of the MmsMessage to the value of the 'From' field of the MMS notification, if present.
    2. Set the timestamp of the MmsMessage to the timestamp of the binary SMS message used to transport the MMS notification, i.e. the value of the TP-Service-Centre-Time-Stamp (TP-SCTS) parameter received in the SMS-DELIVER Protocol Data Unit [GSM-SMS].
    3. Add a new element in the to array of the MmsMessage for each of recipients in the 'To' field of the MMS notification [MMS13], if present.
    4. Add a new element in the cc array of the MmsMessage for each of recipients in the 'Cc' field of the MMS notification [MMS13], if present.
    5. Add a new element in the bcc array of the MmsMessage for each of recipients in the 'Bcc' field of the MMS notification [MMS13], if present.
    6. Set the subject element to the value of the 'Subject' field of the MMS notification [MMS13], if present.
    7. Set the state of the MmsMessage to 'not-downloaded'.
  8. if the fetch mode is otherwise automatic:
    1. Make a request to the system to fetch the MMS message from the URL indicated in the X-Mms-Content-Location field of the MMS notification. Once the MMS has been fetched continue with following steps.
    2. Run the steps for filling the MmsMessage object with the data contained in the MMS message enclosed in the M-Retrieve.conf Protocol Data Unit.
      1. Set the from of the MmsMessage to the value of the 'From' field of the MMS message [MMS13].
      2. Set the timestamp of the MmsMessage to the value of the 'Date' field of the MMS message [MMS13].
      3. Add a new element in the to array of the MmsMessage for each of recipients in the 'To' field of the MMS message [MMS13], if present.
      4. Add a new element in the cc array of the MmsMessage for each of recipients in the 'Cc' field of the MMS message [MMS13], if present.
      5. Add a new element in the bcc array of the MmsMessage for each of recipients in the 'Bcc' field of the MMS message [MMS13], if present.
      6. Set the subject element to the value of the 'Subject' field of the MMS message [MMS13], if present.
      7. Set the smil element to a DOMString containing the SMIL object of the received MMS message [MMS13], if present.
      8. For each of the media files attached to the received MMS message add a new element to the attachments array with:
        1. A new Blob object including the media type and the actual content of the attachment.
        2. The contentID attribute filled with the Content-ID used to reference this element from the SMIL object in the incoming MMS message [MMS13], if present.
        3. The contentLocation attribute filled with the Content-Location used to reference this element from the SMIL object in the incoming MMS message [MMS13], if present.
    3. Set the state of the MmsMessage to 'received'.
    4. Add a new element in the deliveryStatus array of the MmsMessage for each of recipients in the 'To', 'Cc' and 'Bcc' fields with value 'not-applicable'.
  9. Queue a task to fire an event named received with the message attribute set to the newly created MmsMessage instance.
  10. Queue a task to fire a system message named received of type ReceivedMessage with the message attribute set to the newly created MmsMessage instance.

The fetch method can be invoked to fetch an MMS message that has not been automatically fetched upon receiving the corresponding MMS notification due to the fetch mode being manual. When this method is invoked the User Agent MUST run the following steps:

  1. If the messageID parameter passed in the request matches with an MMS message that has already been fetched, or to an SMS message go to next step, otherwise make a request to the system to fetch the MMS message.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Run the steps for filling the MmsMessage object with the data contained in the MMS message.
    2. Let message be the MmsMessage that has been fetched.
    3. Call resolver's accept(value)method with message as value argument.

An example of manual fetch of an MMS is provided below:

Example 2
navigator.setMessageHandler ('received', onMessageReceived)
function onMessageReceived(message) {
  if (message.type == 'sms') { window.console.log('SMS Message from ' +
                               message.from + ' received');  } 
  else if (message.type == 'mms') {
        window.console.log('MMS Message from ' + message.from + ' received');  
        if (message.state == 'not-downloaded') { 
                 window.console.log('MMS Message download started');  
                 navigator.messaging.mms.fetch (message.id).done(
                        function(message) { window.console.log('MMS Message downloaded!');},
                        function(error)   { window.console.error('Error: ' + error);} );
        }
  }
}
Note
It is FFS how to report the progress of the sending and fetching of an MMS message.

Upon a delivery report of a previously sent MMS message being received, the user agent MUST

  1. Set the elements of the deliveryStatus array of the MmsMessage corresponding to the recipients to which the delivery report refers to 'success' or 'error' depending on the reported result.
  2. Queue a task to fire an event named deliverysuccess or deliveryfailure respectively if the delivery was successfull or not, with
    1. the messageID attribute set to the identifier of the MmsMessage to which this confirmation is related,
    2. the serviceID attribute set to the identifier of the service used to send such message, and
    3. the recipients attribute set to the subset of the original recipients to which this delivery report is related.
  3. Queue a task to fire a system message of type DeliveryReportnamed deliverysuccess or deliveryfailure respectively if the delivery was successfull or not, with
    1. the messageID attribute set to the identifier of the MmsMessage to which this confirmation is related,
    2. the serviceID attribute set to the identifier of the service used to send such message, and
    3. the recipients attribute set to the recipient of such message.

The clear method when invoked MUST run the following steps:

  1. Make a request to the system to delete all the messages associated to the messaging service with identifier equal to the serviceID parameter.
  2. Let future be a new Future object and resolver its associated resolver
  3. Return future to the caller.
  4. If an error occurs call resolver's reject(value)method with error as value argument.
  5. When the request has been successfully completed:
    1. Let serviceID be the serviceID parameter passed in the request
    2. Call resolver's accept(value)method with serviceID as value argument.

9.4 Event handlers

The following are the event handlers (and their corresponding event types) that MUST be supported as attributes by the MmsManager object.

event handler event name event type short description
onreceived received MessagingEvent handles received messages
onsent sent MessagingEvent handles sent messages
ondeliverysuccess deliverysuccess DeliveryReportEvent handles successful delivery reports
ondeliveryfailure deliveryfailure DeliveryReportEvent handles failure delivery reports
onserviceadded serviceadded ServiceChangeEvent handle new messaging services
onserviceremoved serviceremoved ServiceChangeEvent handle disabled messaging services

10. SmsMessage Interface

The SmsMessage interface represents an SMS message as defined in [GSM-SMS]. This interface is not intended to represent binary SMS, which are out of the scope of this API.

interface SmsMessage {
    readonly    attribute DOMString       messageID;
    readonly    attribute MessageType     type;
    readonly    attribute DOMString       serviceID;
    readonly    attribute DOMString       from;
    readonly    attribute Date            timestamp;
    readonly    attribute boolean         read;
    readonly    attribute DOMString       to;
    readonly    attribute DOMString       body;
    readonly    attribute SmsState        state;
    readonly    attribute DeliveryStatus? deliveryStatus;
    readonly    attribute MessageClass    messageClass;
};

10.1 Attributes

messageID of type DOMString, readonly
MUST return the identifier of the message.
type of type MessageType, readonly
MUST return the type of message, i.e. 'sms'.
serviceID of type DOMString, readonly
MUST return the messaging service id used to send / receive this message.
from of type DOMString, readonly
MUST return the sender of the message, i.e. the TP Originating Address (TP-OA) of the SMS message.
timestamp of type Date, readonly
MUST return the time the message reached the Short Message Center, indicated in the TP-Service-Centre-Time-Stamp (TP-SCTS) parameter of the SMS message.
read of type boolean, readonly
MUST return 'true' if the message has been marked as read, or 'false' otherwise.
to of type DOMString, readonly
MUST return the recipient of the message, i.e. the TP Destination Address (TP-DA) of the SMS message.
body of type DOMString, readonly
MUST return text of the SMS message, i.e. the SM element contained within the TP User Data (TP-UD) field of the SMS message.
state of type SmsState, readonly
MUST return the status of the SMS message.
deliveryStatus of type DeliveryStatus, readonly , nullable
MUST return the delivery status of the SMS message.
messageClass of type MessageClass, readonly
MUST return the SMS message class, according to the value indicated in the TP-Data-Coding-Scheme (TP-DCS) field of the SMS.

11. MmsMessage Interface

The MmsMessage interface represents an MMS message, as defined in [MMS13].

interface MmsMessage {
    readonly    attribute DOMString         messageID;
    readonly    attribute MessageType       type;
    readonly    attribute DOMString         serviceID;
    readonly    attribute DOMString         from;
    readonly    attribute Date              timestamp;
    readonly    attribute boolean           read;
    readonly    attribute DOMString[]       to;
    readonly    attribute DOMString[]       cc;
    readonly    attribute DOMString[]       bcc;
    readonly    attribute DOMString         subject;
    readonly    attribute DOMString         smil;
    readonly    attribute MmsAttachments[]? attachments;
    readonly    attribute MmsState          state;
    readonly    attribute DeliveryStatus[]  deliveryStatus;
};

11.1 Attributes

messageID of type DOMString, readonly
MUST return the identifier of the message.
type of type MessageType, readonly
MUST return the type of message, i.e. 'mms'.
serviceID of type DOMString, readonly
MUST return the messaging service id used to send / receive this message.
from of type DOMString, readonly
MUST return the sender of the message, i.e. the 'From' field of the MMS message.
timestamp of type Date, readonly
MUST return the time the message was sent at, i.e. the 'Date' field of the MMS message.
read of type boolean, readonly
MUST return 'true' if the message has been marked as read, or 'false' otherwise.
to of type array of DOMString, readonly
MUST return an array containing the recipient(s) included in the 'To' field of the MMS message.
cc of type array of DOMString, readonly
MUST return an array containing the recipient(s) included in the 'Cc' field of the MMS message.
bcc of type array of DOMString, readonly
MUST return an array containing the recipient(s) included in the 'Bcc' field of the MMS message.
subject of type DOMString, readonly
MUST return the subject of the MMS message, corresponding to the 'Subject' field of the MMS message.
smil of type DOMString, readonly
MUST return the SMIL, i.e. the presentation element, unparsed as DOMString, that the messaging client needs to use to determine the way the content of the MMS message is displayed.
attachments of type array of MmsAttachments, readonly , nullable
MUST return the set of attachments of the MMS message.
state of type MmsState, readonly
MUST return the status of the MMS message.
deliveryStatus of type array of DeliveryStatus, readonly
MUST return an array with each of the elements indicating the delivery status to each of the recipients of the message, in order starting with the recipients in the 'To' field, followed by those in 'Cc' and ending with those in 'Bcc'.

12. MmsContent Dictionary

dictionary MmsContent {
    DOMString       subject;
    DOMString[]     to;
    DOMString[]     cc;
    DOMString[]     bcc;
    DOMString       smil;
    MmsAttachment[] attachments;
};

12.1 Dictionary MmsContent Members

subject of type DOMString
Indicates the subject of the MMS message, corresponding to the 'Subject' field of the MMS message.
to of type array of DOMString
Indicates the recipient(s) included in the 'To' field of the MMS message. There MUST be at least one recipient in any of the to, cc or bcc attributes.
cc of type array of DOMString
Indicates the recipient(s) included in the 'Cc' field of the MMS message. There MUST be at least one recipient in any of the to, cc or bcc attributes.
bcc of type array of DOMString
Indicates the recipient(s) included in the 'Bcc' field of the MMS message. There MUST be at least one recipient in any of the to, cc or bcc attributes.
smil of type DOMString
Contains the SMIL component, i.e. the presentation element that determines the way the content of the MMS message MUST be displayed.
attachments of type array of MmsAttachment
Contains the set of attachments of the MMS message.

13. MmsAttachment Dictionary

dictionary MmsAttachment {
    DOMString contentID;
    DOMString contentLocation;
    Blob      content;
};

13.1 Dictionary MmsAttachment Members

contentID of type DOMString
The Content-ID parameter that MAY be used to refer to the attachment from the SMIL presentation object as described in [MMS13] and [MIME-ENC]. At least one of contentID and contentLocation MUST be specified if the MMS Message contains an SMIL presentation object.
contentLocation of type DOMString
The Content-Location parameter that MAY be used to refer to the attachment from the SMIL presentation object as described in [MMS13] and [MIME-ENC]. At least one of contentID and contentLocation MUST be specified if the MMS Message contains an SMIL presentation object. It may also be used as a hint to define the filename when the attachment is stored at the file system.
content of type Blob
The Blob object containing the media type and the binary content of the attachment.

14. Conversation Interface

The Conversation interface represents a set of messages that are grouped together either because they are exchanged among the same set of participants or because they have the same subject.

interface Conversation {
    readonly    attribute DOMString     conversationID;
    readonly    attribute MessageType   type;
    readonly    attribute DOMString[]   participants;
    readonly    attribute DOMString     subject;
    readonly    attribute DOMString[]   messageTypes;
    readonly    attribute unsigned long messageCount;
    readonly    attribute unsigned long unreadCount;
    readonly    attribute DOMString     lastMessageID;
    readonly    attribute MessageCursor cursor;
};

14.1 Attributes

conversationID of type DOMString, readonly
MUST return the identifier of the conversation, which is globally unique within the implementation, i.e. there cannot be any other conversation with the same identifier.
type of type MessageType, readonly
MUST return the type of conversation, with value 'participants' if the conversation is defined as the set of messages exchanged among the same set of parties, and 'subject' if the conversation is defined as the set of messages with the same subject.
participants of type array of DOMString, readonly
MUST return an array containing the participants in the conversation. In case the conversation is of type 'subject' and there are messages in the conversation with a different set of participants then this element MUST return the union of the participants of all the messages in the conversation.
subject of type DOMString, readonly
MUST return the subject of the conversation, if there is a single one.
messageTypes of type array of DOMString, readonly
MUST return an array contining the different types of messages included in the conversation.
messageCount of type unsigned long, readonly
MUST return the number of messages in the conversation.
unreadCount of type unsigned long, readonly
MUST return the number of unread messages in the conversation.
lastMessageID of type DOMString, readonly
MUST return the identifier of the message in the conversation with the most recent timestamp.
cursor of type MessageCursor, readonly
MUST return the MessageCursor to access the messages in this conversation.

15. MessagingCursor Interface

The MessagingCursor interface allows to iterate through a list of Conversation elements or of messages (SmsMessage and/or MmsMessage elements).

A MessagingCursor always has, an associated request which is the Future that created it.

As soon as the MessagingCursor is accessing an element, it MUST put its associated request in the 'processing' readyState, and set the result to null. Then, the UA MUST fetch the next/previous element asynchronously. When the element is retrieved, the associated request's readyState must be set to 'done' and the result must point to the cursor. If no element was found, the cursor's element property must return null.

interface MessagingCursor {
    readonly    attribute any? element;
    void next ();
    void previous ();
};

15.1 Attributes

element of type any, readonly , nullable
This property MUST return the currently accessed element. If the cursor went past the last element or if it is currently accessing the next element, it MUST return null.

15.2 Methods

next
When this method is called, the cursor MUST change its internal state to accessing an element and proceed to access to the next element.
If this method is called while the cursor is in the process of accessing an element, the method MUST throw an "InvalidStateError" error as defined in [DOM4].
No parameters.
Return type: void
previous
When this method is called, the cursor MUST change its internal state to accessing an element and proceed to access to the previous element.
If this method is called while the cursor is in the process of accessing an element, the method MUST throw an "InvalidStateError" error as defined in [DOM4].
No parameters.
Return type: void

16. ReceivedMessage Interface

The ReceivedMessage interface represents a system message related to a received message. This event is originated from the system and will start the application if it is not currently running.

The application that consumes this API SHOULD set a message handler for the ReceivedMessage system message to listen for when a system message related to a received message is fired.

interface ReceivedMessage {
    readonly    attribute (SmsMessage or MmsMessage) message;
};

16.1 Attributes

message of type (SmsMessage or MmsMessage), readonly
MUST return the SmsMessage or MmsMessage object to which this system message is related.

17. DeliveryReport Interface

The DeliveryReport interface represents a system message related to a delivery report of a sent message. This event is originated from the system and will start the application if it is not currently running.

The application that consumes this API MAY set a message handler for the DeliveryReport system message to listen for when a system message related to a received delivery report is fired.

interface DeliveryReport {
    readonly    attribute DOMString   serviceID;
    readonly    attribute DOMString   messageID;
    readonly    attribute DOMString[] recipients;
};

17.1 Attributes

serviceID of type DOMString, readonly
MUST return the identifier of the service used to send the message to which this delivery report is related.
messageID of type DOMString, readonly
MUST return the identifier of the message to which this delivery report is related.
recipients of type array of DOMString, readonly
MUST return an array contining the addresses of the subset of the original recipients of the message to which this delivery report is related. As delivery reports related to just part of the recipients of the MMS message are possible, this array may not contain the full list of recipients to which the MMS message was sent. If the delivery report is related to an SMS message then the array will contain a single element corresponding to the single recipient of the SMS message.

18. MessagingEvent Interface

The MessagingEvent interface represents events related to a message sent or received.

interface MessagingEvent {
    readonly    attribute (SmsMessage or MmsMessage) message;
};

18.1 Attributes

message of type (SmsMessage or MmsMessage), readonly
MUST return the SmsMessage or MmsMessage object to which this event is related.

19. DeliveryReportEvent Interface

The DeliveryReportEvent interface represents events related to a delivery report of a sent message.

interface DeliveryReportEvent : Event {
    readonly    attribute DOMString   serviceID;
    readonly    attribute DOMString   messageID;
    readonly    attribute DOMString[] recipients;
};

19.1 Attributes

serviceID of type DOMString, readonly
MUST return the identifier of the service used to send the message to which this delivery report event is related.
messageID of type DOMString, readonly
MUST return the identifier of the message to which this delivery report event is related.
recipients of type array of DOMString, readonly
MUST return an array contining the addresses of the subset of the original recipients of the message to which this delivery report event is related. As delivery reports related to just part of the recipients of the MMS message are possible, this array may not contain the full list of recipients to which the MMS message was sent. If the delivery report is related to an SMS message then the array will contain a single element corresponding to the single recipient of the SMS message.

20. ServiceChangeEvent Interface

The ServiceChangeEvent interface represents events related to messaging services enabled or disabled.

interface ServiceChangeEvent : Event {
    readonly    attribute DOMString serviceID;
};

20.1 Attributes

serviceID of type DOMString, readonly
MUST return the identifier of the messaging service which is enabled or disabled.

21. MessagingFilter Dictionary

The MessagingFilter Dictionary represents a filter that is used to select a set of messages (e.g. to be provided upon invoking the findMessages or the findConversations method in the Messaging interface).

dictionary MessagingFilter {
    MessageType            type;
    Date                   startDate;
    Date                   endDate;
    DOMString              from;
    sequence<DOMString>    recipients;
    (SmsState or MmsState) state;
    DOMString              serviceID;
    boolean                read;
};

21.1 Dictionary MessagingFilter Members

type of type MessageType
Indicates whether just the SMS or MMS messages are to be provided in the results of this filter, respectively if it is set to string value 'SMS' or 'MMS'.
startDate of type Date
Indicates that messages with timestamp previous to this date will not be provided in the results of this filter.
endDate of type Date
Indicates that messages with timestamp after this date will not be provided in the results of this filter.
from of type DOMString
Indicates that just messages sent from this number are to be provided in the results of this filter.
recipients of type sequence<DOMString>
Indicates that just messages sent to one of these numbers are to be provided in the results of this filter.
state of type (SmsState or MmsState)
Indicates whether the results of this filter just needs to return the messages matching the indicated state.
serviceID of type DOMString
Indicates that just messages associated to the messaging service with this identifier are to be provided in the results of this filter.
read of type boolean
Indicates whether just read or unread messages are to be provided in the results of this filter, respectively if it is set to 'true' or 'false'.

22. FilterOptions Dictionary

dictionary FilterOptions {
    DOMString     sortBy;
    DOMString     sortOrder;
    unsigned long limit;
};

22.1 Dictionary FilterOptions Members

sortBy of type DOMString
Indicates the attribute on which the filtered messages are sorted.
sortOrder of type DOMString
Indicates the order on which the filtered messages are sorted with possible values 'ascending' and 'descending'.
limit of type unsigned long
Indicates the maximum number of messages that can be returned as a result of applying the corresponding filter.

23. Enumerations

The attibute type can have the following values:

enum MessageType {
    "sms",
    "mms"
};
Enumeration description
sms Corresponding to SMS message(s).
mms Corresponding to MMS message(s).

The attibute messageClass in an SmsMessage can have the following values:

enum MessageClass {
    "class-0",
    "class-1",
    "class-2",
    "class-3",
    "normal"
};
Enumeration description
class-0 The message is of class 0.
class-1 The message is of class 1.
class-2 The message is of class 2.
class-3 The message is of class 3.
normal The message is of class 1 (same as 'class-1').

The attibute state in an SmsMessage can have the following values:

enum SmsState {
    "received",
    "draft",
    "sending",
    "sent",
    "failed"
};
Enumeration description
received The message is an inbound message.
draft The message is a draft, i.e. it has not yet been sent.
sending The message is in process of being sent.
sent The message has been successfully sent.
failed The message is an outbound message whose submission has failed.

The attibute state in an MmsMessage can have the following values:

enum MmsState {
    "not-downloaded",
    "received",
    "draft",
    "sending",
    "sent",
    "failed"
};
Enumeration description
not-downloaded The message is an inbound message, for which an MMS mnotification has been received but that has not yet been downloaded.
received The message is an inbound message.
draft The message is a draft, i.e. it has not yet been sent.
sending The message is in process of being sent.
sent The message has been successfully sent.
failed The message is an outbound message whose submission has failed.

The attibute deliveryStatus can have the following values:

enum DeliveryStatus {
    "success",
    "pending",
    "error",
    "not-applicable"
};
Enumeration description
success The message has been succesfully delivered to the recipient.
pending The message is pending delivery.
error The delivery of the message has failed.
not-applicable The delivery status is not applicable either because a delivery report has not been requested or because the message is an inbound message

The MMS fetch mode can have the following values:

enum FetchMode {
    "automatic",
    "manual"
};
Enumeration description
automatic MMS message is fecthed right after the reception of the MMS notification.
manual The message is not fecthed until the user manually requests it.

24. Acknowledgements

The editors would like to express their gratitude to the Mozilla B2G Team and specially to Jonas Sicking, Mounir Lamouri and Vicamo Yang for their technical guidance, implementation work and support.

A. References

A.1 Normative references

[DOM4]
Anne van Kesteren; Aryeh Gregor; Lachlan Hunt; Ms2ger. DOM4. 6 December 2012. W3C Working Draft. URL: http://www.w3.org/TR/2012/WD-dom-20121206
[GSM-SMS]
Richard Burbidge. Technical realization of the Short Message Service (SMS). URL: http://www.3gpp.org/ftp/Specs/html-info/23040.htm
[HTML5]
Robin Berjon et al. HTML5. 17 December 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/html5/
[MIME-ENC]
J. Palme; A. Hopmann; N. Shelness. MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). March 1999. RFC. URL: http://www.ietf.org/rfc/rfc2557.txt
[MMS13]
Multimedia Messaging Service 1.3. 13 September 2011. Approved Enabler Release. URL: http://technical.openmobilealliance.org/Technical/release_program/mms_v1_3.aspx
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
[WEBIDL]
Cameron McCormack. Web IDL. 19 April 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/2012/CR-WebIDL-20120419/

A.2 Informative references

[OMA-PUSH]
Open Mobile Alliance. OMA Push Version 2.3. URL: http://www.openmobilealliance.org/Technical/release_program/push_v2_3.aspx