W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Progress on Push API

Date: Tue, 29 Apr 2014 09:00:15 +0000
To: public-webapps <public-webapps@w3.org>
Message-id: <A52BC7FE998B7E43BB74213DE5CD36906DAAA8C4@EX10-MB1-MAD.hi.inet>
Hi all,

Last week the Push API editors (AT&T, Telefónica) and other interested parties (Mozilla, Google) met to progress this specification. It was a very productive meeting in which great support was shown to this piece of work and consensus was reached around many topics under discussion. This is a summary of these points, which will be incorporated into a new editor's draft shortly. Of course feel free to provide any feedback:

- App Server - Push Server protocol: Mozilla and Google to kick-off a new draft at the IETF to standardize it.

- Change references to webapp => service worker where it might be unclear that only Service Workers should use interfaces & get events etc. other than register (because of the need for permissions UI), all interfaces and events to SW only

- Security and privacy considerations:  describe that user may revoke permissions through UA UI and this will not result in a PushError event to the Service Worker

- PushMessage Interface:
        - 'version' attribute to be dropped. Webapps do not need to get the version number. It can though be part of the wire protocol. The UA implementation should take care of 1- not conveying duplicated messages to the app, 2- informing the webapp whenever a push message is lost (e.g. detecting a gap in an incremental series of 'version').
        -'data' attribute is changed to be a DOMString

- PushManager Interface
        - to be renamed to PushRegistrationManager.  Navigator to expose: navigator.pushRegistrationManager
        - Promise register (optional Object registerOptions); => Promise register ();  registerOptions parameter is dropped, as long as Service Workers require secure connection; to prevent MITM (e.g. snooping of registration info over non-secure connection from webapp to webapp server), Push Registrations should operate only over secure connections thus the webapp and Service Workers code should be served via HTTPS URI scheme; otherwise registration will be rejected - take the text lead from Service Workers spec
        - A single registration is allowed per webapp
        - Promise registrations (); => Promise<boolean> isRegistered (); as a result of single registration allowed
        - Promise unregister (DOMString pushRegistrationId); => Promise unregister (); as a result of single registration allowed
             - Permission can be persistent: as granted by user permission does not have to be reconfirmed for subsequent registration requests if a valid permission exists
             - add new function: Promise<enumeration> hasPermission ();enumeration: Granted, Denied, Default (or NeedToAsk)
        - if there is a need to ask for permission it is done by directly invoking the register() method
        - add to steps that registration will fail if webapp scheme is not HTTPS

- PushRegistration Interface
              - Note that Endpoint may be common among multiple webapp instances running at multiple devices;
         - pushRegistrationId is expected to be unique and specific to a particular webapp instance running at a specific device;

- Push Events
        - PushRegisterMessage => PushError with 'reason' attribute (enumeration). Now it covers at least 2 type of errors: 1-new registration is needed (e.g. due to fatal error at server), 2- "out of sync" (due to dropping "version") will be informational and not imply registration has ended
             - add data processing to event steps

- Errors:
        - NoModificationAllowedError => NotFoundError
        - AbortError to be kept as is. Note about changing to PermissionDeniedError once it is included as a new DOMError (non-resolved bug exists)

- History API: does not apply to Service Workers. Note to be removed.



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
Received on Tuesday, 29 April 2014 09:00:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC