972705 - [WAP push][OMA CP] Handle/parse APPLICATION characteristic elements for POP3/IMAP/SMTP settings.

Status: RESOLVED WONTFIX

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

Description

[sync-1]

the latest id: Mozilla build ID: 20140118004002 FFOS: 1.3
 
 DEFECT DESCRIPTION:
  Can't receive OMA provisioning .
  REPRODUCING PROCEDURES:
  1,Send an OMA provisioning from Now SMS to handset
 
  EXPECTED BEHAVIOUR:
 Can receive OMA provisioning .
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:10/10

Comment 1

[sync-1]

Attachment: refer this picture

Comment 2

[Jason Smith [:jsmith]]

Enpei - Are you able to reproduce this?

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Is this meant to be filed under the Messages app or system app?  The e-mail app definitely does not know anything about OMA provisioning.  I'm speculatively moving the bug there...

Comment 4

[Gabriele Svelto [:gsvelto]]

I think this is WAP Push and AFAIK should have already been implemented, see bug 848403 and bug 917312.

Comment 5

[Enpei]

I can receive OMA browser and MMS client provisioning messages on Buri. 
Gaia      f9a37c77efb4621a1f57e4695b497d18601fe134
Gecko     http://hg.mozilla.org/releases/mozilla-aurora/rev/3d9d920ca43b
BuildID   20140203004001
Version   28.0a2

OMA CP messages must have security enabled (USERPIN or NETWPIN). Please make sure it's enabled before sending the message to DUT.

Comment 6

[sync-1]

(In reply to comment #4)
 > Comment from Mozilla:I can receive OMA browser and MMS client provisioning
 > messages on Buri. 
 > Gaia      f9a37c77efb4621a1f57e4695b497d18601fe134
 > Gecko     http://hg.mozilla.org/releases/mozilla-aurora/rev/3d9d920ca43b
 > BuildID   20140203004001
 > Version   28.0a2
 > 
 > OMA CP messages must have security enabled (USERPIN or NETWPIN). Please make
 > sure it's enabled before sending the message to DUT.
 > 
 
 I tested ,but it still can't receive OMA provisioning.

Comment 7

[Enpei]

(In reply to sync-1 from comment #6)
> (In reply to comment #4)
>  > Comment from Mozilla:I can receive OMA browser and MMS client provisioning
>  > messages on Buri. 
>  > Gaia      f9a37c77efb4621a1f57e4695b497d18601fe134
>  > Gecko     http://hg.mozilla.org/releases/mozilla-aurora/rev/3d9d920ca43b
>  > BuildID   20140203004001
>  > Version   28.0a2
>  > 
>  > OMA CP messages must have security enabled (USERPIN or NETWPIN). Please
> make
>  > sure it's enabled before sending the message to DUT.
>  > 
>  
>  I tested ,but it still can't receive OMA provisioning.

Hi, can you please provide us

1. The screen shot of NowSMS OMA provisioning page before you send the message
2. Use engineer build and capture logcat of this bug
3. How did you build the code you use?

Comment 8

[sync-1]

(In reply to comment #4)
 > Comment from Mozilla:I can receive OMA browser and MMS client provisioning
 > messages on Buri. 
 > Gaia      f9a37c77efb4621a1f57e4695b497d18601fe134
 > Gecko     http://hg.mozilla.org/releases/mozilla-aurora/rev/3d9d920ca43b
 > BuildID   20140203004001
 > Version   28.0a2
 > 
 > OMA CP messages must have security enabled (USERPIN or NETWPIN). Please make
 > sure it's enabled before sending the message to DUT.
 > 
 Can you provide me your OMA provisioning xml file of EMAIL? I try to test again.

Comment 9

[Enpei]

<wap-provisioningdoc><characteristic type="BOOTSTRAP"><parm name="NAME" value="CHT MMS"/><parm name="PROXY-ID" value="CHT MMS_Proxy"/></characteristic><characteristic type="NAPDEF"><parm name="NAME" value="CHT MMS"/><parm name="NAPID" value="CHT_MMS_NAPID"/><parm name="BEARER" value="GSM-GPRS"/><parm name="NAP-ADDRESS" value="epc.tmobile.com"/><parm name="NAP-ADDRTYPE" value="APN"/></characteristic><characteristic type="PXLOGICAL"><parm name="NAME" value="CHT MMS"/><parm name="PROXY-ID" value="CHT MMS_Proxy"/><parm name="STARTPAGE" value="http://wap.emome.net/"/><characteristic type="PXPHYSICAL"><parm name="PHYSICAL-PROXY-ID" value="CHT MMS_PhProxy"/><parm name="PXADDR" value="210.25.112.58"/><parm name="PXADDRTYPE" value="IPV4"/><parm name="TO-NAPID" value="CHT_MMS_NAPID"/><characteristic type="PORT"><parm name="PORTNBR" value="9201"/><parm name="SERVICE" value="CO-WSP"/></characteristic></characteristic></characteristic><characteristic type="APPLICATION"><parm name="APPID" value="w2"/><parm name="NAME" value="CHT MMS"/><parm name="TO-PROXY" value="CHT MMS_Proxy"/><characteristic type="RESOURCE"><parm name="NAME" value="CHT MMS"/><parm name="URI" value="http://wap.emome.net/"/><parm name="STARTPAGE"/></characteristic></characteristic></wap-provisioningdoc>

Comment 10

[José Antonio Olivera Ortega [:jaoo]]

Let me jump into the discussion. The OMA CP logic implemented in the WAP PUSH app only handles provisioning documents with APPLICATION nodes for the Browsing Enabler and AC for the Multimedia Messaging System Enabler. I suppose (for the title of this bug) you want the OMA CP logic to handle email settings and this is not implemented.

Comment 11

[Jason Smith [:jsmith]]

Sounds like we know what the feature request is here then.

Comment 12

[Gabriele Svelto [:gsvelto]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #10)
> Let me jump into the discussion. The OMA CP logic implemented in the WAP
> PUSH app only handles provisioning documents with APPLICATION nodes for the
> Browsing Enabler and AC for the Multimedia Messaging System Enabler. I
> suppose (for the title of this bug) you want the OMA CP logic to handle
> email settings and this is not implemented.

Thanks for the explanation José, can you change the title of this bug so that it reflects more accurately the requested feature?

Comment 13

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Gabriele Svelto [:gsvelto] from comment #12)

> Thanks for the explanation José, can you change the title of this bug so
> that it reflects more accurately the requested feature?

IHMO we should wait for the confirmation from [e-mail] before considering my assumption true. Once [e-mail] confirms what I commented in comment #10 I will be happy to change the title of this bug, of course.

Comment 14

[Gabriele Svelto [:gsvelto]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #13)
> IHMO we should wait for the confirmation from [e-mail] before
> considering my assumption true. Once [e-mail] confirms what I
> commented in comment #10 I will be happy to change the title of this bug, of
> course.

OK, thanks.

Comment 15

[sync-1]

(In reply to comment #9)
 > Comment from Mozilla:Let me jump into the discussion. The OMA CP logic
 > implemented in the WAP PUSH app only handles provisioning documents with
 > APPLICATION nodes for the Browsing Enabler and AC for the Multimedia Messaging
 > System Enabler. I suppose (for the title of this bug) you want the OMA CP logic
 > to handle email settings and this is not implemented.
 > 
 
 Yes,this is what I want.

Comment 16

[José Antonio Olivera Ortega [:jaoo]]

Change the title of this bug so that it reflects more accurately the requested feature.

The APPLICATION characteristic elements for POP3/IMAP/SMTP settings are detailed in the following documents:

- http://technical.openmobilealliance.org/Tech/omna/dm-ac/ac_110_pop3.txt
- http://technical.openmobilealliance.org/Tech/omna/dm-ac/ac_143_imap.txt
- http://technical.openmobilealliance.org/Tech/omna/dm-ac/ac_25_smtp.txt

We should parse and handle the application characteristic elements above and set up the configuration in the email app somehow. The platform underneath and the RIL plumbing is ready for this so we just need to hack a bit on Gaia.

Comment 17

[Jason Smith [:jsmith]]

Not a blocker - this is a new feature, which we are no longer accepting features in 1.3.

Comment 19

[Salvador de la Puente González [:salva]]

Could we use IAC to broadcast a email configuration message to wake up the email application and allow to auto-configure itself? Does it make sense?

ni to jburke to check feasibility.

Comment 20

[James Burke [:jrburke]]

These are all new terms and mechanisms for me, so it would be helpful to have some pointers to some docs or existing code for other apps to learn how the mechanism works, and the expected flow.

For example, in comment 16, looking at the IMAP descriptions, it has listings for some config or auth types we do not support. What is the expected flow if we receive information like that? Maybe this question does not make sense once I understand the mechanisms involved.

In the general sense, the email app can respond to outside triggers like notifications or web activities, so if this is something like that, then it is likely possible. The bigger questions for me are around understanding the full flow. For instance, is there user interaction at all or is the account just seeded so that the next time, when the user opens the email app it can show messages.

Comment 21

[Salvador de la Puente González [:salva]]

AFAIK, you can see more the latest info about IAC API in [1].

The flow should be:

 1. A WAP message is received from the network.
 2. The WAP message is parsed on System APP (or whoever is in charge of currently parsing these SMS)
 3. If it is an email config message, the APP in charge broadcast a configuration message via IAC.
 4. Current E-mail APP receives the broadcasted message and configure itself if needed.

No user interaction is needed.

IAC code is being used in Cost Control to communicate Message APP about silencing some balance query related SMS.

The publishing part can be found in [2] and the subscriber part in [3].

WDYT?

[1] https://wiki.mozilla.org/WebAPI/Inter_App_Communication_Alt_proposal
[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/costcontrol/js/iac_manager.js#L21
[3] https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/js/silent_sms.js#L20

Comment 22

[James Burke [:jrburke]]

Thanks for the links! This is still new to me, so I may ask some questions here that are pretty basic for someone who is better versed in these types of SMS config pathways:

1) For the specific email case, what about using a web activity instead? The IAC mechanism seems to need to set up specific connection mentions to manifestURLs, where I could see it as generically useful for even an email provider's support docs to be able to trigger a web activity that would then help the user configure their email account. The web activity would also let alternative email clients a chance at autoconfiguring too. In summary, better decoupling and interop.

2) What is the broader expected flow for this? Is it just for new account setup, or would the desire be to also alter an existing account setup? When would these messages be sent, for example, in the response to a user request, in-store/help line support, factory setup?

3) What are expectations about what fields are configurable, and how does those expectations map to the structures mentioned in comment 16? For instance, it is useful for the email app to get the smtp settings along with either imap/pop3 in one activity/connection call. What about fields like a "signature" or background sync interval? Are passwords sent via this mechanism, or is it just basic server settings and maybe email account name? For something like APPAUTH/AAUTHTYPE, the email app does not support all the values in that list.

For 3), I am sure it is just a matter of documenting what is supported, for the email app, but want to be sure the capabilities that are supported are well understood and agreed upon.

4) Can we get some example messages that may be sent in the wild, to use for testing? This would help us create some tests that make sure we continue to keep the feature operational in the future.

Comment 23

[Salvador de la Puente González [:salva]]

(In reply to James Burke [:jrburke] from comment #22)
> Thanks for the links! This is still new to me, so I may ask some questions
> here that are pretty basic for someone who is better versed in these types
> of SMS config pathways:
> 
> 1) For the specific email case, what about using a web activity instead?

Because it needs user interaction and the WAP push message could be received at any moment even when the user is not looking at the device.

> The IAC mechanism seems to need to set up specific connection mentions to
> manifestURLs, 

Nop, the IAC mechanism is based on keywords and any subscriber can answer to the keyword.

> where I could see it as generically useful for even an email
> provider's support docs to be able to trigger a web activity that would then
> help the user configure their email account. The web activity would also let
> alternative email clients a chance at autoconfiguring too. In summary,
> better decoupling and interop.

What is true is that a web activity allow a 3rd-party app to configure other webapps as web activities are privileged while IAC is still certified.

> 
> 2) What is the broader expected flow for this? Is it just for new account
> setup, or would the desire be to also alter an existing account setup? When
> would these messages be sent, for example, in the response to a user
> request, in-store/help line support, factory setup?

I think we need some clarifications from UX here.

> 
> 3) What are expectations about what fields are configurable, and how does
> those expectations map to the structures mentioned in comment 16? For
> instance, it is useful for the email app to get the smtp settings along with
> either imap/pop3 in one activity/connection call. What about fields like a
> "signature" or background sync interval? Are passwords sent via this
> mechanism, or is it just basic server settings and maybe email account name?
> For something like APPAUTH/AAUTHTYPE, the email app does not support all the
> values in that list.

I'm going to look for someone helping us here.

> 
> For 3), I am sure it is just a matter of documenting what is supported, for
> the email app, but want to be sure the capabilities that are supported are
> well understood and agreed upon.
> 
> 4) Can we get some example messages that may be sent in the wild, to use for
> testing? This would help us create some tests that make sure we continue to
> keep the feature operational in the future.

I think we can ask about this.

Comment 24

[Salvador de la Puente González [:salva]]

Juwei Huang, could you assist us with the expected behavior of OMA provisioning for Email. Refer to comment 20 for the main concerns about this topic.

Comment 25

[Warren WU]

Attachment: example messages of OMA provisioning for Email

example messages of OMA provisioning for Email

Comment 26

[Juwei Huang[:juwei]]

Hi Salvador,
I am also confused about this requirement:(
Can you provide some example screen for it? It would be very helpful.
As James said, we need to know what part is configurable and what's the limitation for it so that we could have further discussion.

Comment 27

[Salvador de la Puente González [:salva]]

AFAIK, we need the Email application can be auto configured by an OMA provisioning message. The message contains the fields required to properly configure a user account. This is like manually configuring a IMAP/POP3/SMTP (see comment 16 for the specs) but auto instead of manual.

Asking Beatriz to confirm the explained behavior.

Comment 28

[Beatriz Rodríguez [:brg]]

Salva is right. The parameters that must be configured are covered in comment 16. In Comment 25 you have serveral examples of them. Thanks!

All these parameters will create a new user account, they will not modify any previous one configured.

Comment 29

[Salvador de la Puente González [:salva]]

In view of comment 28 but attending to some security issues I detected, I think an IAC broadcasting is not enough safe (when IAC will be available to privileged apps, what if a malicious APP steals the user account info?) so I want to suggest to show a notification from System when receiving such a configuration message, then, when tapping we could launch an activity which is a user required action. What do you think?

Comment 30

[James Burke [:jrburke]]

:salva, in general, I prefer the activation mechanism to email to be an activity, so that other pathways, like a support page for an email site, could help out the user by triggering the activity, so I like that approach in general.

I would still expect the email app to then also confirm with the user that they wanted to add that account, and the email app would only ever add new accounts, not modify existing ones.

For an activity, other apps could register for a chance to receive the activity, even a malicious one. However a user would get a chance to choose the app which receives the registration, which is perhaps the user required action that you mention.

So in general, I like the activity entry point into email.

Looking at the example messages in comment 25, some other thoughts:

* I am a bit concerned that the WAP config that gets pushed could be out of date in some cases. Like how we recently switched to oauth for gmail (in bug 1059100). In that case, we may want to favor our own determination of settings over what is received. Another example: the WAP Push message containing settings for unencrypted connections to servers where we know of a safer set of settings that work.

* In general, it bothers me to see user passwords passed through this mechanism. If the user mis-taps on the activity screen and selects the wrong app, that wrong app still gets a peek at the password.

* The XML format of the messages is not ideal given that a JSON-like structure usually used for activities.

In my ideal world, the flow would be:

* Email receives the WAP Push info as an activity. Ideally JS/JSON style data structure, with no password.
* If the email autoconfig logic has settings for ports/servers that are different for that email address domain, those are used instead of the WAP settings. Otherwise, email app uses the WAP Push settings.
* Email app prompts the user to enter their password to complete the configuration. That prompt could be an oauth hop to the email provider site, in the case of gmail.

Maybe there is not a way to avoid the XML. It can be consumed, so that is not a blocker, just would be nice to avoid it if we could, since I expect other possible activity triggers from places like a help site would just use a JSON/JS-type data structure.

Comment 31

[Salvador de la Puente González [:salva]]

(In reply to James Burke [:jrburke] from comment #30)
> :salva, in general, I prefer the activation mechanism to email to be an
> activity, so that other pathways, like a support page for an email site,
> could help out the user by triggering the activity, so I like that approach
> in general.
> 
> I would still expect the email app to then also confirm with the user that
> they wanted to add that account, and the email app would only ever add new
> accounts, not modify existing ones.
> 
> For an activity, other apps could register for a chance to receive the
> activity, even a malicious one. However a user would get a chance to choose
> the app which receives the registration, which is perhaps the user required
> action that you mention.

Correct.

> 
> So in general, I like the activity entry point into email.
> 
> Looking at the example messages in comment 25, some other thoughts:
> 
> * I am a bit concerned that the WAP config that gets pushed could be out of
> date in some cases. Like how we recently switched to oauth for gmail (in bug
> 1059100). In that case, we may want to favor our own determination of
> settings over what is received. Another example: the WAP Push message
> containing settings for unencrypted connections to servers where we know of
> a safer set of settings that work.

I'm thinking on having a system dialog before requesting the activity giving some information to the user. For instance, something like "This is an automatic configuration for an e-mail account. Notice the configuration includes sensible information about your e-mail account... Press continue to launch configuration."

When the user continues, system launches the activity and subscribed apps answer.

> 
> * In general, it bothers me to see user passwords passed through this
> mechanism. If the user mis-taps on the activity screen and selects the wrong
> app, that wrong app still gets a peek at the password.

In the system screen we could encourage to change the password. Moreover, if needed, we could force the system to show a special activity selection screen for just this case but I have not a ultimate solution for this case. Let's think a little bit more.

> 
> * The XML format of the messages is not ideal given that a JSON-like
> structure usually used for activities
> 
> In my ideal world, the flow would be:
> 
> * Email receives the WAP Push info as an activity. Ideally JS/JSON style
> data structure, with no password.
> * If the email autoconfig logic has settings for ports/servers that are
> different for that email address domain, those are used instead of the WAP
> settings. Otherwise, email app uses the WAP Push settings.
> * Email app prompts the user to enter their password to complete the
> configuration. That prompt could be an oauth hop to the email provider site,
> in the case of gmail.

Agree. It seems elaborated and it could be better to split the bug into several ones: one for system, others for e-mail apps.

> 
> Maybe there is not a way to avoid the XML. It can be consumed, so that is
> not a blocker, just would be nice to avoid it if we could, since I expect
> other possible activity triggers from places like a help site would just use
> a JSON/JS-type data structure.

System should act like an adapter translating XML into JSON, though, XML is the documented standard.

How should we proceed now?

ni to Beatriz to keep she up to date.

Comment 32

[James Burke [:jrburke]]

:salva - next steps seem to be to work out the system mechanism with the system team. It sounds like you have the most context for that. Once you work out that mechanism, we can then work out what the activity API would be, and on the email side, and contact Sri Kasetti (skasetti), the email product manager, to get this work prioritized appropriately for the email feature queue so we can get an email UX flow from the email UX team. 

I will give the productivity team a heads up about this feature so they have some context, but will leave it to you or Beatriz to engage Sri when you think things are ready to proceed.

Comment 33

[Beatriz Rodríguez [:brg]]

Sorry for my late response here. After checking it internally, we think this feature is not important in our target markets. Benefits won't fit our customer needs. However this is something that could be needed by someone else so leaving it open for future work.

Comment 34

[BMO Automation]

Firefox OS is not being worked on