840068 - [MMS][User Story] Unknown headers/values not presented to user

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::SMS, defect, P1)

Description

[Peter Dolanjski [:pdol]]

UCID: Messages-043

User Story:
As a user, I will not be presented with content header errors in the rendering of MMS message content. All unknown headers and values will not be presented to the user to simplify the presentation of the message and mitigate user confusion.

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

Vicamo, does gecko filter out the unknown header/values? thanks

Comment 2

[Vicamo Yang [:vicamo][:vyang]]

Content only gets attributes specified in DOM API. Most successfully parsed header fields are hidden from content and malformed headers are skipped. If I understand Peter's description correctly, there is nothing to do.

Comment 3

[Peter Dolanjski [:pdol]]

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #2)
> Content only gets attributes specified in DOM API. Most successfully parsed
> header fields are hidden from content and malformed headers are skipped. If
> I understand Peter's description correctly, there is nothing to do.

If that is the case, then there is nothing to do other than test.

Comment 4

[Borja Salguero [:borjasalguero]]

Please specify clearly the goal of this bug, and if there is nothing to do we should close it.

Comment 5

[Kev Needham [:kev]]

The goal of this bug is to ensure that the messaging client will not display unknown headers to the user from an MMS message that has been received by that device and contains unknown headers/header information

Comment 6

[Dietrich Ayala (:dietrich)]

Per partner and release-driver discussions, marking blocking- until all MMS functionality in bug 849867 is complete, allowing it all to be uplifted at once to avoid SMS bustage.

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

mark this as resolved and waiting for verification

Comment 8

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Peter Dolanjski [:pdol] from comment #3)
> (In reply to Vicamo Yang [:vicamo][:vyang] from comment #2)
> > Content only gets attributes specified in DOM API. Most successfully parsed
> > header fields are hidden from content and malformed headers are skipped. If
> > I understand Peter's description correctly, there is nothing to do.
> 
> If that is the case, then there is nothing to do other than test.

Throughout MMS-CONF[1], we have two items seem to match the bug description here. One is "MMSCONF-GEN-C-004":

  "Continue functioning after unsupported or corrupted content is received."

listed in MMS-CONF Appendix C.1.1. Another is "MMSCONF-MED-C-028":

  "Ignore unknown SMIL elements/attributes."

listed in MMS-CONF Appendix C.1.12. Both have no test case defined in MMS-ETS-CONF[2] and MMS-ETC-INT[3].

Like my comment 2, Gecko almost implements decoding/encoding for every well known header field. For those fall outside the circle, if encoded correctly, we're also capable of handling them. By "handling", I mean decode and encode. Most fields, unless required by DOM interface, are never revealed to the user, and surely those required are well known fields so far. Gaia parses SMIL, and I think they follow the same rule that Gecko does.

So, actually I'm not quite sure how could that verification process go, and it probably need some testing equipment to perform such test because all the devices at hand generate only messages with well known header fields (for conformance, of course).

[1]: OMA-TS-MMS-CONF-V1_3-20110913-A
[2]: OMA-ETS-MMS_CON-V1_3-20101015-C
[3]: OMA-ETS-MMS_INT-V1_3-20101015-C