Provide read report related APIs for MMS

Could you provide more information about this Bugzilla case? Does it block v1.1.0 release?

A read report is generated by the recipient MMS client on the occurrence of the following events: *The message has been read by the recipient. *The message has been deleted without being read. In addition to the indication of the event, a read report also informs about the date when the message was read or deleted without being read. It doesn't block any user stories listed in Bug 842229. So I don't think it block v1.1.0.

I'm wondering do we really need a new API here, because we've already had a .markMessageRead(). But we still need the implementation to send the read report back to mmsc.

Change the summary to provide read report related fratures.

This one needs to be confirmed with PMs and clients. The earlier we know, the earlier we can start to work on this feature.

Does it block certification? conformance?

In OMA-TS-MMS_CONF-V1_3-20110511-C, it only require below FUNCTIONAL CONFORMANCE * MMS Creation Conformance * MMS Submission Conformance * MMS Retrieval Conformance * MMS Presentation Conformance. No read report related conformance.

After discussing with peter, we don't get any request from clients for this bug.

We need to support below features in Gecko part: 1. Can set the flag of request read report while sending or not. 2. When receiving a read report, notify Gaia SMS AP which receiver return the read report. 3. Notify Gaia SMS AP the read report request when get a MMS. 4. Gaia SMS AP can call an API to reply the read report request.

This is a meta bug. I will file 4 bugs for detail features. Remove the koi? nominate to provide more flexible of choose.

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #10) > This is a meta bug. I will file 4 bugs for detail features. Remove the koi? > nominate to provide more flexible of choose. Hi Chia-hung, have you already opened those bugs? If yes, please add the dependency. Btw, it seems we might need to start working on the read port stuff recently. I'll ask around to see if it should be included in V1.3.

Nominating this for V1.3. We should come up with some user stories first. Will highlight this issue in our next sync-up meeting.

Suggested by Ctai, the expected user stories will be: 1. As a sender, FFOS is capable of enabling/disabling to request MMS read report from the receiver. 2. As a sender, FFOS is capable of displaying the read status to specify if the receiver has read the MMS. 3. As a receiver, FFOS is capable of returning MMS read report when the sender is requesting that.

will be discussed in v1.3 triage sessions

blocking a committed 1.3 user story. 1.3+

(In reply to Joe Cheng [:jcheng] from comment #15) > blocking a committed 1.3 user story. 1.3+ This is a meta bug, which won't inherently block. The dependencies will block, however. Clearing nom as such.

Put this bug into backlog.

Change to fixed because all dependency of this meta bugs are fixed.