WebAPI for MMS

[Philipp von Weitershausen]

One of the last remaining pieces for Milestone 3 on the B2G roadmap
[1] is MMS. There are lots of aspects to this and I wanted to bring up
the Web API we've been musing on over the past couple of days. You can
find our notes here: https://wiki.mozilla.org/WebAPI/WebMMS.

Feedback welcome as always!

[1] https://wiki.mozilla.org/B2G/Schedule_Roadmap#Milestone_3

[Vicamo Yang]

Hi Philipp,

The MMS service defines different PDUs for operations to MMS Proxy-Relay
and MMBox. They are defined in OMA-TS-MMS_ENC-V1_3-20110913-A section 4:

1) MMS Proxy-Relay
1-a) Send (req & conf)
1-b) Fetch (req & conf)
1-c) Notification (ind & Resp.ind)
1-d) Delivery Report (ind)
1-e) Acknowledgement of delivery (ind)
1-f) Read Report (Rec.ind & Orig.ind)
1-g) Forward (req & conf)
1-h) Delete a not retrieved MM (req & conf)
1-i) Cancel a already retrieved MM (req & conf)

2) MMBox
2-a) Store/Update (req & conf)
2-b) View (req & conf)
2-c) Upload (req & conf)
2-d) Delete (req & conf)

In the API draft, there might be some problems:

I) Since there are two objects provided by MMS service, you'll have to
deal with it for best conformance of the specification. For example,
there are actually two kinds of delete operation: one for Relay-Proxy,
another for MMBox.

II) Both of delete operations accept only multiple
X-Mms-Content-Location parameters to indicate which MMs to delete. The
location indicators can come from 1-c, 2-a, 2-b depends on the object of
the operation, Proxy-Relay or MMBox. In order to retrieve location
indicators from MmsMessage, there must be a corresponding field in
database and/or encapsulated MmsMessage object.

III) For MmsManager .fetchMessage(), the specification use the term
`retrieve`. I would prefer using the same terminology with the standard.
Besides, same as II), retrieval of a MM also depends on its location
indicator.

IV) For MmsManager.forwardMessage(), the MMS service works like a Email
service. The message forwarding also allows To/Cc/Bcc as does in Email.
Besides, same as II), forwarding a MM also depends on its location
indicator.

V) For MmsManager.cancelMessage(), that's my fault, I was wrong in the
previous short presentation. The cancellation is a request from MMS
Relay-Proxy, not from MMS client. At receiving such a request, the MMS
client should cancel the previously retrieved MM having the same
Message-ID as indicated by the X-Mms-Cancel-ID field.

VI) Events: sent/delivered/read/canceled/..

VII) MMBox operations?

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>
--
Vicamo Yang ???
Mozilla Taiwan
T: +886-2-87861100 # 309
M: +886-910567401

[JOSE MANUEL CANTERA FONSECA]

El 12/04/12 10:17, "Philipp von Weitershausen" <phil...@googlemail.com>
escribió:

>One of the last remaining pieces for Milestone 3 on the B2G roadmap
>[1] is MMS. There are lots of aspects to this and I wanted to bring up
>the Web API we've been musing on over the past couple of days. You can
>find our notes here: https://wiki.mozilla.org/WebAPI/WebMMS.
>
>Feedback welcome as always!

I have the same concern as with other APIs. It seems there is no intention
to try to refactor APIs in more generic ones. I'm seeing in this API many
overlaps with WebSMS, so I wonder why don't we create an API for Messaging
that encompasses at least the SMS and MMS APIs.

I think a similar effort might be worth for Network Connections. But that
should be part of another thread

>
>[1] https://wiki.mozilla.org/B2G/Schedule_Roadmap#Milestone_3
>_______________________________________________
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
>

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Mounir Lamouri]

On 04/12/2012 01:35 PM, JOSE MANUEL CANTERA FONSECA wrote:
> I have the same concern as with other APIs. It seems there is no intention
> to try to refactor APIs in more generic ones. I'm seeing in this API many
> overlaps with WebSMS, so I wonder why don't we create an API for Messaging
> that encompasses at least the SMS and MMS APIs.

We should definitely use a common API. In my opinion, WebMMS should
merge into WebSMS. If people really care about, we could rename this to
a more generic name but personally if WebSMS handles MMS too, it's okay.

** MmsManager **

We can easily make a generic SmsManager that will handle what MmsManager
does.
For send() methods, I think we should add a method that allows sending a
message with data (attachments or document). Your methods are weird
because a MmsMessage needs a delivery status and calling send() with
such a message doesn't really make sens given that the request resulting
from send() should create the message with the appropriate status.
fetchMessage() should probably move to MmsMessage.
forwardMessage(): I've no idea why that's part of the API. That should
be a UI issue.
cancelMessage(): I'm not sure what is that for...

** MmsMessage **

Most of it is exactly like SmsMessage so I think we should whether have
MmsMessage inheriting from SmsMessage or MmsMessage being merged with
SmsMessage and some properties returning null or an exception if reached
when the message in actually an SMS. We could add a |type| attribute to
know the message type.
I do not agree that "unfetched" is a delivery status. Delivery should be
as simple as received/sent. An unfetched message is received. There are
multiple ways to handle that in another way like adding a boolean or
making attachments and contentDocument returning null if unfetched, ...

** MmsAttachment **

I hope we could make that look simpler but anyhow, it will not make
merging those APIs impossible.

Cheers,
--
Mounir

[Philipp von Weitershausen]

On Fri, Apr 13, 2012 at 12:05 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> On 04/12/2012 01:35 PM, JOSE MANUEL CANTERA FONSECA wrote:
>> I have the same concern as with other APIs. It seems there is no intention
>> to try to refactor APIs in more generic ones. I'm seeing in this API many
>> overlaps with WebSMS, so I wonder why don't we create an API for Messaging
>> that encompasses at least the SMS and MMS APIs.
>
> We should definitely use a common API. In my opinion, WebMMS should
> merge into WebSMS. If people really care about, we could rename this to
> a more generic name but personally if WebSMS handles MMS too, it's okay.

This is fine by me. I'm on the fence personally since I could come up
with arguments for either side. Merging the two APIs would also give
us the opportunity to brush up the SMS API a bit, e.g. use DOMRequest.

> ** MmsManager **
>
> We can easily make a generic SmsManager that will handle what MmsManager
> does.
> For send() methods, I think we should add a method that allows sending a
> message with data (attachments or document). Your methods are weird
> because a MmsMessage needs a delivery status and calling send() with
> such a message doesn't really make sens given that the request resulting
> from send() should create the message with the appropriate status.

I guess this is a philosophical issue. Having the user agent create
the message object after sending it works well for SMS because there
isn't much information to pass into the send() method. With MMS
there's much more, so to me it kinda made sense to create the message
object first and then act upon it. I don't think this is so uncommon
(e.g. think of Blob/File and the Contacts API, for instance).

> fetchMessage() should probably move to MmsMessage.

I had it there originally, but then moved it to MmsManager since
MmsMessage was otherwise without any methods. I don't really care
where it lives.

> forwardMessage(): I've no idea why that's part of the API. That should
> be a UI issue.
> cancelMessage(): I'm not sure what is that for...

Those are features that are supported by the network -- see Vicamo's
reply. These are not just mere UI features. That said, we can skip
those in the first round of the API, probably.

> ** MmsMessage **
>
> Most of it is exactly like SmsMessage

... for a reason ;)

> so I think we should whether have
> MmsMessage inheriting from SmsMessage or MmsMessage being merged with
> SmsMessage and some properties returning null or an exception if reached
> when the message in actually an SMS. We could add a |type| attribute to
> know the message type.

Sounds good.

> I do not agree that "unfetched" is a delivery status. Delivery should be
> as simple as received/sent. An unfetched message is received. There are
> multiple ways to handle that in another way like adding a boolean or
> making attachments and contentDocument returning null if unfetched, ...

Ok, will revise.

> ** MmsAttachment **
>
> I hope we could make that look simpler but anyhow, it will not make
> merging those APIs impossible.

Yup, I agree. It's about as simple as I could make it -- simply an
Array of Blobs like you suggested wouldn't work since the attachments
need to be looked up by name. And as a perf feature, I added a URI
lookup to the blob interface so that we don't have to load them into
memory first to compose, e.g. a data: URI. This seems like a generally
useful feature for Blobs, though, so perhaps we can lift that out into
FileReader or so and make this API a bit simpler.

[Vicamo Yang]

On 04/13/2012 01:00 PM, Philipp von Weitershausen wrote:
> On Fri, Apr 13, 2012 at 12:05 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
>> ** MmsManager **
>>
>> We can easily make a generic SmsManager that will handle what MmsManager
>> does.
>> For send() methods, I think we should add a method that allows sending a
>> message with data (attachments or document). Your methods are weird
>> because a MmsMessage needs a delivery status and calling send() with
>> such a message doesn't really make sens given that the request resulting
>> from send() should create the message with the appropriate status.
> I guess this is a philosophical issue. Having the user agent create
> the message object after sending it works well for SMS because there
> isn't much information to pass into the send() method. With MMS
> there's much more, so to me it kinda made sense to create the message
> object first and then act upon it. I don't think this is so uncommon
> (e.g. think of Blob/File and the Contacts API, for instance).

SMS message can also be very complex, it's the feature set we had
implemented is simple. There is also EMS(Enhanced Message Service) for
SMS, which provides similar multimedia experience as MMS.

>> forwardMessage(): I've no idea why that's part of the API. That should
>> be a UI issue.
>> cancelMessage(): I'm not sure what is that for...
> Those are features that are supported by the network -- see Vicamo's
> reply. These are not just mere UI features. That said, we can skip
> those in the first round of the API, probably.

Message forwarding in MMS is a predefined operation which SMS doesn't
have. Forwarding an MM in UI implies re-sending the MM again, and this
could have side-effects like more 3G/wifi data spent, therefore comes
more expense, and omitted fields/parts since SMS database API never
preserves the whole message PDU.

>> so I think we should whether have
>> MmsMessage inheriting from SmsMessage or MmsMessage being merged with
>> SmsMessage and some properties returning null or an exception if reached
>> when the message in actually an SMS. We could add a |type| attribute to
>> know the message type.
> Sounds good.

Please also note the differences between MMS and SMS by their nature.
For example, MMS can come with multiple customized header for
per-application use. The MMS isn't only for messaging app, but also
possible for other data exchanging services specified by X-Mms-Applic-ID
header: "If an MMS Client receives an MMS PDU that contains an
application identifier ('X-Mms-Applic-ID') the MMS Client is
responsible to route the received MMS information to the destination
application according to the negotiated details upon application
registration process." ~ OMA-AD-MMS-V1_3-20110913-A

>> ** MmsAttachment **
>>
>> I hope we could make that look simpler but anyhow, it will not make
>> merging those APIs impossible.
> Yup, I agree. It's about as simple as I could make it -- simply an
> Array of Blobs like you suggested wouldn't work since the attachments
> need to be looked up by name.

And an attachment can also have it's own parameters, not just a name.
For example, a text-based attachment can have a ` charset` parameter in
header Content-Type. For other MIME parameters, see also
http://www.ietf.org/rfc/rfc2045.txt .

[Philipp von Weitershausen]

On Thu, Apr 12, 2012 at 5:17 AM, Philipp von Weitershausen
<phil...@googlemail.com> wrote:
> One of the last remaining pieces for Milestone 3 on the B2G roadmap
> [1] is MMS. There are lots of aspects to this and I wanted to bring up
> the Web API we've been musing on over the past couple of days. You can
> find our notes here: https://wiki.mozilla.org/WebAPI/WebMMS.

Robert Nyman has provided some useful input and pointed me to the
window.URL API for creating temporary URLs for blobs. This should make
the need for a Blob-subtype for the binary MMS attachments
unnecessary. I have updated the API draft and examples on
https://wiki.mozilla.org/WebAPI/WebMMS accordingly.

Next up I will try to address the other useful comments that have been
discussed on this list.

[Jonas Sicking]

On Fri, Apr 13, 2012 at 2:30 AM, Vicamo Yang <vy...@mozilla.com> wrote:
> Please also note the differences between MMS and SMS by their nature.
> For example, MMS can come with multiple customized header for
> per-application use. The MMS isn't only for messaging app, but also
> possible for other data exchanging services specified by X-Mms-Applic-ID
> header: "If an MMS Client receives an MMS PDU that contains an
> application identifier ('X-Mms-Applic-ID') the MMS Client is
> responsible to route the received MMS information to the destination
> application according to the negotiated details upon application
> registration process." ~ OMA-AD-MMS-V1_3-20110913-A

I suspec that MMS messages that come with such headers shouldn't be
delivered through the normal MMS API, but through some other
specialized API. Alternatively it could be delivered through the MMS
API, but gecko would ensure to only deliver it to the application at
which it was targeted.

/ Jonas

[Vicamo Yang]

Hi,

Yesterday Kan-ru, HsinYi, Price and I had a meeting about merging
SMS/MMS webapi. We would like to give some results/proposal below and
your opinions are welcome.

The changes made are mainly renames of various types, and current SMS
implementation will mostly left untouched. The most significant change
should be retype and rename `SmsMessage.body` to a nsIDOMDocument-typed
attribute `contentDocument`, which will embrace both SMS and MMS content
and allow sharing underlying database and providing same API for user
applications dealing with SMS/MMS messages. The
`SmsService.createSmsMessage` is removed, use constructor of the new
message type instead.

For differences between previous WebMMS API proposal:

1. the two `send` function in MmsManager is unified as one.
2. {fetch,forward,cancel}Message APIs in MmsManager are obsoleted for now.

Note that DOMRequest transition is *NOT* covered in following diff,
although it's already in plan.

[Renames]

* nsIDOMMozNavigatorSms to nsIDOMMozNavigatorMessage
* nsIDOMMozSmsManager to nsIDOMMozMessageManager
* nsIDOMMozSmsMessage to nsIDOMMozMessage
* nsIDOMMozSmsRequest to nsIDOMMozMessageRequest
* nsIDOMMozSmsEvent to nsIDOMMozMessageEvent
* nsIDOMMozSmsFilter to nsIDOMMozMessageFilter
* nsIDOMMozSmsCursor to nsIDOMMozMessageCursor
* nsISmsRequestManager to nsIMessageRequestManager
* nsISmsDatabaseService to nsIMessageDatabaseService
* nsISmsService to nsIMessageService

[API Changes]

// Rename only
-interface nsIDOMMozNavigatorSms : nsISupports
+interface nsIDOMMozNavigatorMessage : nsISupports
{
// Rename only
- readonly attribute nsIDOMMozSmsManager mozSms;
+ readonly attribute nsIDOMMozMessageManager mozMessage;
};

// Rename only
-interface nsIDOMMozSmsCursor : nsISupports
+interface nsIDOMMozMessageCursor : nsISupports
{
// Rename only
- readonly attribute nsIDOMMozSmsMessage message;
+ readonly attribute nsIDOMMozMessage message;

void continue();
};

// Rename only
-interface nsIDOMMozSmsEvent : nsIDOMEvent
+interface nsIDOMMozMessageEvent : nsIDOMEvent
{
// Rename only
[binaryname(MessageMoz)]
- readonly attribute nsIDOMMozSmsMessage message;
+ readonly attribute nsIDOMMozMessage message;
};

// Rename only
-interface nsIDOMMozSmsFilter : nsISupports
+interface nsIDOMMozMessageFilter : nsISupports
{
...
};

-interface nsIDOMMozSmsManager : nsIDOMEventTarget
+interface nsIDOMMozMessageManager : nsIDOMEventTarget
{
unsigned short getNumberOfMessagesForText(in DOMString text);

// Send a message object instead of text string and always return an
// array of nsIDOMMozMessageRequest objects. The `number` parameter is
// removed and nsIDOMMozMessage.receiver will be referred to.
- jsval send(in jsval number,
- in DOMString message);
+ void send(in nsIDOMMozMessage message,
+ out unsigned long length,
+ [array, size_is(length), retval] out nsIDOMMozMessageRequest requests);

// Rename only
- [binaryname(GetMessageMoz)] nsIDOMMozSmsRequest getMessage(in long id);
+ [binaryname(GetMessageMoz)] nsIDOMMozMessageRequest getMessage(in long
id);

// Rename only
- nsIDOMMozSmsRequest delete(in jsval param);
+ nsIDOMMozMessageRequest delete(in jsval param);

// Rename only
- nsIDOMMozSmsRequest getMessages(in nsIDOMMozSmsFilter filter,
- in boolean reverse);
+ nsIDOMMozMessageRequest getMessages(in nsIDOMMozMessageFilter filter,
+ in boolean reverse);

...
};

// Constructor of nsIDOMMozMessage class.
+nsIDOMMozMessagensIDOMMozMessage(
+anyreceiver,
+Document document
+);

[Constructor]
-interface nsIDOMMozSmsMessage : nsISupports
+interface nsIDOMMozMessage : nsISupports
{
...

// Retype and rename message body attribute to a nsIDOMDocument-typed
// contentDocument attribute. The Content-Type of this attribute will be
// "text/plain" for SMS & text-based MMS, and "application/smil+xml" for
// SMIL-based MMS. Other values may also be possible.
- readonly attribute DOMString body;
+ readonly attribute nsIDOMDocument contentDocument;

// For MMS attachments
+ readonly attribute MessageAttachmentStorage attachments;
};

// New interface for message attachments access
+interface MessageAttachmentStorage
+{
+getter Blob getAttachment(DOMString name);
+setter creator void setAttachment(DOMString name, Blob attachment);
+deleter void deleteAttachment(DOMString name);
+}

// Rename only
-interface nsIDOMMozSmsRequest : nsIDOMEventTarget
+interface nsIDOMMozMessageRequest : nsIDOMEventTarget
{
...
};

-interface nsISmsDatabaseService : nsISupports
+interface nsIMessageDatabaseService : nsISupports
{
// Accept a nsIDOMMozMessage object instead of enumeration of all
// storable attributes.
- long saveReceivedMessage(in DOMString aSender,
- in DOMString aBody,
- in unsigned long long aDate);
+ long saveReceivedMessage(in nsIDOMMozMessage aMessage);

// Accept a nsIDOMMozMessage object instead of enumeration of all
// storable attributes.
- long saveSentMessage(in DOMString aReceiver,
- in DOMString aBody,
- in unsigned long long aDate);
+ long saveSentMessage(in nsIDOMMozMessage aMessage);

// Rename only
- void createMessageList(in nsIDOMMozSmsFilter filter,
+ void createMessageList(in nsIDOMMozMessageFilter filter,
in boolean reverse,
in long requestId,
[optional] in unsigned long long processId);
};

// Rename only
-interface nsISmsRequestManager : nsISupports
+interface nsIMessageRequestManager : nsISupports
{
// Rename only
- long createRequest(in nsIDOMMozSmsManager aManager,
- out nsIDOMMozSmsRequest aRequest);
+ long createRequest(in nsIDOMMozMessageManager aManager,
+ out nsIDOMMozMessageRequest aRequest);

// Rename only
- long addRequest(in nsIDOMMozSmsRequest aRequest);
+ long addRequest(in nsIDOMMozMessageRequest aRequest);

// Rename only
- void notifySmsSent(in long aRequestId,
- in nsIDOMMozSmsMessage aMessage);
+ void notifyMessageSent(in long aRequestId,
+ in nsIDOMMozMessage aMessage);

// Rename only
- void notifySmsSendFailed (in long aRequestId,
+ void notifyMessageSendFailed(in long aRequestId,
in long aError);

// Rename only
- void notifyGotSms(in long aRequestId,
- in nsIDOMMozSmsMessage aMessage);
+ void notifyGotMessage(in long aRequestId,
+ in nsIDOMMozMessage aMessage);

// Rename only
- void notifyGetSmsFailed (in long aRequestId,
+ void notifyGetMessageFailed(in long aRequestId,
in long aError);

// Rename only
- void notifySmsDeleted (in long aRequestId,
+ void notifyMessageDeleted(in long aRequestId,
in bool aDeleted);

// Rename only
- void notifySmsDeleteFailed (in long aRequestId,
+ void notifyMessageDeleteFailed(in long aRequestId,
in long aError);

// Rename only
void notifyCreateMessageList(in long aRequestId,
in long aListId,
- in nsIDOMMozSmsMessage aMessage);
+ in nsIDOMMozMessage aMessage);

// Rename only
void notifyGotNextMessage(in long aRequestId,
- in nsIDOMMozSmsMessage aMessage);
+ in nsIDOMMozMessage aMessage);
};

-interface nsISmsService : nsISupports
+interface nsIMessageService : nsISupports
{
boolean hasSupport();
unsigned short getNumberOfMessagesForText(in DOMString text);

// Send a message object instead of text string. The `number` parameter
// is removed and nsIDOMMozMessage.receiver will be referred to.
- void send(in DOMString number,
- in DOMString message,
+ void send(in nsIDOMMozMessage message,
in long requestId,
[optional] in unsigned long long processId);

// Removed. Use nsIDOMMozMessage's constructor instead.
[implicit_jscontext]
- nsIDOMMozSmsMessage createSmsMessage(in long id,
- in DOMString delivery,
- in DOMString sender,
- in DOMString receiver,
- in DOMString body,
- in jsval timestamp);
};


--
Vicamo Yang 楊有勝

[Vicamo Yang]

> [Renames]
> * nsIDOMMozSmsEvent to nsIDOMMozMessageEvent

There is already an interface named nsIDOMMessageEvent in
dom/interfaces/events. This might cause a "The interface XXX was not
found in the idl file YYY" error raised by dombindingsgen.py.

[Vicamo Yang]

[Vicamo Yang]

[JOSE MANUEL CANTERA FONSECA]

El 16/05/12 06:46, "Vicamo Yang" <vy...@mozilla.com> escribió:

>Hi,
>
>Yesterday Kan-ru, HsinYi, Price and I had a meeting about merging
>SMS/MMS webapi. We would like to give some results/proposal below and
>your opinions are welcome.

That's great!

Would it be possible to send the proposed API in a more readable format
i.e. WebIDL?

>
>
>
>--
>Vicamo Yang 楊有勝
>Mozilla Taiwan
>T: +886-2-87861100 # 309
>M: +886-910567401
>

[Mounir Lamouri]

As Jose said, this is not readable. Could you send this in another format?

Thanks,
--
Mounir

On 05/16/2012 06:46 AM, Vicamo Yang wrote:
> Hi,
>
> Yesterday Kan-ru, HsinYi, Price and I had a meeting about merging
> SMS/MMS webapi. We would like to give some results/proposal below and
> your opinions are welcome.
>

[Vicamo Yang]

Sorry, let me to try again:

interface MmsManager : nsIDOMEventTarget
{
/**
* Send a MMS message out and return an array of DOMRequest objects.
* Receiversare specified in `receivers` attribute of message.
*/
DOMRequest[] send(MmsMessage message);

/**
* Delete a message specified by `param`, which can be a id or a MmsMessage
* object.
*/
DOMRequest delete(in jsval param);

/**
* Retrieve a message by its id.
*/
DOMRequest getMessage(in long id);

/**
* Retrieve messages matching with filter. The defaults value of `reverse` is
* false.
*/
DOMRequest getMessages(in MessageFilter filter,
[optional] in boolean reverse);

/**
* The `param` can be a id or a MmsMessage.
*/
DOMRequestmarkMessageRead(in jsval param,
in boolean read);

attribute nsIDOMEventListener onreceived;
attribute nsIDOMEventListener onsent;
attribute nsIDOMEventListener ondelivered;
attribute nsIDOMEventListener onread;
}

[Constructor]
interface MmsMessage : nsISupports
{
const unsigned short PRIORITY_LOW = 128;
const unsigned short PRIORITY_NORMAL = 129;
const unsigned short PRIORITY_HIGH = 130;

const unsigned short REPLY_CHARGING_REQUESTED = 128;
const unsigned short REPLY_CHARGING_REQUESTED_TEXT_ONLY = 129;
const unsigned short REPLY_CHARGING_ACCEPTED = 130;
const unsigned short REPLY_CHARGING_ACCEPTED_TEXT_ONLY = 131;

const unsigned short CONTENT_CLASS_TEXT = 128;
const unsigned short CONTENT_CLASS_IMAGE_BASIC = 129;
const unsigned short CONTENT_CLASS_IMAGE_RICH = 130;
const unsigned short CONTENT_CLASS_VIDEO_BASIC = 131;
const unsigned short CONTENT_CLASS_VIDEO_RICH = 132;
const unsigned short CONTENT_CLASS_MAGA_PIXEL = 133;
const unsigned short CONTENT_CLASS_CONTENT_BASIC = 134;
const unsigned short CONTENT_CLASS_CONTENT_RICH = 135;

readonly attribute long id;

/**
* "draft", "sending", "sent", "delivered", "received"
*/
readonly attribute DOMString delivery;

/**
* Should be "from", but use the same name as SMS did.
*/
readonly attribute DOMString sender;

/**
* All recipients: to, cc or bcc.Should be "recipients", but use the same
* name as SMS did.
*/
readonly attribute DOMString[] receivers;
attribute DOMString[] to;
attribute DOMString[] cc;
attribute DOMString[] bcc;

/**
* Date and time of submission of the message.
*/
attribute Date timestamp;

/**
* Presentation(main) part of the message. Null if unavailable.
*/
attribute Document contentDocument;

readonly attribute MmsAttachmentStorage attachments;

/**
* Optional header fields defined in MMS specification.
*/

/**
* Only valid in received messages.
*/
readonly attribute DOMString previouslySentBy;
readonly attribute Date previouslySentDate;
readonly attribute boolean distributionIndicator;

/**
* Only valid in outgoing messages.
*/
attribute boolean senderVisibility;
attribute boolean storeSent;
attribute boolean adaptationAllowed;

attribute DOMString subject;

/**
* "personal", "advertisement", "informational", "auto" or other strings.
*/
attribute DOMStringmessageClass;

/** See PRIORITY_* */
attribute unsigned short priority;

attribute Date expiry;
attribute boolean deliveryReport;
attribute boolean readReport;

/** See REPLY_CHARGING_* */
attribute unsigned short replyCharging;

attribute Date replyChargingDeadline;
attribute long replyChargingSize;
attribute DOMString replyChargingID;

/** See CONTENT_CLASS_* */
attribute unsigned short contentClass;

attribute boolean drmContent;
attribute DOMString replaceID;
}

interface MmsAttachmentStorage : nsISupports
{
getter Blob getAttachment(DOMString name);

setter creator void setAttachment(DOMString name, Blob attachment);

deleter void deleteAttachment(DOMString name);
}

interface MessageFilter : nsISupports
{
attribute jsval startDate;
attribute jsval endDate;

// An array of DOMString that can return null.
attribute jsval recipients;

/**
* A DOMString that can return and be set to "draft", "sending", "sent",
* "received" or null.
*/
attribute DOMString delivery;

// A read flag that can be a boolean or undefined.
attribute jsval read;

}

On 05/30/2012 09:08 PM, Mounir Lamouri wrote:
> As Jose said, this is not readable. Could you send this in another format?
>
> Thanks,
> --
> Mounir
>

[Vicamo Yang]

(re-format in plain text)

interface MmsManager : nsIDOMEventTarget
{
/**
* Send a MMS message out and return an array of DOMRequest objects.
* Receiversare specified in `receivers` attribute of message.
*/
DOMRequest[] send(MmsMessage message);

/**
* Delete a message specified by `param`, which can be a id or a

* MmsMessage object.

*/
DOMRequest delete(in jsval param);

/**
* Retrieve a message by its id.
*/
DOMRequest getMessage(in long id);

/**
* Retrieve messages matching with filter. The defaults value of

* `reverse` is false.

*/
DOMRequest getMessages(in MessageFilter filter,
[optional] in boolean reverse);

/**
* The `param` can be a id or a MmsMessage.
*/

DOMRequest markMessageRead(in jsval param,

* same name as SMS did.
*/

* strings.
*/
attribute DOMString messageClass;

* "sent", "received" or null.

[Vicamo Yang]

Hi,

Anyone has comments?

There are plenty of new attributes in MmsMessage. Each of them comes
from the corresponding header field in either M-Send.req,
M-Retrieve.conf or M-Notification.ind PDU. SMS messages have also lots
of attributes remained unimplemented, too. Some of them had already
bugzilla issue opened, see 736701 and 736708. I hope we can have some
kind of early solution for these attributes because it may takes much
more efforts to alter every parameter list of functions in related.
Maybe we should identify all attributes known and only include specific
ones in message constructors and leave others optional attributes and
initialize them after instantiation.

[Vicamo Yang]

On 05/31/2012 12:45 AM, Vicamo Yang wrote:
> (re-format in plain text)
>

> [Constructor]
> interface MmsMessage : nsISupports
> {
> readonly attribute long id;

There are two more identities used in MMS specification: one for
X-Mms-Transaction-ID, another for Message-ID. The former relates
sending/retrieval transactions between MMS client and the MMS Proxy
Relay; the latter relates messages of different transactions, eg. the
original message and its delivery report. They can be stored in database
only, hidden from the MMS app and are therefore not shown here.

> /**
> * "draft", "sending", "sent", "delivered", "received"
> */
> readonly attribute DOMString delivery;

"delivered" should be dropped. MMS allows multiple recipients assigned,
which follows multiple delivery reports can be possible and should be
addressed somewhere else. May also need "unknown" for initial state.

> /**
> * Should be "from", but use the same name as SMS did.
> */
> readonly attribute DOMString sender;

I would really like to rename it back to `from`.

> /**
> * Date and time of submission of the message.
> */
> attribute Date timestamp;

The naming in MMS specification is `date`.

> /**
> * Only valid in received messages.
> */
> readonly attribute DOMString previouslySentBy;

`This field MAY appear multiple times.` says the MMS spec.

> readonly attribute Date previouslySentDate;

`This field MAY appear multiple times.` says the MMS spec.

> /** See CONTENT_CLASS_* */
> attribute unsigned short contentClass;

Should be hidden from MMS app.

> attribute boolean drmContent;

This field exists in both incoming and outgoing PDUs.

> attribute DOMString replaceID;

This field exists only in M-Retrieve.conf and M-Notification.ind PDU,
not M-Send.req.

> }
>
> interface MmsAttachmentStorage : nsISupports
> {
> getter Blob getAttachment(DOMString name);
> setter creator void setAttachment(DOMString name,
> Blob attachment);

We MUST also known the Content-Type of the attachment.

> deleter void deleteAttachment(DOMString name);

[Mounir Lamouri]

On 06/04/2012 07:37 AM, Vicamo Yang wrote:
> Hi,
>
> Anyone has comments?
>
> There are plenty of new attributes in MmsMessage. Each of them comes
> from the corresponding header field in either M-Send.req,
> M-Retrieve.conf or M-Notification.ind PDU. SMS messages have also lots
> of attributes remained unimplemented, too. Some of them had already
> bugzilla issue opened, see 736701 and 736708. I hope we can have some
> kind of early solution for these attributes because it may takes much
> more efforts to alter every parameter list of functions in related.
> Maybe we should identify all attributes known and only include specific
> ones in message constructors and leave others optional attributes and
> initialize them after instantiation.

I think you should re-think this API to make it more high level. You
have way too many attributes no one cares about. As an app developer,
sending an MMS should be nearly as simple as sending an SMS except that
you can attach data. Anything else should be considered as details
handled by the API implementation.

--
Mounir

[Vicamo Yang]

On 06/20/2012 11:54 PM, Mounir Lamouri wrote:
> I think you should re-think this API to make it more high level. You
> have way too many attributes no one cares about. As an app developer,
> sending an MMS should be nearly as simple as sending an SMS except that
> you can attach data. Anything else should be considered as details
> handled by the API implementation.

Except there are hundreds of test cases to pass defined in
OMA-ETS-MMS_CON-V1_3-20101015-C. And we're requested to pass a certain
MMS certification by carriers.

[5.1.1.1.9 MMS-1.3-con-111 - Subject field with UTF8 encoding]
[5.6.1.8 MMS-1.3-con-738 - Support for Subject field]
So there must be a `subject` field in MmsMessage.

[5.4.1.1 MMS-1.3-con-601 - Delivery report – Retrieved message]
[5.4.1.2 MMS-1.3-con-602 - Delivery report – Rejected message]
[5.4.1.3 MMS-1.3-con-603 - Delivery report – Expired message]
[5.4.1.4 MMS-1.3-con-604 - Delivery report – Multiple recipients each
with Different Delivery Status]
So there must be a `ondelivered` event in MmsManager. In fact, the
`ondelivered` event should be renamed to `ondelivery` to cover delivery
failure cases. Besides, there can be multiple delivery report for one
single sent message, the `ondelivery` event should also carry
information of the originator.

[5.4.2.1 MMS-1.3-con-605 - Read-Reply report Date]
[5.4.2.3 MMS-1.3-con-607 - Read-Reply Report when sending to multiple
recipients]
So there must be a `onread` event in MmsManager. Multiple recipients
problem must also be addressed.

[5.4.3.1 MMS-1.3-con-611 - Forward without Prior retrieval]
[5.4.3.2 MMS-1.3-con-612 Forward without prior retrieval - Validity
Period (Expiry
Time) set by Client when forwarding]
Message forwarding must be supported in MmsManager.

[5.4.4.1 MMS-1.3-con-623 - Cancel]
Message cancellation must be supported in MmsManager.

[5.5.1.1 MMS-1.3-con-701 - Download options – Immediate retrieval]
[5.5.1.2 MMS-1.3-con-702 - Download options – Deferred retrieval]
[5.5.1.3 MMS-1.3-con-703 - Download options – Rejected retrieval]
Download options. Maybe through settings API.

[5.5.2.1.1 MMS-1.3-con-704 - DRM support – Forward Lock]
The message object should have a `drmContent` so that an app knows it
can't be forwarded. We can also hide this field from app and throw an
error instead.

[5.6.1.3 MMS-1.3-con-733 - Support for Date field]
[5.6.1.4 MMS-1.3-con-734 - Support for From field]
[5.6.1.5 MMS-1.3-con-735 - Support for To field]
[5.6.1.6 MMS-1.3-con-736 - Support for Cc field]
[5.6.1.7 MMS-1.3-con-737 - Support for Bcc field]
[5.6.1.9 MMS-1.3-con-739 - Support for X-Mms-Message-Class field]
[5.6.1.10 MMS-1.3-con-740 - Support for X-Mms-Expiry field – Relative]
[5.6.1.14 MMS-1.3-con-744 - Support for X-Mms-Priority field – Low]
[5.6.1.17 MMS-1.3-con-747 - Support for X-Mms-Delivery-Report field]
[5.6.1.18 MMS-1.3-con-748 - Support for X-Mms-Read-Report field]
[5.6.1.19 MMS-1.3-con-749 - Support for X-MMS-Adaptation-Allowed field]
`date`, `from`, `to`, `cc`, `bcc`, `messageClass`, `expiry`, `priority`,
`deliveryReport`, `readReport`, `adaptationAllowed` attributes in
MmsMessage.

[5.6.1.12 MMS-1.3-con-742 - Support for X-Mms-Delivery-Time field –
Relative]
`deliveryTime` is still not addressed in previous API proposal.


Following attributes are defined in previous proposal but not neccessary
to pass ETS:
`previouslySentBy`, `previouslySentDate`, `distributionIndicator`,
`senderVisibility`, `storeSent`, `replyCharging`,
`replyChargingDeadline`, `replyChargingSize`, `replyChargingID`

Following attributes should be hidden from app:
`replaceID`, `contentClass`

[Vicamo Yang]

Hi all,

Here is an updated proposal with ETS discussion addressed. Changes are:

1. add interface definitions for MmsEvent, MmsDeliveryEvent;
2. rename `sender` to `from`, `receiver` to `recipients` in MmsMessage;
3. add deliveryTime. Also re-type `expiry` to "any";
4. remove attributes `previouslySentBy`, `previouslySentDate`,

`distributionIndicator`, `senderVisibility`, `storeSent`,
`replyCharging`, `replyChargingDeadline`, `replyChargingSize`,

`replyChargingID`, `replaceID`, `contentClass`;
5. add `forward` support in MmsManager.
6. add `oncancelled` event in MmsManager.


interface MmsEvent : nsIDOMEvent
{
readonly attribute nsIDOMMozMmsMessage message;
}

interface MmsDeliveryEvent : nsIDOMEvent
{
readonly attribute nsIDOMMozMmsMessage message;
readonly attribute DOMString originator;

}

interface MmsManager : nsIDOMEventTarget
{
/**
* Send a MMS message out and return an array of DOMRequest objects.
* Receiversare specified in `receivers` attribute of message.
*/

DOMRequest[] send(in MmsMessage message);

/**
* Delete a message specified by `param`, which can be a id or a
* MmsMessage object.
*/

DOMRequest delete(in any param);

/**
* Forward a message specified by `param`, which can ba a id or a
* MmsMessage object, with new settings specified by `message`.
*/
DOMRequest forward(in any param,
in MmsMessage message);

/**
* Retrieve a message by its id.
*/
DOMRequest getMessage(in long id);

/**
* Retrieve messages matching with filter. The defaults value of
* `reverse` is false.
*/
DOMRequest getMessages(in MessageFilter filter,
[optional] in boolean reverse);

/**
* The `param` can be a id or a MmsMessage.
*/

DOMRequest markMessageRead(in any param,
in boolean read);

// MmsEvent
attribute nsIDOMEventListener onreceived;
// MmsEvent
attribute nsIDOMEventListener onsent;
// MmsDeliveryEvent
attribute nsIDOMEventListener ondelivery;
// MmsDeliveryEvent
attribute nsIDOMEventListener onread;

/**
* A MMS Proxy-Relay MAY request an MMS Client, that an MM, which the
* MMS Client has already retrieved to be cancelled.
*/
// MmsEvent
attribute nsIDOMEventListener oncancelled;
}

[Constructor]
interface MmsMessage : nsISupports
{
const unsigned short PRIORITY_LOW = 0;
const unsigned short PRIORITY_NORMAL = 1;
const unsigned short PRIORITY_HIGH = 2;

readonly attribute long id;

/**
* "draft", "sending", "sent", "delivered", "received"
*/
readonly attribute DOMString delivery;

readonly attribute DOMString from;

/**
* All recipients: to, cc or bcc.

*/
readonly attribute DOMString[] recipients;

attribute DOMString[] to;
attribute DOMString[] cc;
attribute DOMString[] bcc;

/**
* Date and time of submission of the message.
*/

attribute Date date;

/**
* A Date object or relative time in seconds.
*/
attribute any expiry;
attribute any deliveryTime;

/**
* Presentation(main) part of the message. Null if unavailable.
*/
attribute Document contentDocument;

readonly attribute MmsAttachmentStorage attachments;

attribute boolean adaptationAllowed;

attribute DOMString subject;

/**
* "personal", "advertisement", "informational", "auto" or other
* strings.
*/
attribute DOMString messageClass;

/** See PRIORITY_* */
attribute unsigned short priority;

attribute boolean deliveryReport;
attribute boolean readReport;

attribute boolean drmContent;

}

interface MmsAttachmentStorage : nsISupports
{
getter Blob getAttachment(DOMString name);
setter creator void setAttachment(DOMString name,
Blob attachment);

deleter void deleteAttachment(DOMString name);
}

interface MessageFilter : nsISupports
{
attribute jsval startDate;
attribute jsval endDate;

// An array of DOMString that can return null.
attribute jsval recipients;

/**
* A DOMString that can return and be set to "draft", "sending",
* "sent", "received" or null.
*/
attribute DOMString delivery;

// A read flag that can be a boolean or undefined.
attribute jsval read;
}

[Vicamo Yang]

Updates previous MMS API proposal. Mostly removals of optional message
attributes.

On 06/21/2012 01:58 AM, Vicamo Yang wrote:
> Hi all,
>
> Here is an updated proposal with ETS discussion addressed. Changes are:
>
> 1. add interface definitions for MmsEvent, MmsDeliveryEvent;
> 2. rename `sender` to `from`, `receiver` to `recipients` in MmsMessage;
> 3. add deliveryTime. Also re-type `expiry` to "any";
> 4. remove attributes `previouslySentBy`, `previouslySentDate`,
> `distributionIndicator`, `senderVisibility`, `storeSent`,
> `replyCharging`, `replyChargingDeadline`, `replyChargingSize`,
> `replyChargingID`, `replaceID`, `contentClass`;
> 5. add `forward` support in MmsManager.
> 6. add `oncancelled` event in MmsManager.

7. Remove MmsMessage.deliveryReport. The ETS doesn't test outgoing messages with X-Mms-Delivery-Report set to false, so we can always request it to reduce interface complexity.

8. Remove MmsMessage.readReport. The ETS doesn't test outgoing messages with X-Mms-Read-Report set to false, so we can always request it to reduce interface complexity.

9. Remove MmsMessage.drmContent. We may implement Forward Lock, delivery restrictions in gecko. So detailed information are hidden from apps.

10. Remove MmsMessage.priority. The ETS may bypasses Priority Low/High tests for devices incapable of setting X-Mms-Priority field, so we can always set it to NORMAL.

11. Remove MmsMessage.messageClass. The ETS lists X-Mms-Message-Class support when the device under test is capable of setting message class. By hiding it from app and always setting it to "personal" in Gecko, the attribute can be removed.

12. Remove MmsMessage.adaptationAllowed. The ETS lists X-Mms-Adaptation-Allowed support when the device under test is capable of setting this field. By hiding it from app and don't set it in Gecko, the attribute can be removed.

13. Remove MmsMessage.expiry. The ETS item X-Mms-Expiry has a precondition that the device under test must support setting the expiry value.

14. Remove MmsMessage.deliveryTime. The ETS item X-Mms-Delivery-Time has a precondition that the device under test must support setting the delivery time value.

15. Add MmsAttachment interface to address attachment content-type and non-file-based messages.

readonly attribute long id;

/**
* "draft", "sending", "sent", "delivered", "received"
*/
readonly attribute DOMString delivery;

readonly attribute DOMString from;

/**
* All recipients: to, cc or bcc.
*/
readonly attribute DOMString[] recipients;
attribute DOMString[] to;
attribute DOMString[] cc;
attribute DOMString[] bcc;

/**
* Date and time of submission of the message.
*/
attribute Date date;

/**

* Presentation(main) part of the message. Null if unavailable.
*/
attribute Document contentDocument;

readonly attribute MmsAttachmentStorage attachments;

attribute DOMString subject;
}

interface MmsAttachmentStorage : nsISupports
{
getter MmsAttachment getAttachment(DOMString name);

setter creator void setAttachment(DOMString name,

MmsAttachment attachment);
deleter void deleteAttachment(DOMString name);
}

interface MmsAttachment : nsISupports
{
attribute DOMString name;
attribute DOMString contentType;

/**
* nsIDOMBlob or DOMString for simple text-based messages.
*/
attribute any content;

[Vicamo Yang]

On 06/25/2012 08:24 PM, Vicamo Yang wrote:
> Updates previous MMS API proposal. Mostly removals of optional message
> attributes.
>
> On 06/21/2012 01:58 AM, Vicamo Yang wrote:
>> Hi all,
>>
>> Here is an updated proposal with ETS discussion addressed. Changes are:
>>
>> 1. add interface definitions for MmsEvent, MmsDeliveryEvent;
>> 2. rename `sender` to `from`, `receiver` to `recipients` in MmsMessage;
>> 3. add deliveryTime. Also re-type `expiry` to "any";
>> 4. remove attributes `previouslySentBy`, `previouslySentDate`,
>> `distributionIndicator`, `senderVisibility`, `storeSent`,
>> `replyCharging`, `replyChargingDeadline`, `replyChargingSize`,
>> `replyChargingID`, `replaceID`, `contentClass`;
>> 5. add `forward` support in MmsManager.
>> 6. add `oncancelled` event in MmsManager.
> 7. Remove MmsMessage.deliveryReport. The ETS doesn't test outgoing messages with X-Mms-Delivery-Report set to false, so we can always request it to reduce interface complexity.
>
> 8. Remove MmsMessage.readReport. The ETS doesn't test outgoing messages with X-Mms-Read-Report set to false, so we can always request it to reduce interface complexity.
>
> 9. Remove MmsMessage.drmContent. We may implement Forward Lock, delivery restrictions in gecko. So detailed information are hidden from apps.
>
> 10. Remove MmsMessage.priority. The ETS may bypasses Priority Low/High tests for devices incapable of setting X-Mms-Priority field, so we can always set it to NORMAL.
>
> 11. Remove MmsMessage.messageClass. The ETS lists X-Mms-Message-Class support when the device under test is capable of setting message class. By hiding it from app and always setting it to "personal" in Gecko, the attribute can be removed.
>
> 12. Remove MmsMessage.adaptationAllowed. The ETS lists X-Mms-Adaptation-Allowed support when the device under test is capable of setting this field. By hiding it from app and don't set it in Gecko, the attribute can be removed.
>
> 13. Remove MmsMessage.expiry. The ETS item X-Mms-Expiry has a precondition that the device under test must support setting the expiry value.
>
> 14. Remove MmsMessage.deliveryTime. The ETS item X-Mms-Delivery-Time has a precondition that the device under test must support setting the delivery time value.
>
> 15. Add MmsAttachment interface to address attachment content-type and non-file-based messages.

Per discussion with Munir:

16. Remove MmsMessage.cc, MmsMessage.bcc. They're not implemented in both iPhone. For Android, there are some translated strings, maybe a few codes in processing outgoing messages with CC/BCC set, but there isn't a trivial way to insert CC/BCC recipients in UI. Since we have `to` now, remove MmsMessage.recipients as well.

17. Remove special alias contentDocument. Moved into attachments for unified semantics.

18. Redesign MmsManager.send() to have similar interface with SmsManager.send().

19. Set readonly to all MmsMessage attributes for we don't have to create MmsMessage instances in user app anymore due to change #18.

20. Remove "draft", "sending", "delivered" values of Message.delivery. Leave only "sent" and "received".

interface MmsEvent : nsIDOMEvent
{
readonly attribute nsIDOMMozMmsMessage message;
}

interface MmsDeliveryEvent : nsIDOMEvent
{
readonly attribute nsIDOMMozMmsMessage message;
readonly attribute DOMString originator;
}

interface MmsManager : nsIDOMEventTarget
{
/**
* Send a MMS message out and return an array of DOMRequest objects.

* `to` can be one single DOMString representing one recipient and
* an array of DOMStrings for multiple ones. `message` is a simple
* shortcut for additional text messages to be sent along with
* `attachments`.
*/
DOMRequest[] send(in any to,
in DOMString? message,
in MmsAttachments[] attachments,
[optional] in DOMString? subject);

* "sent", "received"

*/
readonly attribute DOMString delivery;

readonly attribute DOMString from;

readonly attribute DOMString[] to;

readonly attribute DOMString subject;

/**
* Date and time of submission of the message.
*/

readonly attribute Date date;

readonly attribute MmsAttachmentStorage attachments;