SW171 AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.152 Firefox os v1.1 Mozilla build ID:20130702230206 DEFECT DESCRIPTION: Client doesn't support restricted MMS creation. REPRODUCING PROCEDURES: From PICS: ics_restricted Client support restricted MMS creation (mandatory for version 1.2 on) 1. There is no setting for MMS creation mode. 2. Create a MMS, the restricted media file can be added to MMS. So our client didn't support restricted MMS creation. EXPECTED BEHAVIOUR: From the pics, client should support restricted MMS creation mode. ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: 100% For FT PR, Please list reference mobile's behavior:

It's a blocker certification.

There is not setting available per design. Default restricted and ONLY support restricted

please change PICS to not support to unblock certification. will this be ok? thank you

sorry for the batch update on comment 3. Actually it is supported but only without settings UI. Will this be ok to pass certification? if not, can we change the PICS to not support? thanks

(In reply to Joe Cheng [:jcheng] from comment #4) > sorry for the batch update on comment 3. > Actually it is supported but only without settings UI. Will this be ok to > pass certification? if not, can we change the PICS to not support? thanks OK

Minusing for blocking based on the go ahead in comment 5

Dear John Hammink, (1) Your PICS: (a) ** restricted is supported ** (b) restricted is the ONLY support one (c) there is no setting UI (2) our test result is that: (a) Create a MMS, the restricted media file can be added to MMS. (b) So our client ** didn't support restricted MMS creation ** . Test results does not follow your design. I think there still exists some problems deserved our focus on. BRs, TIAN　Min

Steve/Vicamo, can you provide further input to this? Thanks

Ma(In reply to 田旻 from comment #7) > Dear John Hammink, > > (1) Your PICS: (a) ** restricted is supported ** (b) restricted > is the ONLY support one (c) there is no setting UI > > (2) our test result is that: (a) Create a MMS, the restricted media file can > be > added to MMS. (b) So our client ** didn't support restricted MMS creation > ** . > > Test results does not follow your design. > > I think there still exists some problems deserved our focus on. > > BRs, > TIAN　Min Currently we only handle oversized case, but non core domain content case is not included. Hi Dominic, I've tried to restrict the data type(audio/amr) option for music picker but it dosen't work. I added audio/amr in music pick type but the music option could not show up while picking the multimedia file. Could you confirm that if it is possible to activate music (or gallery/video) picker with restricted data type? Thanks.

Joe, Is this a cert blocker per comment 1?

in restricted mode, these files should not be added into MMS prompt something like: other mobile phone (the receiver side) may not support

(In reply to Cheng-An, XIONG from comment #11) > Created attachment 789455 [details] > creation_mode.zip > > in restricted mode, these files should not be added into MMS > > prompt something like: other mobile phone (the receiver side) may not support only below types are allowed (image): jpe,jpeg,gif,wbmp. (audio): amr,midi,mid, (video): mp4,3gpp(*.3gp),3gpp2(*.3gp).

(In reply to Steve Chung [:steveck] from comment #9) > Hi Dominic, I've tried to restrict the data type(audio/amr) option for music > picker but it dosen't work. > I added audio/amr in music pick type but the music option > could not show up while picking the multimedia file. Could you confirm that > if it is possible to activate music (or gallery/video) picker with > restricted data type? Thanks. Currently the audio mimetypes we can pick are listed in the manifest.webapp of music app: "type": ["audio/*", "audio/mpeg", "audio/ogg", "audio/mp4"] and you can see "audio/amr" is not one of them, so if you added it, it does not match to the mimetypes criteria and the music app will not be listed in the picking options. Also currently sms uses: type: ['image/*', 'audio/*', 'video/*'] to pick all the image, audio and video files so that's why "audio/amr" can be picked for now. But if we want to restrict some specific mimetypes only: 1. We should make sure the target types are listed in the manifest.webapp of the media apps. 2. The media apps should also filter the files and display the specific files only base on the given types.

Hi, Gecko should return an error to Gaia once its configured as in RESTRCITED creation mode, and Gaia just react with that error message. How do you think?

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #14) > Hi, Gecko should return an error to Gaia once its configured as in > RESTRCITED creation mode, and Gaia just react with that error message. How > do you think? Hi Vicamo, I think gaia could handle this type checking. It could be more responsive to notify user the error at the first place instead of after message sent. Hi Ayman, here we have 2 approaches for the ux: 1) Showing 'unsupported file type' warning dialog after picker return the media to message app 2) Set the picker filter while opening the picker, therefore only supported media will be in the list and there is no need to have warning dialog. The gaia work in these 2 approch is different. The changes in (1) only to add type checking in message app, but (2) need to add the type filter in music/video/gallery app. Approch (2) will have better ux because user will not able to selec the unsupported file type .It might be improtant since it's very possible to selete the unsupported file because of the limited set. We need your help to confirm the ux behavior the before implementation, thanks.

(In reply to Cheng-An, XIONG from comment #12) > (In reply to Cheng-An, XIONG from comment #11) > > Created attachment 789455 [details] > > creation_mode.zip > > > > in restricted mode, these files should not be added into MMS > > > > prompt something like: other mobile phone (the receiver side) may not support > > only below types are allowed > (image): jpe,jpeg,gif,wbmp. > (audio): amr,midi,mid, > (video): mp4,3gpp(*.3gp),3gpp2(*.3gp). let's come back to this. i think the question is, are the formats outside of this need to be blocked? Can you show us the spec that you are referring to? it does not seem like there are end user impacts on this either. if our phone can decode a format and send it and the other phone can receive it and decode it. anything wrong? Thanks

(In reply to Joe Cheng [:jcheng] from comment #16) > (In reply to Cheng-An, XIONG from comment #12) > > (In reply to Cheng-An, XIONG from comment #11) > > > Created attachment 789455 [details] > > > creation_mode.zip > > > > > > in restricted mode, these files should not be added into MMS > > > > > > prompt something like: other mobile phone (the receiver side) may not support > > > > only below types are allowed > > (image): jpe,jpeg,gif,wbmp. > > (audio): amr,midi,mid, > > (video): mp4,3gpp(*.3gp),3gpp2(*.3gp). > > let's come back to this. > i think the question is, are the formats outside of this need to be blocked? > Can you show us the spec that you are referring to? > > it does not seem like there are end user impacts on this either. if our > phone can decode a format and send it and the other phone can receive it and > decode it. anything wrong? > > Thanks page 123 attached. .wav/.mp3/.imy/.png should not be added to MMS if RESTRICT mode is support. Test Procedure 1. In client A, create a new MM. 2. In MM content: Try to add any one of the following files that does not belong to the core domain (song.wav, song.mp3, song.imy or image.png) to the message. 3. Verify the pass criteria below. Pass Criteria Client A is limited to the addition of allowable content within the CORE Domain. The inclusion of any one of the above content types is refused.

We cannot add features to v1.1 and this is a new feature (restricted mode) so it will have to go into v1.2

Dear, This bug is a block and certification bug. I don't think it's very appropriate to degrade it from "leo?" to "koi?" TIAN Min

(In reply to lsblakk@mozilla.com [:lsblakk] from comment #18) > We cannot add features to v1.1 and this is a new feature (restricted mode) > so it will have to go into v1.2 Dear Joe, Lsblakk, "restricted mode" is not new feature of v1.1. see Comment #7 and the PICS file provided by Moz. Thanks.

Hi Chengan, The type you provided seems doesn't match OMA spec. It's not in the old version(2008 you provided) nor in the new version(2010). OMA core domain I saw in 2010 version: Image: JPEG, GIF, WBMP. Audio: AMR series, 13K (QCELP) Video: H.264/MPEG-4 , H.263. Could you please confirm the type set before next step? Thanks.

Actually there is a latest OMA spec(2013-02-05). I am attaching it and we can also download it from: http://technical.openmobilealliance.org/Technical/release_program/mms_v1_3.aspx

I am looking on the spec 3GPP TS 26.140 called: - Multimedia Messaging Service (MMS); Media formats and codecs - http://www.3gpp.org/ftp/Specs/html-info/26140.htm on page 9, 10 and 11 it described what "should be supported" for image/audio/video. Image: JPEG, GIF, PNG and SVG. Audio: AMR series, Enhanced aacPlus and MIDI. Video: H.264/MPEG-4, H.263. The formats that should be supported are different from OMA and 3GPP. Which spec. should we follow? 3GPP or OMA? or both?

All, We follow OMA spec do test and also in PTCRB. Please refer to comment #17, that (song.wav, song.mp3, song.imy or image.png) are used for test. i.e. png/wav/mp3/imy should not be added into MMS.

Hi Cheng-an, Given the time we have for v1.1 (to avoid late l10n strings to warn users about why their contents cannot be added), please waive this for v1.1. Marking this as koi+ so this can be resolved for v1.2

also, we decreased the mms version in bug 905087, so now it's probably not a certification blocker anymore.

Per discussion with Joe and Steve, this one is more appropriate to be solved on the Gaia side.

After meeting with Steve adding ni? to Tyler to provide required strings. Tyler please talk directly to Steve Chung about the strings that he required

Hi Taylor, per previous discussion about the warning creation mode, we need the string about "This type of attachment is not supported in mms spec, do you still want to attach it?". Could you please provide the wording for warning dialog(Maybe we also need "This type of attachment is not supported in mms spec." for restricted creation mode)? Thanks. Hi Joe, I just discuss this issue with vicamo, and he suggest that restricted mode should be supproted for the certification. That means we should have option in settings for switching creation mode. Do you think we should implement this in v1.2 or later?

(In reply to Julien Wajsberg [:julienw] from comment #26) > also, we decreased the mms version in bug 905087, so now it's probably not a > certification blocker anymore. Just check the OMA conformance v1.1 again, it didn't define the creation mode in OMA v1.1 MMS conformance. It might not be the certification blocker, but we need partners to confirm this.

comment 29 sound like a new feature if we were to add menu in settings. this was koi+ as a bug fix to simply show the strings when attachment is not supported. let's see comment 30 feedback as well.

(In reply to Steve Chung [:steveck] from comment #29) > Hi Taylor, per previous discussion about the warning creation mode, we need > the string about "This type of attachment is not supported in mms spec, do > you still want to attach it?". Could you please provide the wording for > warning dialog(Maybe we also need "This type of attachment is not supported > in mms spec." for restricted creation mode)? Thanks. Hi Steve, I'm not clear on the message we need to convey. If the type of content isn't supported and can't be sent, why are we asking if they still want to attach it? Shouldn't it be a simple message saying that the file type can't be sent, and telling them the types that they can send?

(In reply to tyler.altes from comment #32) > > Hi Steve, I'm not clear on the message we need to convey. If the type of > content isn't supported and can't be sent, why are we asking if they still > want to attach it? Shouldn't it be a simple message saying that the file > type can't be sent, and telling them the types that they can send? Hi Taylor, it depends on what kind of the creation mode user choose. If we set creation mode as "restricted", we should popup a warning dialog with "ok" button only for blocking the unsupported file attaching; if creation mode is "warning", we should also popup warning dialog in this mode with "attach" and "cancel" button and we could not block the unsupported file attaching if user click "attach". So the options and wording in the dialog whould be different in 2 modes. Since partner only mentioned the restricted creation mode here, we might only need string for restricted creation mode now, thanks.

> Hi Taylor, it depends on what kind of the creation mode user choose. If we > set creation mode as "restricted", we should popup a warning dialog with > "ok" button only for blocking the unsupported file attaching; if creation > mode is "warning", we should also popup warning dialog in this mode with > "attach" and "cancel" button and we could not block the unsupported file > attaching if user click "attach". So the options and wording in the dialog > whould be different in 2 modes. Since partner only mentioned the restricted > creation mode here, we might only need string for restricted creation mode > now, thanks. Hi, I'm still not sure I understand what's happening. The user chooses a "creation mode" for attaching the file? Sometimes we let them attach unsupported files and sometimes we don't? For the restricted case you mention, the message would be: "Message attachments can be X, X, X, or X." (X = supported file type) Does this work? Also, let me know if another message is needed for the "warning case".

Joe, Please help understand why this was re-nom?

action on me to talk to partner whether this is needed given that we moved MMS to MMS v1.1 per Bug 905087 - [MMS] decrease the supported version in the X-Mms-Version header

Triage: minus. We may claim "restricted is not support" in PICS

Hello, everyone. Is there any advance about this problem. This problem will influence our certification badly and can't be waived any more in future build.

Thus maybe we should pay more focus on it.

Hey Beatriz, do we really need this for the certification ?

(In reply to Julien Wajsberg [:julienw] from comment #40) > Hey Beatriz, > > do we really need this for the certification ? Hi Julien, this requirement did not come from our side, but... there are other partners in this project!

(In reply to Beatriz Rodríguez [:brg] from comment #41) > (In reply to Julien Wajsberg [:julienw] from comment #40) > > Hey Beatriz, > > > > do we really need this for the certification ? > Hi Julien, this requirement did not come from our side, but... there are > other partners in this project! Yes, SPM told me this problem must be fixed on version 1.3.

Hi 田旻, Current mms version is v1.1 now, not v1.3 we claimed originally(please ref bug 905087). Creation mode is not in OMA v1.1 spec(please ref the attachment). It was also metioned in comment 0: ics_restricted Client support restricted MMS creation (mandatory for version 1.2 on) If you think creation mode is still a certification blocker, I have some questions about how we can pass the certification: - Can we just claim we "do not" support "restricted" creation mode? If we still need to choose a creation mode for certification, can we claim we just support "free" creation mode?

Wilfred, can you confirm that this is on the backlog and targeted for 1.3?

Moving to 1.3 per comment 42. Buri is expecting this fix in 1.2.

Minus from 1.3? until we have confirmation this is certification blocker as per comment 36 and 43. I will keep this in the back log as a feature enhancement for future releases.

(In reply to Steve Chung [:steveck] from comment #43) > Created attachment 823741 [details] > OMA-IOP-MMSCONF-V2_0_0-20040715-A.pdf > > Hi 田旻, > Current mms version is v1.1 now, not v1.3 we claimed originally(please ref > bug 905087). Creation mode is not in OMA v1.1 spec(please ref the > attachment). > It was also metioned in comment 0: > ics_restricted Client support restricted MMS creation (mandatory for version > 1.2 on) > > If you think creation mode is still a certification blocker, I have some > questions about how we can pass the certification: > > - Can we just claim we "do not" support "restricted" creation mode? If we > still need to choose a creation mode for certification, can we claim we just > support "free" creation mode? I think it's a MUST surport item about creation mode at least on v1.3. However we can see from the comment 0, we should better support it on v 1.2.

If we could fixed this bug on version 1.2, that will be much better.

Please be noticed the 'version' I metioned in comment 43 is MMS version, not FFOS release version. No matter which FFOS version we released(v1.1 / v1.2/ v1.3), we all claim our MMS version followed OMA conformance spec v1.1. May I know the certification you used now based on which MMS spec version?

(In reply to Steve Chung [:steveck] from comment #49) > Please be noticed the 'version' I metioned in comment 43 is MMS version, not > FFOS release version. No matter which FFOS version we released(v1.1 / v1.2/ > v1.3), we all claim our MMS version followed OMA conformance spec v1.1. May > I know the certification you used now based on which MMS spec version? We use OMA conformance spec v1.1 now, but spec v1.2 or v1.3 is probably requested in future.

Steve, do we need UX changes for this feature ? If yes, I doubt we'll do it even for 1.3. I think we'll need an entry in the settings menu we're adding in 1.3, therefore we won't do it in 1.2 for sure, and 1.3 is already full of features. We could live without this until now, I think this could be deferred to 1.4.

This is not going into 1.2 and we are late for v1.3. The next chance will be v1.4. My question is simple (even to include in v1.4): If we use MMS (OMA Spec v1.1) on FX OS v1.4 - do we need to have MMS Restricted mode to pass certification? I understand at some point later we will move to MMS OMS spec 1.2/1.3 - but while we are still at OMA Spec 1.1 do we need MMS restricted mode?

(In reply to Julien Wajsberg [:julienw] from comment #51) > Steve, do we need UX changes for this feature ? If yes, I doubt we'll do it > even for 1.3. > > I think we'll need an entry in the settings menu we're adding in 1.3, > therefore we won't do it in 1.2 for sure, and 1.3 is already full of > features. We could live without this until now, I think this could be > deferred to 1.4. If we need creation mode in the later version, I still have some question need to be clarify: - Is the 'restricted' creation mode mandatory for certification? or can we claim we just support 'free' creation mode. In 'free' creation mode we don't need to block for sending nor popup a warning dialog for type limitation, which means there might be no or few efforts to claim 'free' creation mode. - If 'restricted' creation mode is mandatory item for certification, we need to sync the supported media type list. The set in comment 12 seems different from the oma mms v1.3 spec, and set provide by Dominic(comment 23) and me (comment 21) also has some difference. Please provide the set you used for certification testing. - Do we need to support more than single creation mode? If we should support multiple creation modes, we will need an additional option in message settings panel.

To me, so many question at this time => we need to resolve these questions during 1.3 development, and implement this in 1.4, in a quiet pace.

This request should be part of Bug 802290 and there's still lots of unclear parts as I said in comment 53. Un-assign myself since we won't have any further plan in near future.

Mass closing of Gaia::SMS bugs. End of an era :(

Mass closing of Gaia::SMS bugs. End of an era :(