Peter Dolanjski [:pdol] Reporter
	Description • 12 years ago

UCID: Messages-014

User Story:
As a user, I should be able to send, receive, and view MMS messages with images that are at least 1600x1200 pixels in size in order to send, view and review MMS messages with images to or from other devices.

	Neo Hsieh [:neo]
	Comment 1 • 12 years ago

If size limitation is equal to cost, Maybe file size limitation is more important than resolution size. Unless 1600x1200 is for MMS certification. 

In some high-end mobile phone 1920x1080 is standard now, But some low-end mobile phone still stay in 320x480 or 160x120 .

Maybe we can remove this requirement, If this is not MMS certification.

	Steve Chung [:steveck] Assignee
	Comment 2 • 12 years ago

I'm confused about this issue and 840061. We'll have the size limitation for sending/receiving the message, how we deal with the situation when size exceed the limitation after inserting the image with 1600x1200 resolution? Android will resize the images automatically to make sure the total size under the limitation. If we want to keep the resolution at least 2M pixel, we might need to avoid adding image in current message.

	Casey Yee
	Comment 3 • 12 years ago

I think the requirement only really applies to incoming MMS images that are 1600x1200 or greater.   I agree with Neo here that overall file sizes are more important than the resolution of the image itself when sending images.

The UX is designed around this understanding.

See page 3:
https://www.dropbox.com/s/zc3hhd1mxi16p4w/MMS.pdf

	Casey Yee
	Comment 4 • 12 years ago

Flagging Peter for more clarity.

	Joe Cheng [:jcheng] (please needinfo)
	Comment 5 • 12 years ago

and also, bug 840061 should be the ultimate deciding factor for MMS message size as the size will be limited by operator network policy

	Vicamo Yang [:vicamo][:vyang]
	Comment 6 • 12 years ago

Please follow OMA-TS-MMS-CONF-V1_3-20110913-A section 7 "MM Content Classes" and section 14 "Creation Modes" to design UX spec. The limits defined in MMS-CONF are much much smaller than specified here.  And, resolution 1600x1200 falls to Mega-Pixel content class, but Mega-Pixel is *NOT* a mandatory conformance item for now.  Besides, Mega-Pixel class has upper-bound 1600x1200, not lower-bound.

	Peter Dolanjski [:pdol] Reporter
	Comment 7 • 12 years ago

+Kev, since he is the original author of this requirement.

	Kev Needham [:kev]
	Comment 8 • 12 years ago

The functional requirement probably helps, here. The 1600x1200 is a minimum value, where we must be able to support, at a minimum, a max image size of 1600x1200 (e.g. if we put constraints on the max image size in the OS, the minimum max size constraint would be 1600x1200, and any maximum with a lower resolution would be rejected).

	Kev Needham [:kev]
	Comment 9 • 12 years ago

The specific functional requirement is:

"Must support image resolutions of at least 1600x1200 pixels for both send and receive."

	Paul Yang [:pyang] (away)
	Comment 10 • 12 years ago

Hi Kev,
we'll create test case align with the scenario, can we simply attach http://placehold.it/1600x1200 to verify? thanks.

	Vicamo Yang [:vicamo][:vyang]
	Comment 11 • 12 years ago

(In reply to Kev Needham [:kev] from comment #9)
> "Must support image resolutions of at least 1600x1200 pixels for both send and receive."

I'm not talking about functional requirement.  I'm talking about "whether we should put this requirement in user stories at all."  I'm fine with this requirement, but just want to notice you about some technical details.

Supporting 1600x1200 images is easy.  AFAIK there is no known technical difficulties.  But MMS-CONF has other restrictions like RESTRICTED creation mode.  Under RESTRICTED creation mode, you can only send messages with attachments under a certain limitations like file size and maximum image/video resolution.  As described in bug 792326, we have only Text and Image-Basic content classes supported for now.  So actually we don't bother having requirements for supporting images with resolutions larger than 640x480.  They're simply not conformance mandatory items and are out of current scope.

However, we can still include this as a mandatory user story, but that doesn't bring any benifit.  1600x1200 belongs to Mega-Pixel content class, so does H.263 and SP-MIDI media formats.  We won't include support for the two immediately, so we're not conforming to Mega-Pixel any time soon, even we do support 1600x1200 images.

	Kai-Chih Hu [:khu]
	Comment 12 • 12 years ago

Should we and could we lower down the priority for this requirement? 
And, it looks like we may need to provide more details about the environment / situation to apply this requirement. For example, for creation modes other than RESTRICTED(ex. WARNING mode), this requirement could be applied, and might be much meaningful. Does it make sense?

	Kai-Chih Hu [:khu]
	Comment 13 • 12 years ago

We have 3 modes: FREE, WARNING, and RESTRICTED. 

So, it looks like this case is only feasible for RESTRICTED mode. Taipei office had a discussion about this case and the modes. We would suggest to choose one default mode and let's focus on the scope for the default mode. 

Peter, could we choose one default creation mode? Does it make sense? 
Thank you.

	Kev Needham [:kev]
	Comment 14 • 12 years ago

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #11)
 > Supporting 1600x1200 images is easy.  AFAIK there is no known technical
> difficulties.  But MMS-CONF has other restrictions like RESTRICTED creation
> mode.  Under RESTRICTED creation mode, you can only send messages with
> attachments under a certain limitations like file size and maximum
> image/video resolution.  As described in bug 792326, we have only Text and
> Image-Basic content classes supported for now.  So actually we don't bother
> having requirements for supporting images with resolutions larger than
> 640x480.  They're simply not conformance mandatory items and are out of
> current scope.

The specification and requirements given by the partner were pretty clear, and reviewed in November of last year. I am unsure how the conclusion stated was reached without bringing this up before now. They certainly are conformance mandatory items given the partner requirements, and if they can't be met, that should have been brought up during the initial review in November (or, the very least, well before now).

> However, we can still include this as a mandatory user story, but that
> doesn't bring any benifit.  1600x1200 belongs to Mega-Pixel content class,
> so does H.263 and SP-MIDI media formats.  We won't include support for the
> two immediately, so we're not conforming to Mega-Pixel any time soon, even
> we do support 1600x1200 images.

If the only resolution we support is 640x480 for this release, we can ask for a variance. I will note, however, that on this specific requirement, we indicated to the partner that the resolution was "unlimited" and that this minimum requirement was supported, per the MMS review performed by Mozilla and submitted to the partner.

Please that we are requesting we ask for a variance on this particular requirement.

	Kev Needham [:kev]
	Comment 15 • 12 years ago

err... please confirm that we are requesting we ask for a variance on this particular requirement.

	Dietrich Ayala (:dietrich)
	Comment 16 • 12 years ago

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.

	Vicamo Yang [:vicamo][:vyang]
	Comment 17 • 12 years ago

(In reply to Kev Needham [:kev] from comment #15)
> err... please confirm that we are requesting we ask for a variance on this
> particular requirement.

As Kevin has described in comment #13, if we have only RESTRICTED creation mode and supports only Image-Basic content class, then we don't really have to support 1600x1200 right now because you just can't send that image out.  Not it's not limited by Gecko or any other parts.  It's restricted by confirmance.

	Vicamo Yang [:vicamo][:vyang]
	Comment 18 • 12 years ago

s/Not/Note/

	Kev Needham [:kev]
	Comment 19 • 12 years ago

So we do not comply with a requirement that Mozilla has stated in a requirements response as being compliant previously. This means I need to inform the partner. All I was asking was for confirmation of that, which I believe comment #17 does.

	Joe Cheng [:jcheng] (please needinfo)
	Comment 20 • 11 years ago

so it seems this is an invalid user story. should this be closed?

	Peter Dolanjski [:pdol] Reporter
	Comment 21 • 11 years ago

Daniel/Maria, what is your opinion on the modes mentioned in comment 13?

	Maria Angeles Oteo (:oteo)
	Comment 22 • 11 years ago

In Bug 792327 it's clear that the only mode for MMS will be the RESTRICTED mode, and in order to be compliant with that mode some limitations on the attachments need to be enforced. The image size described in this User Story will make the device not conform with the MMS RESTRICTED mode. Ideally, if we wish to support those kind of big attachments we should support the FREE mode, but it seems that this was not planned and now is too late for adding that support.

	Peter Dolanjski [:pdol] Reporter
	Comment 23 • 11 years ago

If we are only supporting the mandatory RESTRICTED MODE for leo, does it make sense to close this requirement?

	Kev Needham [:kev]
	Comment 24 • 11 years ago

Yes, but it's not exactly what we had specified as being compliant with. Agreed we can close, but this needs to be pushed into 1.1 if possible.

	Dietrich Ayala (:dietrich)
	Comment 25 • 11 years ago

All parties present seem to agree we can move this out until we support modes other than RESTRICTED, so blocking-.

	Vicamo Yang [:vicamo][:vyang]
	Comment 26 • 11 years ago

Since some (vCard -- bug 849729, vCalendar -- bug 849733) features are not going to be implemented in v1.1, and this is actually not blocked by all mandatory conformance items, don't depend on bug 792319 here.

	Julien Wajsberg [:julienw]
	Comment 27 • 11 years ago

I think we should close this WONTFIX and eventually re-create it later on when we'll want to do it. Joe, what's your call?

	Paul Yang [:pyang] (away)
	Comment 28 • 11 years ago

As this user story does exist in IOT test and MMS spec, we might finish the discussion in this thread - personally, I don't think we should follow since there's no way to know the operator's threshold.

	Joe Cheng [:jcheng] (please needinfo)
	Comment 29 • 11 years ago

let's close it 
new bugs should be filed if it comes up again in later releases