Closed Bug 890180 Opened 7 years ago Closed 6 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED WONTFIX
1.1 QE5

People

(Reporter: ctai, Assigned: vicamo)

References

Details

Attachments

(1 file)

We set the wrong code in WSP Well-Known Parameter Assignments including name, type and start.
Discussed with CTai and marking them as Leo+.
- Veeresh
blocking-b2g: --- → leo+
Target Milestone: --- → 1.1 QE4 (15jul)
(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.
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.
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.
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.
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.
(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.
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!
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.
See Also: → 890166
Priority: -- → P1
Duplicate of this bug: 890166
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"}}
(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="<950120.aaCC@XIson.com>";
                  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.
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.
Assignee: ctai → nobody
Vicamo is more suitable for this bug.
Assignee: nobody → 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.
Whiteboard: TaipeiMMS
Not a leo+ per yesterday's conclusion.
blocking-b2g: leo+ → ---
blocking-b2g: --- → leo+
Target Milestone: 1.1 QE4 (15jul) → 1.1 QE5
Leo will take this patch as discussed during MMS work week in taiwan
blocking-b2g: leo+ → ---
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.
Whiteboard: TaipeiMMS
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.