Re: Messaging API proposal

[Gene Lian]

Hi Eduardo,

Recently, we had a couple of changes about the MMS structure (thanks to Chia-Hung and Vicamo's hard work). We think they are worth reporting to you so that the Messaging APIs can keep in sync'ed time by time. I tried to summarise them as below:

1. Expose Expiry Date for MMS

Please see [1] for its original motivation. We need a way to inform our user when an MMS is going to be expired under the manual retrieval mode, so that the receiver can try to download the MMS before the expired date. The bug link for the interface change is at [2].

2. Add More Delivery Status for MMS

Please see [3] for the motivation and the interface change. We're hoping to provide 2 more types: "rejected" and "manual". The former is for the never-download retrieval mode (i.e. MMS is totally disabled) and the latter is for the manual retrieval mode. The original "pending" delivery status is kind of ambiguous and insufficient because the content side cannot know whether the first notification from MMSC is under the automatic retrieval mode or the manual retrieval mode. Under the automatic retrieval mode, the app developer has to *hide* that "pending" notification because the receiver doesn't need to be aware of that. Under the manual retrieval mode, the receiver can be aware of a "manual" notification and knows they should download the real MMS content later.

3. Thread (Conversation) Needs to Know the Last Message is SMS or MMS

Please see [4] for the motivation and [5] for the interface change. In this way, the thread can know whether to display some special icons for the presence of MMS attachments.

4. Message Time Stamp

We decide to use the device sent/received time for both SMS/MMS messages [6]. If my recall is right, the W3C Messaging API concludes the message sent/received time should reflect the server time. Vicamo and I agree that using the server time is much better than the device time, and it's actually feasible because we can get the server sent/received time in the SMS/MMS headers of transactions. Anyway, our main point is: no matter which to choose, all the time stamps should be based on the same standard so that the messages can be sorted in the correct order.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=862262
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=867227
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=867440
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=862311
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=863241
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=840051

Hope these info are helpful for you. Keep in contact. Thanks!

Gene

[Marcos Caceres]

Hi Gene,
tl;dr: bugs filed on W3C spec. Links below. Thanks for the feedback! :)

On Thursday, May 9, 2013 at 1:36 PM, Gene Lian wrote:

> Hi Eduardo,
>
> Recently, we had a couple of changes about the MMS structure (thanks to Chia-Hung and Vicamo's hard work). We think they are worth reporting to you so that the Messaging APIs can keep in sync'ed time by time. I tried to summarise them as below:
>
> 1. Expose Expiry Date for MMS
>
> Please see [1] for its original motivation. We need a way to inform our user when an MMS is going to be expired under the manual retrieval mode, so that the receiver can try to download the MMS before the expired date. The bug link for the interface change is at [2].

Filed bug on spec:
https://github.com/sysapps/messaging/issues/55

>
> 2. Add More Delivery Status for MMS
>
> Please see [3] for the motivation and the interface change. We're hoping to provide 2 more types: "rejected" and "manual". The former is for the never-download retrieval mode (i.e. MMS is totally disabled) and the latter is for the manual retrieval mode. The original "pending" delivery status is kind of ambiguous and insufficient because the content side cannot know whether the first notification from MMSC is under the automatic retrieval mode or the manual retrieval mode. Under the automatic retrieval mode, the app developer has to *hide* that "pending" notification because the receiver doesn't need to be aware of that. Under the manual retrieval mode, the receiver can be aware of a "manual" notification and knows they should download the real MMS content later.

Filed bug on spec:
https://github.com/sysapps/messaging/issues/56

> 3. Thread (Conversation) Needs to Know the Last Message is SMS or MMS
>
> Please see [4] for the motivation and [5] for the interface change. In this way, the thread can know whether to display some special icons for the presence of MMS attachments.

Filed bug on spec:

https://github.com/sysapps/messaging/issues/57

>
> 4. Message Time Stamp
>
> We decide to use the device sent/received time for both SMS/MMS messages [6]. If my recall is right, the W3C Messaging API concludes the message sent/received time should reflect the server time. Vicamo and I agree that using the server time is much better than the device time, and it's actually feasible because we can get the server sent/received time in the SMS/MMS headers of transactions. Anyway, our main point is: no matter which to choose, all the time stamps should be based on the same standard so that the messages can be sorted in the correct order.

Filed bug on spec:

https://github.com/sysapps/messaging/issues/58

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=862262
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=867227
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=867440
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=862311
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=863241
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=840051
>
> Hope these info are helpful for you. Keep in contact. Thanks!
>
> Gene

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org (mailto:dev-w...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-webapi

--
Marcos Caceres

[EDUARDO FULLEA CARRERA]

Hi Gene,

On 9 may 2013 at 14:36:17, Gene Lian wrote:
> Hi Eduardo,
>
> Recently, we had a couple of changes about the MMS structure (thanks to
> Chia-Hung and Vicamo's hard work). We think they are worth reporting to
> you so that the Messaging APIs can keep in sync'ed time by time. I tried to
> summarise them as below:
>
> 1. Expose Expiry Date for MMS
>
> Please see [1] for its original motivation. We need a way to inform our user
> when an MMS is going to be expired under the manual retrieval mode, so
> that the receiver can try to download the MMS before the expired date. The
> bug link for the interface change is at [2].
>

Makes sense to me. Will work to add it to W3C's Messaging API.

> 2. Add More Delivery Status for MMS
>
> Please see [3] for the motivation and the interface change. We're hoping to
> provide 2 more types: "rejected" and "manual". The former is for the never-
> download retrieval mode (i.e. MMS is totally disabled) and the latter is for
> the manual retrieval mode. The original "pending" delivery status is kind of
> ambiguous and insufficient because the content side cannot know whether
> the first notification from MMSC is under the automatic retrieval mode or the
> manual retrieval mode. Under the automatic retrieval mode, the app
> developer has to *hide* that "pending" notification because the receiver
> doesn't need to be aware of that. Under the manual retrieval mode, the
> receiver can be aware of a "manual" notification and knows they should
> download the real MMS content later.
>

This change perverts the use of Delivery Status (at least the use we make of it in W3C Messaging API) to track status of outbound messages. You propose to use it to show or not show an incoming MMS notification, based on the retrieval mode.
It would be more correct to split the 'not-downloaded' state in two, for instance 'not-downloaded' and 'pending-automatic-download'. In any case if the app can get the retrieval mode (via getFetchMode or similar) it may be enough with current state 'not-downloaded'.

> 3. Thread (Conversation) Needs to Know the Last Message is SMS or MMS
>
> Please see [4] for the motivation and [5] for the interface change. In this
> way, the thread can know whether to display some special icons for the
> presence of MMS attachments.
>

In W3C's Messaging API this info can already be obtained by checking the 'type' of the message with ID equal to the 'lastMessageID' of the Conversation. Any problem with this approach?

> 4. Message Time Stamp
>
> We decide to use the device sent/received time for both SMS/MMS
> messages [6]. If my recall is right, the W3C Messaging API concludes the
> message sent/received time should reflect the server time. Vicamo and I
> agree that using the server time is much better than the device time, and it's
> actually feasible because we can get the server sent/received time in the
> SMS/MMS headers of transactions. Anyway, our main point is: no matter
> which to choose, all the time stamps should be based on the same standard
> so that the messages can be sorted in the correct order.
>

For incoming messages, we should use the time in the message headers since the device time (of the receiving device) is the time when the user receives the message, and it is the sending time that should be shown. Note that using the server time does not mean that this cannot be shown according to the time zone of the user if different from the server.

For outgoing messages device time (of the sending device) and server time should roughly be the same. Since in MMS we don't get the server time when the message submission is ack'ed by the server, then we just can use the sending time by the device.

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=862262
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=867227
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=867440
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=862311
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=863241
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=840051
>
> Hope these info are helpful for you. Keep in contact. Thanks!
>
> Gene

________________________________

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

[Vicamo Yang]

Hi all,

I've created an issue about the MMS text charset parameter of the
attachments in https://github.com/sysapps/messaging/issues/61 .

Recently Mozilla has issues (bug 883017, bug 880648) regarding text
encodings of MMS attachments. By W3C File API, a Blob has only mime type
and no further information like text encoding available. The API client
may not decode that blob correctly without these detailed parameters,
and the API implementation may not encode that MMS PDU with all
necessary parameters for message inter-change as well.

To solve text encoding problem with minimum work, we may allow
MmsAttachment::content to be either a text or a blob:

1. when API client sets MmsAttachment::content to a text, the underlying
implementation may choose an appropriate charset for text encoding and
carry that chosen charset in the encoded PDU,
2. when API implementation receives a PDU and finds some attachments are
of text mime types, the implementation decodes these attachments to a
string rather than a blob.

How do you think?

Vicamo

[Vicamo Yang]

[Vicamo Yang]

[Gene Lian]

Hi,

Just helping clarify what Vicamo is going to do. The current MMS attachment is defined as below:

dictionary MmsAttachment
{
DOMString? id;
DOMString? location;
nsIDOMBlob content; // If the content blob is a "text/*" type, the encoding
// for text should always be "utf-8".
};

We're hoping to change it to:

dictionary MmsAttachment
{
DOMString? id;
DOMString? location;
jsval content; // Can be nsIDOMBlob or DOMString.
};

-----
I have one concern on this. What's happening if the clients still want to assign the |content| with a "text/*" MIME type blob? The API implementation would still face the same issue of not knowing the encoding of the text blob. Right? I don't think this issue can be perfectly solved by this new design. I'd suggest another design as below:

dictionary MmsAttachment
{
DOMString? id;
DOMString? location;
DOMString? encoding;
nsIDOMBlob content;
};

This design exposes an |encoding| parameter to let the client have a more flexible way to specify the encoding of the content blob no matter it's a "text/*" MIME type or not.

What do you think?

Gene

[Gene Lian]

[EDUARDO FULLEA CARRERA]

Hi,

Why cannot we specify the encoding as part of Blob's content-type attribute? See how the definition of this attribute in [1] points to [2] and this RFC provides the following example: Content-Type: text/html; charset=ISO-8859-4
[1] http://www.w3.org/TR/FileAPI/#dfn-contentTypeBlob
[2] http://tools.ietf.org/html/rfc2616#page-124

[EDUARDO FULLEA CARRERA]

[Vicamo Yang]

Oops! Just don't know that's allowed.
Thank you. ;)

On 06/19/2013 06:20 PM, EDUARDO FULLEA CARRERA wrote:
> Hi,

>
> Why cannot we specify the encoding as part of Blob's content-type attribute? See how the definition of this attribute in [1] points to [2] and this RFC provides the following example: Content-Type: text/html; charset=ISO-8859-4
> [1] http://www.w3.org/TR/FileAPI/#dfn-contentTypeBlob
> [2] http://tools.ietf.org/html/rfc2616#page-124

--
Vicamo Yang 楊有勝
Mozilla Taiwan

[Vicamo Yang]

[Gene Lian]

Hi Eduardo,

Great! Thanks!

Yeap, I understand. The current W3C only makes delivery status for outbound MMS; whereas we reuse it also for incoming MMS. Anyway, I think you're right. We can dynamically check the retrieval mode to distinguish the notification between:

- the state of "not-downloaded and waiting for manual download"
- the state of "not-downloaded but is auto-downloading"

The current W3C spec should be working well.

>
> > 3. Thread (Conversation) Needs to Know the Last Message is SMS or
> > MMS
> >
> > Please see [4] for the motivation and [5] for the interface
> > change. In this
> > way, the thread can know whether to display some special icons for
> > the
> > presence of MMS attachments.
> >
>
> In W3C's Messaging API this info can already be obtained by checking
> the 'type' of the message with ID equal to the 'lastMessageID' of
> the Conversation. Any problem with this approach?

Sounds good to me! Btw, we don't have such an ID because we don't want to do extra queries at run-time, which might affect the perfomance of showing the thread list.

>
> > 4. Message Time Stamp
> >
> > We decide to use the device sent/received time for both SMS/MMS
> > messages [6]. If my recall is right, the W3C Messaging API
> > concludes the
> > message sent/received time should reflect the server time. Vicamo
> > and I
> > agree that using the server time is much better than the device
> > time, and it's
> > actually feasible because we can get the server sent/received time
> > in the
> > SMS/MMS headers of transactions. Anyway, our main point is: no
> > matter
> > which to choose, all the time stamps should be based on the same
> > standard
> > so that the messages can be sorted in the correct order.
> >
>
> For incoming messages, we should use the time in the message headers
> since the device time (of the receiving device) is the time when the
> user receives the message, and it is the sending time that should be
> shown. Note that using the server time does not mean that this
> cannot be shown according to the time zone of the user if different
> from the server.

This is correct. For the received SMS/MMS, we must be able to have its server time in the headers.

>
> For outgoing messages device time (of the sending device) and server
> time should roughly be the same. Since in MMS we don't get the
> server time when the message submission is ack'ed by the server,
> then we just can use the sending time by the device.

Sounds good! At least for MMS, we don't heve the server time info in the M-Send.conf acknowledgement after sending the M-Send.req request. To make sure all the SMS/MMS messages can be sorted in the correct order, we can uniformly define the sending time as the device time.


In addition to the above-mentioned issues, I'll summarize all the recent changes and send them to you when I'm more available on the next Monday. Thanks!

Gene

[EDUARDO FULLEA CARRERA]

Hi Gene,

Pull Request available. Please comment if needed.
https://github.com/sysapps/messaging/pull/62

Your comment added in Github and issue closed

>>
>>> 3. Thread (Conversation) Needs to Know the Last Message is SMS or
>>> MMS
>>>
>>> Please see [4] for the motivation and [5] for the interface
>>> change. In this
>>> way, the thread can know whether to display some special icons for
>>> the
>>> presence of MMS attachments.
>>>
>>
>> In W3C's Messaging API this info can already be obtained by checking
>> the 'type' of the message with ID equal to the 'lastMessageID' of
>> the Conversation. Any problem with this approach?
>
> Sounds good to me! Btw, we don't have such an ID because we don't want to do
> extra queries at run-time, which might affect the perfomance of showing the
> thread list.
>

Your comment added in Github. The issue is left open so that it can be discussed whether we need to redesign to address the performance issue you mention.

Pull Request available. Please comment if needed.
https://github.com/sysapps/messaging/pull/65

>
> In addition to the above-mentioned issues, I'll summarize all the recent changes
> and send them to you when I'm more available on the next Monday. Thanks!
>
> Gene

Thanks,
Eduardo.

[Jonas Sicking]

On Jun 19, 2013 9:42 AM, "Vicamo Yang" <vic...@gmail.com> wrote:
>
> Hi all,
>
> I've created an issue about the MMS text charset parameter of the
> attachments in https://github.com/sysapps/messaging/issues/61 .
>
> Recently Mozilla has issues (bug 883017, bug 880648) regarding text
> encodings of MMS attachments. By W3C File API, a Blob has only mime type
> and no further information like text encoding available. The API client
> may not decode that blob correctly without these detailed parameters,
> and the API implementation may not encode that MMS PDU with all
> necessary parameters for message inter-change as well.
>
> To solve text encoding problem with minimum work, we may allow
> MmsAttachment::content to be either a text or a blob:
>
> 1. when API client sets MmsAttachment::content to a text, the underlying
> implementation may choose an appropriate charset for text encoding and
> carry that chosen charset in the encoded PDU,
> 2. when API implementation receives a PDU and finds some attachments are
> of text mime types, the implementation decodes these attachments to a
> string rather than a blob.
>
> How do you think?

How are charsets handled in other platforms today? What is the charset of
the attachments that the network sends to the terminal? And does the
network expect attachments to have a particular charset when the terminal
sends it to the network?

Or does the network not care and simply pass the data through? If so, what
charsets do other platforms support for receiving and use for sending?

Does the MMS specs say anything about what charsets to use?

/ Jonas

[Jonas Sicking]

[Jonas Sicking]

On Jun 14, 2013 1:36 PM, "EDUARDO FULLEA CARRERA" <e...@tid.es> wrote:
>
> Hi Gene,
>
> On 9 may 2013 at 14:36:17, Gene Lian wrote:
> > Hi Eduardo,
> >
> > Recently, we had a couple of changes about the MMS structure (thanks to
> > Chia-Hung and Vicamo's hard work). We think they are worth reporting to
> > you so that the Messaging APIs can keep in sync'ed time by time. I
tried to
> > summarise them as below:
> >
> > 1. Expose Expiry Date for MMS
> >
> > Please see [1] for its original motivation. We need a way to inform
our user
> > when an MMS is going to be expired under the manual retrieval mode, so
> > that the receiver can try to download the MMS before the expired date.
The
> > bug link for the interface change is at [2].
> >
>
> Makes sense to me. Will work to add it to W3C's Messaging API.
>

Would it make sense to add a 'downloading' state which we transition into
directly if the device is set to automatic downloads. For manual downloads
we transition into the state when the download function is called for the
message.

/ Jonas

> > 3. Thread (Conversation) Needs to Know the Last Message is SMS or MMS
> >
> > Please see [4] for the motivation and [5] for the interface change.
In this
> > way, the thread can know whether to display some special icons for the
> > presence of MMS attachments.
> >
>
> In W3C's Messaging API this info can already be obtained by checking the
'type' of the message with ID equal to the 'lastMessageID' of the
Conversation. Any problem with this approach?
>

> > 4. Message Time Stamp
> >
> > We decide to use the device sent/received time for both SMS/MMS
> > messages [6]. If my recall is right, the W3C Messaging API concludes the
> > message sent/received time should reflect the server time. Vicamo and I
> > agree that using the server time is much better than the device time,
and it's
> > actually feasible because we can get the server sent/received time in
the
> > SMS/MMS headers of transactions. Anyway, our main point is: no matter
> > which to choose, all the time stamps should be based on the same
standard
> > so that the messages can be sorted in the correct order.
> >
>
> For incoming messages, we should use the time in the message headers
since the device time (of the receiving device) is the time when the user
receives the message, and it is the sending time that should be shown. Note
that using the server time does not mean that this cannot be shown
according to the time zone of the user if different from the server.
>

> For outgoing messages device time (of the sending device) and server time
should roughly be the same. Since in MMS we don't get the server time when
the message submission is ack'ed by the server, then we just can use the
sending time by the device.
>

> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=862262
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=867227
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=867440
> > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=862311
> > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=863241
> > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=840051
> >
> > Hope these info are helpful for you. Keep in contact. Thanks!
> >
> > Gene
>

[EDUARDO FULLEA CARRERA]

Hi Jonas,

It makes sense. That was exactly was I was proposing but with a different state name ('pending-automatic-download') to reflect the fact that the message may be effectively downloading whilst in this state, but it may be also waiting for a retry if something has failed in the first download attempt. It seems though that 'pending-automatic-download' may be too long and not straightforward to understand, so maybe 'downloading' is better.

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-webapi

[EDUARDO FULLEA CARRERA]

Hi Jonas, all,

>How are charsets handled in other platforms today? What is the charset of the attachments that the network sends to the terminal? And
>does the network expect attachments to have a particular charset when the terminal sends it to the network?
>Or does the network not care and simply pass the data through? If so, what charsets do other platforms support for receiving and use for
>sending?
>Does the MMS specs say anything about what charsets to use?

About the last question, the MMS spec (OMA MMS 1.3) mandates the use of either US-ASCII or UTF-8 for multimedia objects' encoding
at submission and requires its support at reception. UTF-16 may also be used for text/plain but not recommended. See following excerpts
from MMS Conformance Document:

" In creation, the character set SHALL be either us-ascii (IANA MIBenum 3) or utf-8 (IANA MIBenum 106)
[Unicode]. In retrieval, both us-ascii and utf-8 SHALL be supported. The us-ascii character set SHALL be unencoded. In
encoding utf-8, either Q-encoding [RFC2047, 4.1] or B-encoding [RFC2047, 4.2] SHALL be used. In decoding utf-8, both
Q-encoding and B-encoding SHALL be supported."

" The text parts (text/plain) of submitted MM SHALL support at least one of the following character encodings:
• us-ascii (IANA MIBEnum 3)
• utf-8 (IANA MIBenum 106) [Unicode]
Character encoding utf-16 SHOULD NOT be used in “text/plain” media parts for submitted MM.
Note: Use of utf-16 within a “text/plain” media part may entail interoperability problems when the MM may be transported
over the MMSE (MM3 in 3GPP terminology), MMSR (MM4 in 3GPP terminology) interfaces, or other transport protocols as
detailed in [RFC2781].
MMS Clients SHALL support received MM with text parts (text/plain) encoded in us-ascii and utf-8.
MMS Clients that are compliant to the MMS suite of specifications defined by 3GPP (e.g., [TS23140]) SHALL support
received MM with text parts (text/plain) encoded in utf-16 (IANA MIBenum 1015) with explicit Byte Order Mark (BOM)
[Unicode]."

[EDUARDO FULLEA CARRERA]

[Gene Lian]

Hi Eduardo,

The following summarises all the interface changes from the last update. Please take a look to decide if it's worth adding in the W3C proposal.

-----
1. Support |onretrieving| Event for MMS

Please see [1]. This event is going to be fired when the back-end starts the retrieving process, which is symmetric to the |onsending| event. However, the W3C doesn't consider the |onsending| event either, so maybe you don't want to add another |onretrieving| event, though.

-----
2. Enforce Content Blob to be UTF-8 Encoding for MMS

Please see [2]. We used to discuss this topic before. Just for the records. Since it's a formal way in W3C to specify the |charset| property in the MIME type of Blob object, so the current W3C spec works for me.

-----
3. Support Retrieval Modes "automatic-home"/"never" for MMS

Please see [3] and [4]. The "never" mode is trivial; sometimes we want to completely disable our MMS retrieving. The "automatic-home" mode is used for allowing users to automatically download MMS only when they are in the home network. The ordinary "automatic" mode will download the MMS all the time even if it's roaming, which would cost lots of money.

-----
4. Add MMS Subject in Thread Object

Please see [5]. It seems the W3C has already exposed this attribute at [6]. However, one thing I need to mention is why does the W3C spec only expose MMS' |subject| but not SMS' |body|? Btw, if you're hoping to use |Conversation.lastMessageID| to fetch all the detailed SMS/MMS content, why do you expose the |subject| only, but not for other attributes?

-----
5. Expose Delivered Time for SMS/MMS

Please see [7]. We have a plan to expose the delivered time (maybe, name it as |deliveredTimestamp|) for both SMS/MMS. The original |timestamp| specifies the sending/receiving time points but the new |deliveredTimestamp| is going to specify the time point(s) when getting the delivery report(s). You can imagine this attribute is going to be a Date object for SMS or an array of Date objects for MMS.

-----
6. Add More Error Codes When Failing to Send SMS/MMS

Please see [8] and [9]. The current W3C doesn't define what the error codes are going to be returned by the Future object. In Mozilla (we still use DOM Request for now), we define the following error codes at [10] which is also listed as below:

const unsigned short SUCCESS_NO_ERROR = 0;
const unsigned short NO_SIGNAL_ERROR = 1;
const unsigned short NOT_FOUND_ERROR = 2;
const unsigned short UNKNOWN_ERROR = 3;
const unsigned short INTERNAL_ERROR = 4;
const unsigned short NO_SIM_CARD_ERROR = 5;
const unsigned short RADIO_DISABLED_ERROR = 6;

-----
References:

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=810099
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=880648
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=810067
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=855605
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=885679
[6] http://messaging.sysapps.org/#conversation-interface
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=887159
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=885652
[9] https://bugzilla.mozilla.org/show_bug.cgi?id=880561
[10] http://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/interfaces/nsIMobileMessageCallback.idl#24

-----
Please let me know if you have any questions or suggestions.

Thanks,
Gene

[EDUARDO FULLEA CARRERA]

Hi Gene,

Thanks for the great summary of updates. See response inline.

Regards,
Eduardo.

On 1 jul 2013 at 13:45:09, Gene Lian wrote:
> Hi Eduardo,
>
> The following summarises all the interface changes from the last update.
> Please take a look to decide if it's worth adding in the W3C proposal.
>
> -----
> 1. Support |onretrieving| Event for MMS
>
> Please see [1]. This event is going to be fired when the back-end starts the
> retrieving process, which is symmetric to the |onsending| event. However, the
> W3C doesn't consider the |onsending| event either, so maybe you don't want
> to add another |onretrieving| event, though.
>

It is not clear to me why we need this event. In case of manual download the application knows when the retrieval starts, as it is invoked by the retrieveMMS method (fetch method in W3C spec). In case of automatic download I don't see the value in notifying the app about the message until the message has been fetched from the server. I see that similar concerns were raised by Mounir in [1] and convincing arguments were not provided in the discussion.

Wrt onsending, the app knows when the sending starts as it is invoked by the send method, so again I don't see a need to add this event.

I have though filed a issue to add a 'fetching' state for MmsMessage in W3C spec: https://github.com/sysapps/messaging/issues/67

> -----
> 2. Enforce Content Blob to be UTF-8 Encoding for MMS
>
> Please see [2]. We used to discuss this topic before. Just for the records. Since
> it's a formal way in W3C to specify the |charset| property in the MIME type of
> Blob object, so the current W3C spec works for me.
>

I have filed a new issue to make it more clear in W3C spec: https://github.com/sysapps/messaging/issues/68

> -----
> 3. Support Retrieval Modes "automatic-home"/"never" for MMS
>
> Please see [3] and [4]. The "never" mode is trivial; sometimes we want to
> completely disable our MMS retrieving. The "automatic-home" mode is used
> for allowing users to automatically download MMS only when they are in the
> home network. The ordinary "automatic" mode will download the MMS all the
> time even if it's roaming, which would cost lots of money.
>

Make sense. New issue added: https://github.com/sysapps/messaging/issues/69

> -----
> 4. Add MMS Subject in Thread Object
>
> Please see [5]. It seems the W3C has already exposed this attribute at [6].
> However, one thing I need to mention is why does the W3C spec only expose
> MMS' |subject| but not SMS' |body|? Btw, if you're hoping to use
> |Conversation.lastMessageID| to fetch all the detailed SMS/MMS content, why
> do you expose the |subject| only, but not for other attributes?
>

Not that the 'Conversation' interface is not cast in stone in W3C but still under discussion. Two different types of conversations were considered:
-messages with the same set of participants
-messages with the same subject
As the subject is the key to define this latest type of conversation it was added to the interface. Note that the subject attribute will not be provided if more there is more than one subject in a conversation defined by the set of participants.

> -----
> 5. Expose Delivered Time for SMS/MMS
>
> Please see [7]. We have a plan to expose the delivered time (maybe, name it
> as |deliveredTimestamp|) for both SMS/MMS. The original |timestamp|
> specifies the sending/receiving time points but the new |deliveredTimestamp|
> is going to specify the time point(s) when getting the delivery report(s). You can
> imagine this attribute is going to be a Date object for SMS or an array of Date
> objects for MMS.
>

Make sense. New issue filed: https://github.com/sysapps/messaging/issues/70

> -----
> 6. Add More Error Codes When Failing to Send SMS/MMS
>
> Please see [8] and [9]. The current W3C doesn't define what the error codes
> are going to be returned by the Future object. In Mozilla (we still use DOM
> Request for now), we define the following error codes at [10] which is also
> listed as below:
>
> const unsigned short SUCCESS_NO_ERROR = 0;
> const unsigned short NO_SIGNAL_ERROR = 1;
> const unsigned short NOT_FOUND_ERROR = 2;
> const unsigned short UNKNOWN_ERROR = 3;
> const unsigned short INTERNAL_ERROR = 4;
> const unsigned short NO_SIM_CARD_ERROR = 5;
> const unsigned short RADIO_DISABLED_ERROR = 6;

New issue filed: https://github.com/sysapps/messaging/issues/71

> -----
> References:
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=810099 [2]
> https://bugzilla.mozilla.org/show_bug.cgi?id=880648 [3]
> https://bugzilla.mozilla.org/show_bug.cgi?id=810067 [4]
> https://bugzilla.mozilla.org/show_bug.cgi?id=855605 [5]
> https://bugzilla.mozilla.org/show_bug.cgi?id=885679 [6]
> http://messaging.sysapps.org/#conversation-interface [7]
> https://bugzilla.mozilla.org/show_bug.cgi?id=887159 [8]
> https://bugzilla.mozilla.org/show_bug.cgi?id=885652 [9]
> https://bugzilla.mozilla.org/show_bug.cgi?id=880561 [10]
> http://mxr.mozilla.org/mozilla-
> central/source/dom/mobilemessage/interfaces/nsIMobileMessageCallback.idl
> #24
>
> -----
> Please let me know if you have any questions or suggestions.
>
> Thanks,
> Gene

[JOSE MANUEL CANTERA FONSECA]

El 01/07/13 13:45, "Gene Lian" <cl...@mozilla.com> escribió:

>Hi Eduardo,
>
>The following summarises all the interface changes from the last update.
>Please take a look to decide if it's worth adding in the W3C proposal.
>
>-----
>1. Support |onretrieving| Event for MMS
>
> Please see [1]. This event is going to be fired when the back-end
>starts the retrieving process, which is symmetric to the |onsending|
>event. However, the W3C doesn't consider the |onsending| event either, so
>maybe you don't want to add another |onretrieving| event, though.

I'm wondering if we could just reuse ProgressEvents for this purpose

>
>-----
>2. Enforce Content Blob to be UTF-8 Encoding for MMS
>
> Please see [2]. We used to discuss this topic before. Just for the
>records. Since it's a formal way in W3C to specify the |charset| property
>in the MIME type of Blob object, so the current W3C spec works for me.
>

>-----
>3. Support Retrieval Modes "automatic-home"/"never" for MMS
>
> Please see [3] and [4]. The "never" mode is trivial; sometimes we want
>to completely disable our MMS retrieving. The "automatic-home" mode is
>used for allowing users to automatically download MMS only when they are
>in the home network. The ordinary "automatic" mode will download the MMS
>all the time even if it's roaming, which would cost lots of money.
>

>-----
>4. Add MMS Subject in Thread Object
>
> Please see [5]. It seems the W3C has already exposed this attribute at
>[6]. However, one thing I need to mention is why does the W3C spec only
>expose MMS' |subject| but not SMS' |body|? Btw, if you're hoping to use
>|Conversation.lastMessageID| to fetch all the detailed SMS/MMS content,
>why do you expose the |subject| only, but not for other attributes?
>

>-----
>5. Expose Delivered Time for SMS/MMS
>
> Please see [7]. We have a plan to expose the delivered time (maybe,
>name it as |deliveredTimestamp|) for both SMS/MMS. The original
>|timestamp| specifies the sending/receiving time points but the new
>|deliveredTimestamp| is going to specify the time point(s) when getting
>the delivery report(s). You can imagine this attribute is going to be a
>Date object for SMS or an array of Date objects for MMS.

I believe the semantics of this new field should be the timestamp when the
message actually arrived at destination and not when the delivery report
was received at origin

>
>-----
>6. Add More Error Codes When Failing to Send SMS/MMS
>
> Please see [8] and [9]. The current W3C doesn't define what the error
>codes are going to be returned by the Future object. In Mozilla (we still
>use DOM Request for now), we define the following error codes at [10]
>which is also listed as below:
>
> const unsigned short SUCCESS_NO_ERROR = 0;
> const unsigned short NO_SIGNAL_ERROR = 1;
> const unsigned short NOT_FOUND_ERROR = 2;
> const unsigned short UNKNOWN_ERROR = 3;
> const unsigned short INTERNAL_ERROR = 4;

Unknown error and internal error seem to be the same

> const unsigned short NO_SIM_CARD_ERROR = 5;

I think here we would need to be more generic, maybe we can use something
like SUBSCRIPTION_ERROR

> const unsigned short RADIO_DISABLED_ERROR = 6;

This error seems to be similar to nosignal error. I believe we should not
try to generate too many error states as later will be harder to check for
compliance and interoperability, provided that there could be
implementations not able to report errors with such a precision.