UCID: WAPPush-001 User Story: As an OEM, I want Firefox OS to support the receipt of WAP Push messages that conform to the WAP 1.2.1 Push Access Protocol so that a Firefox OS handset can integrate third party solutions that make use of WAP Push messaging easily.

Reference: Support WAP over SMS(bug 744360).

This is something that Doug may be interested in.

Clearing tracking-b2g18 flag from User Story bugs. This flag is for bugs that we would take fixes for in the 1.x branch. Feature work should be officially slotted into a release instead with leo+. If this story is intended for v1.1, please nominate for leo? blocking.

Peter: Can you describe how OEMs are expecting to use this feature? It seems nicer if we use a single push solution like the one developed in bug 822712. It shouldn't be a goal in and of itself to implement Wap Push just so that we conform to a specification. We should only do it if there is a technical need for it in applications that someone is planning on building.

Another reason we need to know this is that it will affect what type of API we build here. I.e. it's impossible to know if the API we design will meet OEM needs unless we know what those needs are.

Adding Daniel in CC as he might be able to provide some information about the need of WAP Push support.

For example, OMA CP (client provisioning) specs (bug 815554) needs WAP 1.2.1 Push Access Protocol support.

Recently I've done some discussion with jaoo, Laxman, and Vicamo. Followings are my conclusions: 1. We don't have to support all WAP Push types natively, but we have to notify receiving of unsupported types with raw data. For supported types, we *could* send notification containing content-type and corresponding data(might be a decoded XML string or an object parsed from XML string). For those we don't support, we *should* send notification containing content-type and raw data of message body. Client Provisioning looks like a special case, Vicamo suggests we can handle it in gecko and no notification is sent. But it might contains "VENDORCONFIG" field, I think at least we need to send notification if this field exists. 2. It would be good that an app can register message types to be notified, so it won't receive unnecessary notification. It seems that WebActivities might do the job, but I don't know if it can be triggered by gecko yet. 3. If we need to save WAP Push messages, we only save supported messages in XML string form. For unsupported message, leave it to app.

(In reply to Chuck Lee [:chucklee] from comment #8) > Recently I've done some discussion with jaoo, Laxman, and Vicamo. > Followings are my conclusions: > 1. We don't have to support all WAP Push types natively, but we have to > notify receiving of unsupported types with raw data. > For supported types, we *could* send notification containing content-type > and corresponding data(might be a decoded XML string or an object parsed > from XML string). > For those we don't support, we *should* send notification containing > content-type and raw data of message body. > Client Provisioning looks like a special case, Vicamo suggests we can > handle it in gecko and no notification is sent. But it might contains > "VENDORCONFIG" field, I think at least we need to send notification if this > field exists. This sounds good. I think it's fine to make all events be sent to the app in the raw binary form. I think it should be quite easy to for the app to convert to text using the TextDecoder API and then parse it to XML using the DOMParser API. Both of those APIs are already implemented. We should definitely not return Document objects from the API since that would mean that we could never make the API available to WebWorkers. And there's also a lot of tricky security issues when parsing XML into a DOM in C++. > 2. It would be good that an app can register message types to be notified, > so it won't receive unnecessary notification. > It seems that WebActivities might do the job, but I don't know if it can > be triggered by gecko yet. What you need here is system messages. You can trigger these from gecko. > 3. If we need to save WAP Push messages, we only save supported messages in > XML string form. > For unsupported message, leave it to app. I'd really like to avoid storing data in this API. Applications should be able to store that in IndexedDB and storing data in the API leads to all sorts of tricky performance issues.

(In reply to Jonas Sicking (:sicking) from comment #9) > (In reply to Chuck Lee [:chucklee] from comment #8) > > Recently I've done some discussion with jaoo, Laxman, and Vicamo. > > Followings are my conclusions: > > 1. We don't have to support all WAP Push types natively, but we have to > > notify receiving of unsupported types with raw data. > > For supported types, we *could* send notification containing content-type > > and corresponding data(might be a decoded XML string or an object parsed > > from XML string). > > For those we don't support, we *should* send notification containing > > content-type and raw data of message body. > > Client Provisioning looks like a special case, Vicamo suggests we can > > handle it in gecko and no notification is sent. But it might contains > > "VENDORCONFIG" field, I think at least we need to send notification if this > > field exists. > > This sounds good. I think it's fine to make all events be sent to the app in > the raw binary form. I think it should be quite easy to for the app to > convert to text using the TextDecoder API and then parse it to XML using the > DOMParser API. Both of those APIs are already implemented. > TextDecoder seems used to handle charset decoding, but raw message body in WAP Push is encoded in the form called WBXML. It basically replace XML tags and frequent used string(like "http://www.") with a number, and the tag-number mapping is different in each WAP Push type. I have implemented decoder for SI and SL in bug 853715, they decode WBXML into XML string. > We should definitely not return Document objects from the API since that > would mean that we could never make the API available to WebWorkers. And > there's also a lot of tricky security issues when parsing XML into a DOM in > C++. > > > 2. It would be good that an app can register message types to be notified, > > so it won't receive unnecessary notification. > > It seems that WebActivities might do the job, but I don't know if it can > > be triggered by gecko yet. > > What you need here is system messages. You can trigger these from gecko. As far as I know, we can't register a system message with a filter like activities. So we can't register "wap-push-received"(for example) and set a filter |{"content-type": ["text/vnd.wap.si", "application/vnd.wap.sic"]}| says "I only want to be notified on System Indication". Developer has to check content-type on every received notification. Unless we provide different system message for every WAP Push message type. Based on the supported type list[1], it's not very a good choice to me. Anyway, I consider this one as "good to have". [1] http://technical.openmobilealliance.org/tech/omna/omna-wsp-content-type.aspx > > > 3. If we need to save WAP Push messages, we only save supported messages in > > XML string form. > > For unsupported message, leave it to app. > > I'd really like to avoid storing data in this API. Applications should be > able to store that in IndexedDB and storing data in the API leads to all > sorts of tricky performance issues. This is still discussing in bug 838059, I also hope we don't have to save data in this API.

(In reply to Chuck Lee [:chucklee] from comment #10) > (In reply to Jonas Sicking (:sicking) from comment #9) > > (In reply to Chuck Lee [:chucklee] from comment #8) > > > Recently I've done some discussion with jaoo, Laxman, and Vicamo. > > > Followings are my conclusions: > > > 1. We don't have to support all WAP Push types natively, but we have to > > > notify receiving of unsupported types with raw data. > > > For supported types, we *could* send notification containing content-type > > > and corresponding data(might be a decoded XML string or an object parsed > > > from XML string). > > > For those we don't support, we *should* send notification containing > > > content-type and raw data of message body. > > > Client Provisioning looks like a special case, Vicamo suggests we can > > > handle it in gecko and no notification is sent. But it might contains > > > "VENDORCONFIG" field, I think at least we need to send notification if this > > > field exists. > > > > This sounds good. I think it's fine to make all events be sent to the app in > > the raw binary form. I think it should be quite easy to for the app to > > convert to text using the TextDecoder API and then parse it to XML using the > > DOMParser API. Both of those APIs are already implemented. > > > > TextDecoder seems used to handle charset decoding, but raw message body in > WAP Push is encoded in the form called WBXML. It basically replace XML tags > and frequent used string(like "http://www.") with a number, and the > tag-number mapping is different in each WAP Push type. > I have implemented decoder for SI and SL in bug 853715, they decode WBXML > into XML string. One option is to write a JS library for converting an ArrayBuffer containing the raw WBXML data into an XML string. But I'm also ok with with this being implemented in the API, but be careful to ensure that invalid WBXML data can't lead to buffer overflows or other scary things. > > We should definitely not return Document objects from the API since that > > would mean that we could never make the API available to WebWorkers. And > > there's also a lot of tricky security issues when parsing XML into a DOM in > > C++. > > > > > 2. It would be good that an app can register message types to be notified, > > > so it won't receive unnecessary notification. > > > It seems that WebActivities might do the job, but I don't know if it can > > > be triggered by gecko yet. > > > > What you need here is system messages. You can trigger these from gecko. > > As far as I know, we can't register a system message with a filter like > activities. > So we can't register "wap-push-received"(for example) and set a filter > |{"content-type": ["text/vnd.wap.si", "application/vnd.wap.sic"]}| says "I > only want to be notified on System Indication". > Developer has to check content-type on every received notification. > Unless we provide different system message for every WAP Push message type. > Based on the supported type list[1], it's not very a good choice to me. We could add an API like: navigator.setWAPListenerTypes(["text/vnd.wap.si", "application/vnd.wap.sic"]); Only when an application has registered to be notified for certain types do we fire the "wap-push-received" message to them. Applications can do this automatically once they are installed. There's a system message which allows applications to be automatically started upon when they are installed, but I forget the name of the message right now.

(In reply to Jonas Sicking (:sicking) from comment #11) > > Applications can do this automatically once they are installed. There's a > system message which allows applications to be automatically started upon > when they are installed, but I forget the name of the message right now. This will be the 'install-complete' system message. See bug 839058.

Updating the whiteboard to be consistent with other WAP Push stories in backlog

What are the acceptance criteria for this user story?

Acceptance criteria from PM: Device should be able to receive and process WAP Push messages

Test case URL is provided.

This feature is finished.

WAP push results will be updated on other WAP user stories. Currently device can receive WAP push message, other issues will be updated on each user story.