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

RE: Progress on Push API

Date: Mon, 05 May 2014 17:02:04 +0000
To: "arnaud.braud@orange.com" <arnaud.braud@orange.com>, public-webapps <public-webapps@w3.org>
Message-id: <A52BC7FE998B7E43BB74213DE5CD36906DAADA8C@EX10-MB1-MAD.hi.inet>
Hi Arnaud,

On 29 abr 2014 at 14:03:46, arnaud.braud@orange.com wrote:
> EDUARDO FULLEA CARRERA wrote on  App Server - Push Server protocol: Mozilla and Google to kick-off a:
> be available ?
>> - 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
> Doesn't this make push slightly harder to implement on "WebOS type" context ?
> It also mean we have a strong requirement on the service worker spec which is
> just starting.
>>         - 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
> This is going to require a lot of clarification I feel, the reason the options were
> added in the first place was to deal with the non standard underlying push
> services, for example to provide app authentification details from the browser
> to the push server (I think this was a requirement on the GCM ? ). I don't see
> how this modification addresses the issue and I don't see why https is
> mandatory either. U

Including non-standard parameters in the 'register' method found significant opposition as you may have seen in previous messages to this list. It seems Google can live without it (maybe they can explain themselves in more detail), so having into account it was their proposal originally, we can drop it.

> Could you provide an updated end to end workflow with who's credentials are
> used in the exchanges ?
> Thanks
> ________________________________________________________________
> _________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.


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 Monday, 5 May 2014 17:02:32 UTC

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