890180 - B2G MMS: Fix the wrong coder in WSP Well-Known Parameter Assignments.

Status: RESOLVED WONTFIX

(Core :: DOM: Device Interfaces, defect, P1)

Description

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

We set the wrong code in WSP Well-Known Parameter Assignments including name, type and start.

Comment 1

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Patch v1.0

Comment 2

[Leo]

Discussed with CTai and marking them as Leo+.
- Veeresh

Comment 3

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

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #0)
> We set the wrong code in WSP Well-Known Parameter Assignments including
> name, type and start.

According to OMA-TS-MMS_ENC-V1_3-20110913-A clause 7.1 "Special Considerations Regarding Usage of WSP in MMS":

  Table 38 in [WAPWSP] contains bugs at Expected BNF Rules for Value. “Text-value”
  MUST be used for parameter values instead of “Text-string”.

So we won't fix "name" and "start" here.  About "type", I still have to digg out the reason we have TypeValue instead.  Just can't remember that much.  But since we have some confusions here, add some more comments right above the two will be nice.

Comment 4

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

ConstrainedEncoding returns either a numeric value or a string.  However, in the case of decoding parameters, we want string-based type only.  So basically TypeValue is just a helper for ConstrainedEncoding to transform numeric well known types into a string one as it suggests in the comments right above the code.

As a result, no any a line of code will be changed in this bug, but comments are still welcome.

Comment 5

[Leo]

In WSP 230 document, Table 38. Well-Known Parameter Assignments provides the list of parameters. In this Start parameter is listed twice. In the first one its with assigned number 0X0A, which is deprecated and second one with assigned number 0x19. As per Vicamo comment if we are not changing the start parameter then we should not be using 0X8A, which is deprecated.

Comment 6

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

According to OMA-TS-MMS_ENC-V1_3-20110913-A clause 7.1 "Special Considerations Regarding Usage of WSP in MMS":
Header fields included in a MM SHALL be encoded according to WSP Binary Encoding version 1.3 [WAPWSP] whenever possible.

0x19 for start is WSP 1.4. So we should not use 0x19.

Comment 7

[Leo]

in WSP document, (1): These numbers have been deprecated and should not be used. mentioned just below Table 38. Which means 0x8A should not be used.

Comment 8

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

(In reply to Leo from comment #7)
> in WSP document, (1): These numbers have been deprecated and should not be
> used. mentioned just below Table 38. Which means 0x8A should not be used.

That's why we have a comment after it:

  // Deprecated, but used in some carriers, eg. T-Mobile.

Comment 9

[Leo]

I believe here we have a very tricky situation. 
1. 0x8A with text-string is deprecated.
2. 0x99 with text-value is not supported by some of the operators.

currently ffos use 0x8A with text-value because MMS 1.3 conf requires to use text-value instead of text-string. However 0x8A is deprecated.

There can be one way-out, we can skip sending start parameter from ffos device if we make sure SMIL is the first part in MMS message, which is being sent. This is as per MMS specification. 

Comments welcome!

Comment 10

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

In OMA-TS-MMS-CONF-V1_3-20110913-A clause 10.2.3 "Start Parameter Referring to Presentation":

  The presentation part in an application/vnd.wap.multipart.related structure SHALL
  be identified by a Content-ID header in the multipart structure. ([WAPWSP] 8.5.3).

So basically MMS-CONF suggests we SHALL have "start" parameter in an application/vnd.wap.multipart.related structure, and that presentation part SHALL have a Content-ID header.

Comment 12

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

What iOS did is send a smil id without <>. Like below:
"content-type":{"media":"application/vnd.wap.multipart.related","params":{"type":"application/smil","start":"0.smil"}}

Comment 13

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

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #12)
> What iOS did is send a smil id without <>. Like below:
> "content-type":{"media":"application/vnd.wap.multipart.related","params":
> {"type":"application/smil","start":"0.smil"}}

OMA-TS-MMS-CONF-V1_3-20110913-A 10.2.3 "Start Parameter Referring to Presentation":

  According to [RFC2387] Content-ID in start parameter contains < and > characters:

    Content-Type: Multipart/Related;
                  start="<[e-mail]>";
                  type="application/smil"

  These < and > SHALL be retained in the header, but quotes SHALL be omitted. Also,
  quotes SHALL NOT be used in the content type specification of SMIL. The
  corresponding Content-ID header of the SMIL body part SHOULD contain the same
  string with < and > included.

So, iOS is wrong.

Comment 14

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Let me summary the current situation. Below is all the solutions that I have.
If anyone can provide other solution, it is very welcome.
1. Keep current FX OS implementation is take start as 0x8A and encode as Text-value.
Pros:
* Looks like FX OS follow the spec in below descriptions:
OMA-TS-MMS_ENC-V1_3-20110913-A clause 7.1 "Special Considerations Regarding Usage of WSP in MMS":

  Table 38 in [WAPWSP] contains bugs at Expected BNF Rules for Value. “Text-value”
  MUST be used for parameter values instead of “Text-string”. 
Cons:
* It breaks MC B test raised by LEO.
* In wap-230-wsp-20010705-a, 0x8A(start) is encoded as Text-string, not Text-value. This is conflicted with OMA-TS-MMS_ENC-V1_3-20110913-A clause 7.1. This ambiguous definition might cause other implementation take 0x8A as Text-string. I guess that is why MC B test fail.
* 0x8A is deprecated  

2. Follow what Android do, take start as 0x8A and encode as Text-string.
Pros:
* Can pass MC B test.
Cons:
* Looks like we not follow OMA-TS-MMS_ENC-V1_3-20110913-A clause 7.1.
* 0x8A is deprecated  

3. Use 0x99
Cons: 
* Can't accept in some operators(Like CHT...)

4. Skip the start parameter.
Pros:
* Skip the encoding issue.
Cons:
* Violate MMS-CONF suggestion" we SHALL have "start" parameter in an application/vnd.wap.multipart.related structure"

5. Follow iOS do, remove the "<" and ">".
Pros:
* No encoding issue.
Cons:
* Violate [RFC2387] Content-ID in start parameter contains < and > characters.

So we need to make a choice.

Comment 15

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Vicamo is more suitable for this bug.

Comment 16

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

As above cited MMS specification excerpts, we have:

  I. We will NOT skip the start parameter.  See comment 10.
  II. We will NOT remove angle brackets ("<" and ">").  See comment 13.
  III. We will NOT replace TextValue with TextString at encoding parameters.  See comment 3.

So basically 2), 4), 5) are not on our options list.  For 0x8A/0x99 codes, we should definitely provide a switch to completely disable deprecate codes for better specification conformance.

One thing I would really want to clarify: NOT everything is a Gecko bug.  In Mozilla, we try to deliver a standard conforming, open implementation of various technologies required by a mobile platform.  Openness and standardization are the very basic targets and assumptions for B2G's existence and success.  Any request that violates open standards will never be the first option that we should take.

For me, that MC B test failure is itself a bug, not something Gecko should deal with.  Unless someone proves that test case is widely deployed and has became a industry convention, which I don't really think so, will we re-consider to override all the specifications cited.  You're free to fork Gecko and have any modifications in need.

Comment 17

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

Not a leo+ per yesterday's conclusion.

Comment 18

[Leo]

Leo will take this patch as discussed during MMS work week in taiwan

Comment 19

[Wayne Chang [:wchang]]

Just to clarify comment 18. This bug is not required for v1.1 for specification interpretation per comment 16. However Leo will be doing this on their own.