805722 - WebSMS: support configurable SMS-STATUS-REPORT requisition

Status: RESOLVED INVALID

(Core :: DOM: Device Interfaces, defect)

Description

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

In order to be UI configurable, this should add a new Settings entry and controls whether should we enable TP-SR field in B2G RIL backend or insert deliveryIntents in Android backend.

Comment 1

[Mounir Lamouri (:mounir)]

Before going forward in B2G/Gonk/RIL there, I would prefer to see if we want this to be defined by the WebSMS specs or as a setting. In other words, in the WebSMS specification, we will have to say how to ask for delivery notifications and we should make sure if we want to have this defined via the WebSMS spec itself or mention the Settings spec.

My main concern in doing that in Settings is that we can hardly have this as an app option because right now, AFAIK, an app can't ask to set/get some specific settings, it has to set/get all of them which reduces the possibility of a user trusting the app.
I know that WebSMS is only allowed to certified apps right now but that situation will not be like that forever.

However, I think it is better to use the Settings API for that and more generally for most settings. If we can easily have APIs to rely on the settings API for some settings, it would make everyone's life easier. But to make that happen, we need the Settings API to have modular permissions. Jonas, what do you think?

Comment 2

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

This issue is NOT a requested feature yet. It's a common design in SMS API. I think we can postpone this issue until somebody is thirsty for it.

The status report requisition is simply a bit field on the outgoing SMS PDU. Android sets this bit if 1) SmsManager.send() is invoked with delivery intents, or 2) related system-wise shared preference is set to true. WebSMS Firefox OS backend always sets this bit to 1, and Android backend also always sets it to true because it always invokes SmsManager.send() with delivery intents.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Given that it doesn't sound like this is something we're planning on doing for v1 (which sounds good to me given that we're past feature freeze) I think we should postpone further discussion here.

In v2 we'll also have more possibilities available to us, possibly like being able to grant access to the settings API on a per-setting basis.