Please consider carefully that user agents effectively requiring a single push service may introduce concerns related to privacy and security, as well as internationalisation given the realistic scenario that a "standard" service may be unavailable regionally. The asserted design trade-off is against efficiency for power consumption.

It would be helpful to understand whether the TAG supports this sort of design, and what should be taken into account in determining the trade-off between power consumption and user privacy and security.

Comments from f2f: no explainer...

Thanks for looking at this. Do you think comments by 31st July might be possible?

@LJWatson we are looking at this now.

I tend to pick a lot of nits and couldn't find any to pick.

Overall we have no substantive feedback, and the API looks great. On the push service relationship with the browser:

• We acknowledge the need that browsers and OSes have expressed in minimizing the number of background wake-ups which have a detrimental effect on battery life. This concern has led to nearly all mobile OSes minimizing the number and diversity of push backends. Allowing sites to select their own services would make it difficult to mediate this delicate balance.
• If the user is to be offered a choice of push services (and we note there's nothing in the spec to preclude this), the choice must be made a meaningful one, and we are not sure how this might be achieved, or indeed whether it is possible.
• We note that the provision of an effective, usable push service is an area in which browsers can compete, and therefore there is an incentive for the service to be well maintained.