RE: Progress on Push API

[EDUARDO FULLEA CARRERA]

Hi Arnaud,

On 29 abr 2014 at 14:03:46, arnaud.br...@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:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Re: Progress on Push API

[Jonas Sicking]

On Fri, May 2, 2014 at 9:11 AM, John Mellor  wrote:
> I was trying to make the point that events letting the webapp know it needs
> to re-register should go to the Service Worker, so the webapp can
> re-register whether or not it happens to be currently open

Ah, this is a very good point indeed. I think that renders my proposal moot.

I'll have another look at this once there are drafts that reflect the
latest API proposal.

/ Jonas

Re: Progress on Push API

[John Mellor]

Domenic wrote:
> this doesn't allow notification that you need to re-register

I was trying to make the point that events letting the webapp know it needs
to re-register should go to the Service Worker, so the webapp can
re-register whether or not it happens to be currently open. Since the app
might not be open at all, Promise-based APIs don't work, as Promises can
only persist as long as their JS context stays alive, hence PushError being
an event delivered to the SW.

> be sure to only use rejections for exceptional situations [2]. It wasn't
clear in your message, John, but you seemed to be proposing that
isRegistered() reject when not registered?

No, I was saying that isRegistered would resolve the promise with true or
false, except if the UA for some reason couldn't determine whether the
webapp had registered yet, in which case it would reject the promise. But
perhaps a) UAs can always determine this, or b) in such cases it would be
better to just wait until the UA becomes able to determine this, in either
of which cases some kind of registrationRequired promise would be easier to
use.


On 2 May 2014 16:17, Domenic Denicola  wrote:

> Regarding promise idiomaticness, the two proposals I've seen that look
> most reasonable would be:
>
> - isRegistered() + register(). But, this doesn't allow notification that
> you need to re-register, from what I can tell.
> - A variant on registrationNeeded, where---since it can return a different
> promise each time---it becomes a method, named e.g.
> waitForRegistrationNeeded() or whenRegistrationNeeded().
>
> The former is a very typical async-function-call use of promises. The
> latter is the notification-of-state-transition use of promises [1], which
> is a bit less typical, but is often convenient---especially, as Jonas
> notes, when you would want to find out even after the fact.
>
> Also, be sure to only use rejections for exceptional situations [2]. It
> wasn't clear in your message, John, but you seemed to be proposing that
> isRegistered() reject when not registered? That would be a promise
> antipattern, akin to a synchronous function called isRegistered() throwing
> an exception to signal non-registration.
>
> [1]: https://github.com/w3ctag/promises-guide/issues/25
> [2]:
> https://github.com/w3ctag/promises-guide#rejections-should-be-used-for-exceptional-situations
>

RE: Progress on Push API

[Domenic Denicola]

Regarding promise idiomaticness, the two proposals I've seen that look most 
reasonable would be:

- isRegistered() + register(). But, this doesn't allow notification that you 
need to re-register, from what I can tell.
- A variant on registrationNeeded, where---since it can return a different 
promise each time---it becomes a method, named e.g. waitForRegistrationNeeded() 
or whenRegistrationNeeded().

The former is a very typical async-function-call use of promises. The latter is 
the notification-of-state-transition use of promises [1], which is a bit less 
typical, but is often convenient---especially, as Jonas notes, when you would 
want to find out even after the fact.

Also, be sure to only use rejections for exceptional situations [2]. It wasn't 
clear in your message, John, but you seemed to be proposing that isRegistered() 
reject when not registered? That would be a promise antipattern, akin to a 
synchronous function called isRegistered() throwing an exception to signal 
non-registration.

[1]: https://github.com/w3ctag/promises-guide/issues/25
[2]: 
https://github.com/w3ctag/promises-guide#rejections-should-be-used-for-exceptional-situations

Re: Progress on Push API

[John Mellor]

Jonas wrote:
> One thing that I think would help the API would be to unify the
> "initial registration" flow and the "you need to reregister since the
> push server has lost track of your registration" flow. I.e. having a
> single API which lets the page check "do I need to register now".

Actually, the isRegistered method that Eduardo mentioned was intended to
behave this way, i.e. you would do:

// page onload handler
navigator.push.isRegistered().then(registered => {
if (!registered)
navigator.push.register().then(endpoint =>
sendToAppServer(endpoint));
});

Though I agree that registrationRequired would neatly save a little
boilerplate by removing the if(!registered) check*.

The PushError event meanwhile was intended to be delivered only to the
Service Worker not to web pages, and when the reason code indicates a fatal
error at the server requiring re-registration, it would give your webapp a
chance to re-register in the background (from the Service Worker) without
having to wait until the user next launches your webapp (or course it would
also work if your web page is still open).

In order for this to be possible, navigator.push.register (and friends)
needs to be exposed to Service Workers, but when used in the background it
would typically always reject unless hasPermission() == "granted" (since
UAs can typically only show permissions UI in the foreground).

Cheers,
John

*: (FWIW, isRegistered() in theory had a tri-state return value, where if
the promise got rejected instead of returning true/false it would have
meant that the UA doesn't know, perhaps because it can only check whilst
online or something - but in practice I suspect most UAs will cache
registrations locally, so perhaps we can just drop that state).


On 2 May 2014 06:18, Martin Thomson  wrote:

> On 1 May 2014 17:31, Jonas Sicking  wrote:
> >> If it's going to happen over and over, why not an event?
> >>
> >> function register() {
> >>   navigator.push.register().then(endpoint => sendToAppServer(endpoint));
> >> }
> >> navigator.push.onderegister = e => register;
> >
> > For two reasons:
> >
> > * If the page does some initialization asynchronously then it might
> > miss that the "deregister" event fires. I.e. it is very easy to
> > accidentally register the onderegister event handler "too late".
> > * It would require that we for each page that the user visits check if
> > that page has a registration, and if that registration has been lost
> > by the server. We only want to do this on pages that care about push
> > registration and is actually going to make a registration if needed.
> > Not for every page the user visits.
>
> Fair points, but with a an event coupled to a state (attribute boolean
> registered), this can be avoided.  I guess that the point of your
> second proposal at least is that it sort of rolls all that into the
> one package.
>
> I think that I prefer the "registration needed callback" approach,
> even though it seems to be a little surprising in the sense that it
> shares many characteristics with events.  Maybe a onregistrationneeded
> event would be a closer fit.
>
>

Re: Progress on Push API

[Martin Thomson]

On 1 May 2014 17:31, Jonas Sicking  wrote:
>> If it's going to happen over and over, why not an event?
>>
>> function register() {
>>   navigator.push.register().then(endpoint => sendToAppServer(endpoint));
>> }
>> navigator.push.onderegister = e => register;
>
> For two reasons:
>
> * If the page does some initialization asynchronously then it might
> miss that the "deregister" event fires. I.e. it is very easy to
> accidentally register the onderegister event handler "too late".
> * It would require that we for each page that the user visits check if
> that page has a registration, and if that registration has been lost
> by the server. We only want to do this on pages that care about push
> registration and is actually going to make a registration if needed.
> Not for every page the user visits.

Fair points, but with a an event coupled to a state (attribute boolean
registered), this can be avoided.  I guess that the point of your
second proposal at least is that it sort of rolls all that into the
one package.

I think that I prefer the "registration needed callback" approach,
even though it seems to be a little surprising in the sense that it
shares many characteristics with events.  Maybe a onregistrationneeded
event would be a closer fit.

Re: Progress on Push API

[Jonas Sicking]

On Thu, May 1, 2014 at 5:26 PM, Martin Thomson  wrote:
> On 1 May 2014 16:55, Jonas Sicking  wrote:
>> function registrationHandler() {
>>   navigator.push.register().then((endpoint) => {
>>sendBackToAppServer(endpoint);
>>navigator.push.registrationNeeded.then(registrationHandler);
>>   }
>> }
>> navigator.push.registrationNeeded.then(registrationHandler);
>
> If it's going to happen over and over, why not an event?
>
> function register() {
>   navigator.push.register().then(endpoint => sendToAppServer(endpoint));
> }
> navigator.push.onderegister = e => register;

For two reasons:

* If the page does some initialization asynchronously then it might
miss that the "deregister" event fires. I.e. it is very easy to
accidentally register the onderegister event handler "too late".
* It would require that we for each page that the user visits check if
that page has a registration, and if that registration has been lost
by the server. We only want to do this on pages that care about push
registration and is actually going to make a registration if needed.
Not for every page the user visits.

/ Jonas

Re: Progress on Push API

[Martin Thomson]

On 1 May 2014 16:55, Jonas Sicking  wrote:
> function registrationHandler() {
>   navigator.push.register().then((endpoint) => {
>sendBackToAppServer(endpoint);
>navigator.push.registrationNeeded.then(registrationHandler);
>   }
> }
> navigator.push.registrationNeeded.then(registrationHandler);

If it's going to happen over and over, why not an event?

function register() {
  navigator.push.register().then(endpoint => sendToAppServer(endpoint));
}
navigator.push.onderegister = e => register;

Of course, you would have to set some expectations around how quickly
the browser is required to detect this error.  30 minutes is a pretty
common liveness interval for these things, which might not meet the
usual timeliness expectations for applications.

Re: Progress on Push API

[Jonas Sicking]

I'll give it a shot to define an outline here.

The problem that we're trying to solve is to let a webpage know when
it needs to register for push notifications. This happens either when
the page never has registered, or if the push server lost track of the
registration that was previously done.

Proposal A
One approach to this would be something like this:

interface PushManager {
  ...
  readonly attribute Promise registrationNeeded;
}

The returned promise would be resolved as soon as the UA determines
that this website never has done a registration, or that the
registration that was done was lost by the server.

The resulting code would look something like

navigator.push.registrationNeeded.then(() => {
  return navigator.push.register();
}).then(endpoint => {
  sendBackToAppServer(endpoint);
});

However ideally the page should also handle the server loosing the
registration multiple times during even the lifetime of a single page.
We could handle this by having the attribute return a new Promise any
time registration happens. This new promise would get resolved if
reregistration is needed. This gets a little messier with this
approach.

function registrationHandler() {
  navigator.push.register().then((endpoint) => {
   sendBackToAppServer(endpoint);
   navigator.push.registrationNeeded.then(registrationHandler);
  }
}
navigator.push.registrationNeeded.then(registrationHandler);


Another option is something like this:

interface PushManager {
  ...
  registrationRequired(callback);
}

The callback would get called any time that (re-)registration is needed.

navigator.push.registrationRequired(() => {
  navigator.push.register().then((endpoint) => {
sendBackToAppServer(endpoint);
  });
});

We could even simplify the flow even more by combining the
registrationRequired and register() functions into something like
this:

navigator.push.registrationRequired((endpoint) => {
  sendBackToAppServer(endpoint);
});

In this case (re-)registration happens automatically. If
registrationRequired is called when a registration already exists,
then it does nothing. But if no registration has been done, or if/when
the server looses the existing registration, the callback is called.

If we go with an API like this, we'd likely need to enable forcefully
re-registering in case the app has lost track of the registration.
Something like this could work but is pretty ugly.

navigator.push.registrationRequired((endpoint) => {
  sendBackToAppServer(endpoint);
}, { forceReregister: true });

/ Jonas

On Wed, Apr 30, 2014 at 12:25 AM, EDUARDO FULLEA CARRERA  wrote:
> On 30 abr 2014 at 00:13:14, Jonas Sicking wrote:
>> On Tue, Apr 29, 2014 at 2:00 AM, EDUARDO FULLEA CARRERA 
>> wrote:
>>> 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:
>>
>
> We developing the new version at [1], though not yet updated with the changes 
> in my previous email.
>
> But if may be a good idea to migrate is to the W3C GitHub official repo. What 
> is the process to open the project there? Can anyone help?
>
> Thanks.
> Eduardo.
>
> [1] https://github.com/telefonicaid/WebAPISpecs/tree/develop/Push
>
> 
>
> 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

Re: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[Mounir Lamouri]

On Thu, 1 May 2014, at 21:38, Arthur Barstow wrote:
> On 4/30/14 1:19 PM, Mounir Lamouri wrote:
> > On Thu, 1 May 2014, at 1:50, EDUARDO FULLEA CARRERA wrote:
> >> On 30 abr 2014 at 16:52:49, Arthur Barstow wrote:
> >>> On 4/30/14 10:44 AM, Arthur Barstow wrote:
>  I'll work with Mike/Robin to create a new "push-api" project, unless
>  you request otherwise. OK?
> >>> Eduardo - Mike created this project .
> >> Thanks! Once we deal with open pull requests in current repo will migrate
> >> to the new one.
> >> A question, who has permission to accept pull requests? At least the
> >> editors should have.
> > I believe this will be the WebApps team including Marcos and I for the
> > moment:
> > https://github.com/orgs/w3c/teams/webapps
> 
> Cindy - it appears Mounir is asking to create a new "WebApps" team i.e. 
>  and to include him (I don't 
> know Mounir's GH uname), Marcos (marcosc), Eudardo (efullea) and Bryan 
> (blsaws).  Mounir - is this correct?

Not exactly. There is already a WebApps team with Marcos and I. Eduardo
and Bryan might need to be added.

-- Mounir

Re: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[Arthur Barstow]

On 4/30/14 1:19 PM, Mounir Lamouri wrote:

On Thu, 1 May 2014, at 1:50, EDUARDO FULLEA CARRERA wrote:

On 30 abr 2014 at 16:52:49, Arthur Barstow wrote:

On 4/30/14 10:44 AM, Arthur Barstow wrote:

I'll work with Mike/Robin to create a new "push-api" project, unless
you request otherwise. OK?

Eduardo - Mike created this project .

Thanks! Once we deal with open pull requests in current repo will migrate
to the new one.
A question, who has permission to accept pull requests? At least the
editors should have.

I believe this will be the WebApps team including Marcos and I for the
moment:
https://github.com/orgs/w3c/teams/webapps


Cindy - it appears Mounir is asking to create a new "WebApps" team i.e. 
 and to include him (I don't 
know Mounir's GH uname), Marcos (marcosc), Eudardo (efullea) and Bryan 
(blsaws).  Mounir - is this correct?


-Thanks, AB

Re: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[Mounir Lamouri]

On Thu, 1 May 2014, at 1:50, EDUARDO FULLEA CARRERA wrote:
> On 30 abr 2014 at 16:52:49, Arthur Barstow wrote:
> > On 4/30/14 10:44 AM, Arthur Barstow wrote:
> >> I'll work with Mike/Robin to create a new "push-api" project, unless
> >> you request otherwise. OK?
> >
> > Eduardo - Mike created this project .
> 
> Thanks! Once we deal with open pull requests in current repo will migrate
> to the new one.
> A question, who has permission to accept pull requests? At least the
> editors should have.

I believe this will be the WebApps team including Marcos and I for the
moment:
https://github.com/orgs/w3c/teams/webapps

-- Mounir

RE: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[EDUARDO FULLEA CARRERA]

On 30 abr 2014 at 16:52:49, Arthur Barstow wrote:
> On 4/30/14 10:44 AM, Arthur Barstow wrote:
>> I'll work with Mike/Robin to create a new "push-api" project, unless
>> you request otherwise. OK?
>
> Eduardo - Mike created this project .

Thanks! Once we deal with open pull requests in current repo will migrate to 
the new one.
A question, who has permission to accept pull requests? At least the editors 
should have.



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

Re: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[Arthur Barstow]

On 4/30/14 10:44 AM, Arthur Barstow wrote:
I'll work with Mike/Robin to create a new "push-api" project, unless 
you request otherwise. OK?


Eduardo - Mike created this project .

[admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[Arthur Barstow]

On 4/30/14 3:25 AM, EDUARDO FULLEA CARRERA wrote:

We developing the new version at [1], though not yet updated with the changes 
in my previous email.

But if may be a good idea to migrate is to the W3C GitHub official repo.


Hi Eduardo,

WebApps already has a few specs using github.org/W3C so the Push API can 
be added.



What is the process to open the project there? Can anyone help?


I'll work with Mike/Robin to create a new "push-api" project, unless you 
request otherwise. OK?


-Thanks, ArtB

RE: Progress on Push API

[EDUARDO FULLEA CARRERA]

On 30 abr 2014 at 00:13:14, Jonas Sicking wrote:
> On Tue, Apr 29, 2014 at 2:00 AM, EDUARDO FULLEA CARRERA 
> wrote:
>> 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:
>

We developing the new version at [1], though not yet updated with the changes 
in my previous email.

But if may be a good idea to migrate is to the W3C GitHub official repo. What 
is the process to open the project there? Can anyone help?

Thanks.
Eduardo.

[1] https://github.com/telefonicaid/WebAPISpecs/tree/develop/Push



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

Re: Progress on Push API

[Jonas Sicking]

On Tue, Apr 29, 2014 at 2:00 AM, EDUARDO FULLEA CARRERA  wrote:
> 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:

Is the new API proposal drafts up anywhere as a complete API? Rather
than the "delta description" that's in this email?

One thing that I think would help the API would be to unify the
"initial registration" flow and the "you need to reregister since the
push server has lost track of your registration" flow. I.e. having a
single API which lets the page check "do I need to register now".

This would only be a syntax change on the API side, and wouldn't
affect the communication between the device and the push server at
all. The goal would be to make "push server has lost your
registration" less of a special-case, and make it more likely that
people handle it correctly.

/ Jonas

Re: Progress on Push API

[Charles McCathie Nevile]

On Tue, 29 Apr 2014 16:02:43 +0200, EDUARDO FULLEA CARRERA   
wrote:



Hi Chaals, all,


Hi,

It was not intended to be an official W3C meeting, but just an informal  
discussion to feed the official standardization track, which AFAIK this  
mailing list is part of.


Right. But the boundaries are difficult to define. If you invite more  
people than the editors to a discussion that isn't archived on this list  
(or a specific list for your spec, where relevant), then I strongly  
recommend that you make it "a formal WG meeting".


As you know, that doesn't actually have to be very formal. Basically, you  
have to tell people where and when it is happening, and give enough notice  
to meet the process requirements. Ideally there would be minutes, or at  
least a rationale along with any proposals.



As you may note my previous email was not imposing any agreement to the
group but just proposing a set of changes and asking from feedback from
other parties.


Understood - and that is a general part of how the group works: The  
requirement that decisions are made asynchronously, rather than imposed  
from some meeting where people may not be able to attend.



But sorry if my email has led to any misunderstanding.


No, it hasn't led to a misunderstanding, it shows that we (the chairs, but  
probably everyone) seem to have some misunderstanding in the group about  
meetings. As you know, this group tries to avoid having meetings unless  
they are for some purpose - but when we do have a purpose, we should be  
clear and hold a real meeting. And we do work to make that as simple and  
efficient as possible.


Again, I am pleased that you are making progress. That's the real reason  
we are here. But part of the chairs' job is to make sure we follow the  
"fairness" procedures of W3C. Another part of our job is to make that as  
simple as possible for everyone so it becomes the easiest and obvious way  
to do things.


cheers

Chaals


Regards,
Eduardo.

On 29 abr 2014 at 15:42:40, Charles McCathie Nevile wrote:

Hi Eduardo, all,

On Tue, 29 Apr 2014 11:00:15 +0200, EDUARDO FULLEA CARRERA 
wrote:


Hi all,

Last week the Push API editors (AT&T, Telefónica) and other interested
parties (Mozilla, Google) met to progress this specification.


Just a gentle reminder that if you are having a meeting there needs to  
be
an announcement of it. I don't want to stop people doing work -  
obviously,
we encourage that happening and applaud members who take initiative to  
get

things done.

But there is a process requirement, that you and your employer agreed to
when joining the group. It isn't just a quid pro quo for the rest of us
agreeing to go through a PAG if necessary. It is also based on an
important legal requirement that standards be developed according to a
fair process, to avoid being construed as engaging in anti-competitive  
or

cartel behaviour.

And of course it is good manners.

As a quick reminder, the general notice times required are 1 week for a
"distributed" telephone meeting (unless it is a regularly scheduled
meeting) and 8 weeks for a physical meeting.

If you want to organise a meeting for a particular topic the chairs and
staff contacts will be very happy to help, both to make sure we meet the
process requirements and with any necessary logistics. The notice period
is the only one likely to have any real impact, and there is a way to
approve shorter notice if it is really necessary.

But I would ask people who want to organise a get-together that they
provide the notice required by the Process, to ensure that "interested
parties" in the working group have a fair opportunity to attend.

cheers

Chaals





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



--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

RE: Progress on Push API

[EDUARDO FULLEA CARRERA]

Hi Chaals, all,

It was not intended to be an official W3C meeting, but just an informal 
discussion to feed the official standardization track, which AFAIK this mailing 
list is part of. As you may note my previous email was not imposing any 
agreement to the group but just proposing a set of changes and asking from 
feedback from other parties. But sorry if my email has led to any 
misunderstanding.

Regards,
Eduardo.

On 29 abr 2014 at 15:42:40, Charles McCathie Nevile wrote:
> Hi Eduardo, all,
>
> On Tue, 29 Apr 2014 11:00:15 +0200, EDUARDO FULLEA CARRERA 
> wrote:
>
>> Hi all,
>>
>> Last week the Push API editors (AT&T, Telefónica) and other interested
>> parties (Mozilla, Google) met to progress this specification.
>
> Just a gentle reminder that if you are having a meeting there needs to be
> an announcement of it. I don't want to stop people doing work - obviously,
> we encourage that happening and applaud members who take initiative to get
> things done.
>
> But there is a process requirement, that you and your employer agreed to
> when joining the group. It isn't just a quid pro quo for the rest of us
> agreeing to go through a PAG if necessary. It is also based on an
> important legal requirement that standards be developed according to a
> fair process, to avoid being construed as engaging in anti-competitive or
> cartel behaviour.
>
> And of course it is good manners.
>
> As a quick reminder, the general notice times required are 1 week for a
> "distributed" telephone meeting (unless it is a regularly scheduled
> meeting) and 8 weeks for a physical meeting.
>
> If you want to organise a meeting for a particular topic the chairs and
> staff contacts will be very happy to help, both to make sure we meet the
> process requirements and with any necessary logistics. The notice period
> is the only one likely to have any real impact, and there is a way to
> approve shorter notice if it is really necessary.
>
> But I would ask people who want to organise a get-together that they
> provide the notice required by the Process, to ensure that "interested
> parties" in the working group have a fair opportunity to attend.
>
> cheers
>
> Chaals
>



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

Re: Progress on Push API

[Charles McCathie Nevile]

Hi Eduardo, all,

On Tue, 29 Apr 2014 11:00:15 +0200, EDUARDO FULLEA CARRERA   
wrote:



Hi all,

Last week the Push API editors (AT&T, Telefónica) and other interested  
parties (Mozilla, Google) met to progress this specification.


Just a gentle reminder that if you are having a meeting there needs to be  
an announcement of it. I don't want to stop people doing work - obviously,  
we encourage that happening and applaud members who take initiative to get  
things done.


But there is a process requirement, that you and your employer agreed to  
when joining the group. It isn't just a quid pro quo for the rest of us  
agreeing to go through a PAG if necessary. It is also based on an  
important legal requirement that standards be developed according to a  
fair process, to avoid being construed as engaging in anti-competitive or  
cartel behaviour.


And of course it is good manners.

As a quick reminder, the general notice times required are 1 week for a  
"distributed" telephone meeting (unless it is a regularly scheduled  
meeting) and 8 weeks for a physical meeting.


If you want to organise a meeting for a particular topic the chairs and  
staff contacts will be very happy to help, both to make sure we meet the  
process requirements and with any necessary logistics. The notice period  
is the only one likely to have any real impact, and there is a way to  
approve shorter notice if it is really necessary.


But I would ask people who want to organise a get-together that they  
provide the notice required by the Process, to ensure that "interested  
parties" in the working group have a fair opportunity to attend.


cheers

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: Progress on Push API

[Anne van Kesteren]

On Tue, Apr 29, 2014 at 2:04 PM, Anne van Kesteren  wrote:
> On Tue, Apr 29, 2014 at 1:32 PM, Peter Beverloo  wrote:
>> It would still require another synchronous operation, which is unwanted for
>> browsers using multiple processes. Chrome uses a synchronous IPC message for
>> getting the notification permission (it is not known at renderer startup),
>> and I would strongly prefer if we can avoid adding others.
>
> Interesting. Maybe we should put a use counter on
> Notification.permission then. Somewhat sad that nobody raised this
> earlier.

Oh, and if you care about this you should probably give feedback to
DNT as they have an API… o_O


-- 
http://annevankesteren.nl/

Re: Progress on Push API

[Anne van Kesteren]

On Tue, Apr 29, 2014 at 1:32 PM, Peter Beverloo  wrote:
> On Tue, Apr 29, 2014 at 1:23 PM, Anne van Kesteren  wrote:
>> Well yes, the question is why the application cares about garbage on
>> the push server. How would it handle the return value of unregister()
>> other than simply ignoring it?
>
> Since we only allow a single registration, register() would simply return
> the current registration at least until unregister() has succeeded. A
> scenario in which the developer might want to renew the registrations is
> where their database was compromised.

We could also make unregister(); register() work. That actually seems
better and more likely to lead to success. It does make for a slightly
more complicated register() as it has to check an unregister() invoked
flag, but that's not too bad.


> It would still require another synchronous operation, which is unwanted for
> browsers using multiple processes. Chrome uses a synchronous IPC message for
> getting the notification permission (it is not known at renderer startup),
> and I would strongly prefer if we can avoid adding others.

Interesting. Maybe we should put a use counter on
Notification.permission then. Somewhat sad that nobody raised this
earlier.


-- 
http://annevankesteren.nl/

Re: Progress on Push API

[Peter Beverloo]

On Tue, Apr 29, 2014 at 1:23 PM, Anne van Kesteren  wrote:

> On Tue, Apr 29, 2014 at 1:17 PM, Peter Beverloo 
> wrote:
> > Dropping a push registration has two aspects to it: (1) removing the
> mapping
> > between registration Id and the Service Worker to deliver it to on the
> > browser side, and (2) removing the registration on the push service. This
> > way we can communicate whether that has succeeded, and the registration
> Id
> > known to the site's application server has been invalidated.
> >
> > That said, an alternative would be to say that the UA would do a best
> effort
> > to drop the registration at the earliest option (e.g. when the user is
> > offline), allowing the developer to assume it succeeded.
>
> Well yes, the question is why the application cares about garbage on
> the push server. How would it handle the return value of unregister()
> other than simply ignoring it?
>

Since we only allow a single registration, register() would simply return
the current registration at least until unregister() has succeeded. A
scenario in which the developer might want to *renew* the registrations is
where their database was compromised.

>> > Promise hasPermission ();enumeration: Granted, Denied,
> >> > Default (or NeedToAsk)
> >>
> >> I think this can be synchronous and done similarly to
> >> http://notifications.spec.whatwg.org/#permission
> >
> > Checking whether the site has permission to use feature X is an
> asynchronous
> > operation in many browsers. In fact, I'd prefer if the Notification
> > specification would be updated to replace the permission property with a
> > hasPermission method as well.
>
> I think that ship has sailed. And setting an additional bit per origin
> does not seem too bad.
>

It would still require another synchronous operation, which is unwanted for
browsers using multiple processes. Chrome uses a synchronous IPC message
for getting the notification permission (it is not known at renderer
startup), and I would strongly prefer if we can avoid adding others.

Peter

--
> http://annevankesteren.nl/
>

Re: Progress on Push API

[Anne van Kesteren]

On Tue, Apr 29, 2014 at 1:17 PM, Peter Beverloo  wrote:
> Dropping a push registration has two aspects to it: (1) removing the mapping
> between registration Id and the Service Worker to deliver it to on the
> browser side, and (2) removing the registration on the push service. This
> way we can communicate whether that has succeeded, and the registration Id
> known to the site's application server has been invalidated.
>
> That said, an alternative would be to say that the UA would do a best effort
> to drop the registration at the earliest option (e.g. when the user is
> offline), allowing the developer to assume it succeeded.

Well yes, the question is why the application cares about garbage on
the push server. How would it handle the return value of unregister()
other than simply ignoring it?


>> > Promise hasPermission ();enumeration: Granted, Denied,
>> > Default (or NeedToAsk)
>>
>> I think this can be synchronous and done similarly to
>> http://notifications.spec.whatwg.org/#permission
>
> Checking whether the site has permission to use feature X is an asynchronous
> operation in many browsers. In fact, I'd prefer if the Notification
> specification would be updated to replace the permission property with a
> hasPermission method as well.

I think that ship has sailed. And setting an additional bit per origin
does not seem too bad.


-- 
http://annevankesteren.nl/

Re: Progress on Push API

[Peter Beverloo]

Thank you for these notes, Eduardo!

On Tue, Apr 29, 2014 at 11:21 AM, Anne van Kesteren wrote:

> On Tue, Apr 29, 2014 at 10:00 AM, EDUARDO FULLEA CARRERA 
> wrote:
> > Promise unregister (); as a result of single registration allowed
>
> Why does this have a return value?
>

Dropping a push registration has two aspects to it: (1) removing the
mapping between registration Id and the Service Worker to deliver it to on
the browser side, and (2) removing the registration on the push service.
This way we can communicate whether that has succeeded, and the
registration Id known to the site's application server has been invalidated.

That said, an alternative would be to say that the UA would do a best
effort to drop the registration at the earliest option (e.g. when the user
is offline), allowing the developer to assume it succeeded.

> Promise hasPermission ();enumeration: Granted, Denied,
> Default (or NeedToAsk)
>
> I think this can be synchronous and done similarly to
> http://notifications.spec.whatwg.org/#permission


Checking whether the site has permission to use feature X is an
asynchronous operation in many browsers. In fact, I'd prefer if the
Notification specification would be updated to replace the permission
property with a hasPermission method as well.

Thanks,
Peter


> > a new DOMError
>
> DOMError is dead, use DOMException.
>
>
> --
> http://annevankesteren.nl/
>
>

RE: Progress on Push API

[arnaud.braud]

> -Message d'origine-
> De : EDUARDO FULLEA CARRERA [mailto:e...@tid.es]

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

Great, do we know where they plan to do this work ? and when a first draft will 
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

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.

Re: Progress on Push API

[Anne van Kesteren]

On Tue, Apr 29, 2014 at 10:00 AM, EDUARDO FULLEA CARRERA  wrote:
> Promise unregister (); as a result of single registration allowed

Why does this have a return value?


> Promise hasPermission ();enumeration: Granted, Denied, Default 
> (or NeedToAsk)

I think this can be synchronous and done similarly to
http://notifications.spec.whatwg.org/#permission


> a new DOMError

DOMError is dead, use DOMException.


-- 
http://annevankesteren.nl/