840061 - [MMS][User Story] Operator size limit definition

Status: RESOLVED FIXED

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

Description

[Peter Dolanjski [:pdol]]

UCID: Messages-048

User Story:
As an operator, I can set the maximum MMS message size that can be sent or received on the device (in kilobytes) in order to ensure that messages composed and/or received from the device adhere to network policy.

Comment 1

[Casey Yee]

This should be configured as a pref.

page 5 of the spec shows what happens when a user tries to attach a file larger than the set limit:
https://www.dropbox.com/s/zc3hhd1mxi16p4w/MMS.pdf

Comment 2

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

This bug is to provide the customization capability for bug 840038

Comment 3

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

(In reply to Peter Dolanjski [:pdol] from comment #0)
> UCID: Messages-048
> 
> User Story:
> As an operator, I can set the maximum MMS message size that can be sent or
> received on the device (in kilobytes) in order to ensure that messages
> composed and/or received from the device adhere to network policy.

maximum MMS message size = complete message (all headers + attachments)? or just the size of the attachments?

Comment 4

[Wilfred Mathanaraj [:WDM]]

includes all : content, attachment and headers

Comment 6

[Kai-Chih Hu [:khu]]

Peter, so, for this case, we don't really need to provide an UI to configure this option, right? It looks like if we can provide a way to configure this one during build time, it's also ok? Thanks.

Comment 7

[Peter Dolanjski [:pdol]]

Kev, could you check with the partner on this being set as a build time configuration?

Comment 8

[Kev Needham [:kev]]

This is an operator-set parameter which does not have any requirement to expose it to the user (and it should not be exposed to the user). The network also enforces this requirement, and the main reason for having this parameter in place is to ensure the user is informed that their message size is too large prior to attempting to send the message and getting a failed send or other network error.

Comment 9

[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 10

[Steve Chung [:steveck]]

Hi Kev, is this limitation also necessary for message receiving? Because conformance says we should not block message receiving depends on message size. If we do block the over-sized message, do we need to ignore the message and remove from the database, or just stop the attachments downloading(and maybe send a notification to user) ?

Comment 11

[Steve Chung [:steveck]]

Attachment: Patch for operator customizable MMS message size limitation

Hi Vicamo, I added 'dom.mms.operatorSizeLimitation' key in settings DB for customization. Please inform me if the key naming doesn't follow the convention, thanks.

Comment 12

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

(In reply to Steve Chung from comment #11)
> Created attachment 728077 [details]
> Patch for operator customizable MMS message size limitation
> 
> Hi Vicamo, I added 'dom.mms.operatorSizeLimitation' key in settings DB for
> customization. Please inform me if the key naming doesn't follow the
> convention, thanks.

Maybe 'dom.mms.maxMessageSize'? Seems more clearly reflect that it's about message size, not length of operator names, or number of operators, etc. And, will there be different limitations for incoming and outgoing messages? For example, you might want to limit outgoing messages only, and accept all incoming messages of all sizes.

Comment 13

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

Comment on attachment 728077 [details]
Patch for operator customizable MMS message size limitation

Have comments in Github instead. It seems a return statement is missing. Besides, what's the expected behaviour if such size limitation is unset. Shouldn't it mean NO LIMIT instead?

Comment 14

[Steve Chung [:steveck]]

Hi Kev, per Vicamo's comment at #13, should we define a default MMS message size if operator doesn't customize the limitation, or just set no limitation for both sending/receiving ?

Comment 15

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

leo+ as this is a part of MMS. No_UPLIFT for now before the whole MMS is completed

Comment 16

[Paul Yang [:pyang] (away)]

moztrap #6675

Comment 17

[Kev Needham [:kev]]

No limitation gets my vote. If there's a limit, it's usually enforced network side anyways. Something to flag in customization docs, too.

Comment 18

[Dietrich Ayala (:dietrich)]

Steve, does this need a new patch? If not, should it get review from Julien instead of Borja (who's out this week)?

Comment 19

[Steve Chung [:steveck]]

Comment on attachment 728077 [details]
Patch for operator customizable MMS message size limitation

Oh yes, I will change the review to Julien, but I need some modification about removing the message size upper bound by default base on Kev's comment. I'll remove the review request first, Thanks.

Comment 20

[Steve Chung [:steveck]]

Comment on attachment 728077 [details]
Patch for operator customizable MMS message size limitation

Hi Borja, I change the size limitation to unlimited by default and add some test cases. Please contact me if you got any question about the patch, thanks.

Comment 21

[Borja Salguero [:borjasalguero]]

This customization param is detailed in the following link:
https://wiki.mozilla.org/B2G/MarketCustomizations#Customization_Overview

Comment 22

[Steve Chung [:steveck]]

This feature is mms related but no UI involved and won't affect sms functionality. I landed this patch in master: 87ce52cdce7c18d40b50f5785bf5016458e99b9a

Comment 23

[Steve Chung [:steveck]]

Reopen this issue for reducing the conflict and refinement

Comment 24

[Steve Chung [:steveck]]

Attachment: Patch for code refinement

Comment 25

[Jason Smith [:jsmith]]

Just a process comment in the future - I'd suggest filing followups for patches in separate bugs and avoid reopening the same bug for multiple patches.

Comment 26

[Borja Salguero [:borjasalguero]]

Comment on attachment 746704 [details]
Patch for code refinement

R+. Please take a look to Corey's questions about the API. Thanks!

Comment 27

[Steve Chung [:steveck]]

Thanks for the reminder, Jason. I'll open another follow up bug next time

Comment 28

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 87ce52cdce7c18d40b50f5785bf5016458e99b9a to:
v1-train: d24ba14b56cd391da071db227fd2153120604b9c