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.
Regards,
Eduardo.
________________________________
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:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
