Subject: [Webpush] WGLC for draft-ietf-webpush-protocol-05

From: Shida Schubert <[email-masked]>
Date: Mon, 16 May 2016 11:32:51 -0700

All;

As discussed at the IETF 95, as last issue surrounding the subscription re-use is addressed, we are starting a Working Group Last Call for the webpush protocol. 

https://tools.ietf.org/html/draft-ietf-webpush-protocol-05 <https://tools.ietf.org/html/draft-ietf-webpush-protocol-05>

If you have any issues or questions regarding the draft please submit it to the list, when raising issues please provide constructive resolution when possible.

Please acknowledge on the list even when you are content/happy with the status of the draft. 

The Working Group Last Call will end on June 6th (3 weeks). 

Shida
As co-chair

---

From: Richard Maher <[email-masked]>
Date: Tue, 17 May 2016 09:50:13 +0800

"5.4 Updating Push Messages" is based on the misconception that "Topics"
are "Collapse Keys". The standard as proposed has been superseded by event
on the ground by established, successful, and more importantly scalable
solutions: -

Google Cloud Messaging: -
https://developers.google.com/cloud-messaging/topic-messaging

Azure Notification Hubs: -

https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifications-to-millions-of-devices-with-windows-azure-notification-hubs/

Whether the Topics are identified via HTTP headers or JSON Tokens is the
only moot point. What is clear is that the proposed protocol attempts to
conflate the Topic and Collapse Key features: -
https://developers.google.com/cloud-messaging/concept-options#collapsible_and_non-collapsible_messages

The fact that quintessential Push Notification feature "Broadcasting" has
been descoped from this protocol must be sufficient to reject the proposal.

Please do not make the same mistake that you made with Geofences. IETF and
W3C credibility has already suffered enough.

On Tue, May 17, 2016 at 2:32 AM, Shida Schubert <[email-masked]> wrote:

> All;
>
> As discussed at the IETF 95, as last issue surrounding the subscription
> re-use is addressed, we are starting a Working Group Last Call for the
> webpush protocol.
>
> https://tools.ietf.org/html/draft-ietf-webpush-protocol-05
>
> If you have any issues or questions regarding the draft please submit it
> to the list, when raising issues please provide constructive resolution
> when possible.
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>
>

---

From: Richard Maher <[email-masked]>
Date: Thu, 19 May 2016 14:20:20 +0800

Interesting developments: -

GCM has been rebranded to Firebase Cloud Messaging (FCM). FCM
<http://firebase.google.com/docs/cloud-messaging/> inherits the reliable
and scalable GCM infrastructure, plus new features! See the FAQ
<http://firebase.google.com/support/known-issues/#messaging-difference> to
learn more. If you are integrating messaging in a new app, start with FCM.
GCM users are strongly recommended to upgrade to FCM, in order to benefit
from new FCM features today and in the future.

FIREbase - Hell of a catchy name! What's Mozilla's Autopush called?

"Firebase the bullet-proof, scaleable, industrial-strength infrastructure
behind Firefox." I like it.

---

From: Shida Schubert <[email-masked]>
Date: Mon, 23 May 2016 17:03:32 -0700

Hi Richard;

Thank you for your feedback.

Currently developers need to either deal with different spec/api for each of the push notification providers (GCM, Azure, APN etc.) to communicate to their subscribers or use third party service (urban airship etc.), which is fine for native apps but gets a little more complicated with the browser. The IETF has agreed that we need a standardized protocol for this and that’s what we are chartered to work on. 

As for Broadcasting, from my shallow understanding isn’t it merely the same payload sent to set or all of subscribers? In which case, I believe it can be handled as an implementation matter likely at the application side. The protocol can be extended at later stage if wg agrees it is something that is necessary but I haven’t heard anybody else at the meeting or on the mailing list expressing this feature is a show-stopper.  

Anyway, I would very much appreciate it, if you can refrain the comments to the technical contents of the draft. 

Thanks
Shida

> On May 16, 2016, at 6:50 PM, Richard Maher <[email-masked]> wrote:
> 
> "5.4 Updating Push Messages" is based on the misconception that "Topics" are "Collapse Keys". The standard as proposed has been superseded by event on the ground by established, successful, and more importantly scalable solutions: -
> 
> https://developers.google.com/cloud-messaging/topic-messaging <https://developers.google.com/cloud-messaging/topic-messaging>
> 
>  https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifications-to-millions-of-devices-with-windows-azure-notification-hubs/ <https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifications-to-millions-of-devices-with-windows-azure-notification-hubs/>
> 
> Whether the Topics are identified via HTTP headers or JSON Tokens is the only moot point. What is clear is that the proposed protocol attempts to conflate the Topic and Collapse Key features: -
> https://developers.google.com/cloud-messaging/concept-options#collapsible_and_non-collapsible_messages <https://developers.google.com/cloud-messaging/concept-options#collapsible_and_non-collapsible_messages>
> 
> The fact that quintessential Push Notification feature "Broadcasting" has been descoped from this protocol must be sufficient to reject the proposal.
> 
> Please do not make the same mistake that you made with Geofences. IETF and W3C credibility has already suffered enough.
> 
> On Tue, May 17, 2016 at 2:32 AM, Shida Schubert <[email-masked] <mailto:[email-masked]>> wrote:
> All;
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/webpush <https://www.ietf.org/mailman/listinfo/webpush>
> 
>

---

From: Shida Schubert <[email-masked]>
Date: Mon, 23 May 2016 17:05:12 -0700

Hi Richard;

This has nothing to do with the subject. 

As mentioned in the other e-mail, please refrain your comments to the draft in subject. 

Thanks! 
Shida as co-chair

> On May 18, 2016, at 11:20 PM, Richard Maher <[email-masked]> wrote:
> 
> GCM has been rebranded to Firebase Cloud Messaging (FCM). FCM <http://firebase.google.com/docs/cloud-messaging/> inherits the reliable and scalable GCM infrastructure, plus new features! See the FAQ <http://firebase.google.com/support/known-issues/#messaging-difference> to learn more. If you are integrating messaging in a new app, start with FCM. GCM users are strongly recommended to upgrade to FCM, in order to benefit from new FCM features today and in the future.
> 
> "Firebase the bullet-proof, scaleable, industrial-strength infrastructure behind Firefox." I like it.
> 
> On Tue, May 17, 2016 at 9:50 AM, Richard Maher <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Richard Maher <[email-masked]>
Date: Tue, 24 May 2016 08:53:37 +0800

Please see embedded comments: -

On Tue, May 24, 2016 at 8:03 AM, Shida Schubert <[email-masked]> wrote:

> Currently developers need to either deal with different spec/api for each
> of the push notification providers (GCM, Azure, APN etc.) to communicate to
> their subscribers or use third party service (urban airship etc.), which is
> fine for native apps but gets a little more complicated with the browser.
>

Inconvenient but feature detection is not the end of the world.

> The IETF has agreed that we need a standardized protocol for this and
> that’s what we are chartered to work on.
>

A much better idea especially considering the number of Push Services that
don't happen to also manufacture a browser. But let's get it as
fit-for-purpose and as extensive as we can, eh? How many different
specifications have there been so far dealing with Server Push, Simple
Push, etc. Each time with developers having to deprecate and re-tool :-(

>
> As for Broadcasting, from my shallow understanding isn’t it merely the
> same payload sent to set or all of subscribers?
>

I find that level of naivety astounding in anyone who is involved in
formulation of this standard. Why do you seek to deliberately ignore the
client-based subscription feature where any and all client-to-topic mapping
is maintained solely by the Push Service and where the Application Server
is oblivious to consumers and freed the need for a local mapping database?
The Use-Cases are clear: - Sports results, Weather Updates, Stock Prices,
Security Alerts, just to name a few. The strategy for encrypting an
authenticating the payload/body is also clear(ish): -
https://github.com/slightlyoff/ServiceWorker/issues/901

Why do you people continue to say "What elephant?"

In which case, I believe it can be handled as an implementation matter
> likely at the application side.
>

 For some other use cases, managing subscriptions on the server is indeed
an option. Horses for courses: -

https://developers.google.com/cloud-messaging/topic-messaging#managing_topic_subscriptions_from_the_server

The protocol can be extended at later stage if wg agrees it is something
> that is necessary but I haven’t heard anybody else at the meeting or on the
> mailing list expressing this feature is a show-stopper.
>

I sorry to appear blunt but if the other members of the cloistered star
chamber that is adjudicating on this are equally ignorant of the business
requirements then there is no surprise they haven't come up with a solution.

But *please* don't listen to me. Just look at what solutions that are
already in the wild with native apps. Why won't you let HTML5 Web App
developers compete on an even playing field and create Apps that satisfy
these common requirements?

The MBONE people seem to have made progress over the years and we all know
that your Application Servers with simply be overwhelmed if you tickle
potentially millions of clients so let's get on with the solution?

> to the technical contents of the draft.

Are you telling me that pointing out omissions and scope deficiencies is
not welcomed?

Either way 5.4 is completely wrong. You've been told.

---

From: Costin Manolache <[email-masked]>
Date: Tue, 24 May 2016 18:11:13 +0000

+1 - we discussed my concerns on flow control for push promises, and I
think it's reasonable to have them addressed either
as part of http2 or as a separate document.

Other than that I think it's reasonable and stable base - extensions and
features can be added on top of it.

Costin

On Mon, May 23, 2016 at 5:53 PM Richard Maher <[email-masked]>
wrote:

>> Please do not make the same mistake that you made with Geofences. IETF
>> and W3C credibility has already suffered enough.
>>

---

From: Richard Maher <[email-masked]>
Date: Wed, 25 May 2016 15:04:06 +0800

For those who prefer to pain-by-numbers (see scalability): -
https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern

And, WRT the payload encryption options, maybe the following is the way to
go?
Defacto Javascript encryption standard?
https://github.com/bitwiseshiftleft/sjcl
C# and/or JAVA can encrypt and Javascrypt decrypt. A better solution?

---

From: Shida Schubert <[email-masked]>
Date: Mon, 30 May 2016 20:52:19 -0700

All;

We have heard very little regarding the actual contents of the draft and WGLC is over this week.

As noted when I started the last call, please show your support by providing acknowledgement(s) if you are happy with the draft as is. 

Thanks! 
Shida

> On May 24, 2016, at 11:11 AM, Costin Manolache <[email-masked]> wrote:
> 
> +1 - we discussed my concerns on flow control for push promises, and I think it's reasonable to have them addressed either 
> Other than that I think it's reasonable and stable base - extensions and features can be added on top of it.
> 
> Costin
> 
> 
> On Mon, May 23, 2016 at 5:53 PM Richard Maher <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, May 24, 2016 at 8:03 AM, Shida Schubert <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Richard;
> 
> Currently developers need to either deal with different spec/api for each of the push notification providers (GCM, Azure, APN etc.) to communicate to their subscribers or use third party service (urban airship etc.), which is fine for native apps but gets a little more complicated with the browser.
> 
> The IETF has agreed that we need a standardized protocol for this and that’s what we are chartered to work on. 
> 
> A much better idea especially considering the number of Push Services that don't happen to also manufacture a browser. But let's get it as fit-for-purpose and as extensive as we can, eh? How many different specifications have there been so far dealing with Server Push, Simple Push, etc. Each time with developers having to deprecate and re-tool :-(
>  
> 
> As for Broadcasting, from my shallow understanding isn’t it merely the same payload sent to set or all of subscribers?
> 
> I find that level of naivety astounding in anyone who is involved in formulation of this standard. Why do you seek to deliberately ignore the client-based subscription feature where any and all client-to-topic mapping is maintained solely by the Push Service and where the Application Server is oblivious to consumers and freed the need for a local mapping database? The Use-Cases are clear: - Sports results, Weather Updates, Stock Prices, Security Alerts, just to name a few. The strategy for encrypting an authenticating the payload/body is also clear(ish): - https://github.com/slightlyoff/ServiceWorker/issues/901 <https://github.com/slightlyoff/ServiceWorker/issues/901>
> 
> In which case, I believe it can be handled as an implementation matter likely at the application side.
> 
>  For some other use cases, managing subscriptions on the server is indeed an option. Horses for courses: -
>  https://developers.google.com/cloud-messaging/topic-messaging#managing_topic_subscriptions_from_the_server <https://developers.google.com/cloud-messaging/topic-messaging#managing_topic_subscriptions_from_the_server> 
> 
> The protocol can be extended at later stage if wg agrees it is something that is necessary but I haven’t heard anybody else at the meeting or on the mailing list expressing this feature is a show-stopper.  
> 
> I sorry to appear blunt but if the other members of the cloistered star chamber that is adjudicating on this are equally ignorant of the business requirements then there is no surprise they haven't come up with a solution.
> 
> But *please* don't listen to me. Just look at what solutions that are already in the wild with native apps. Why won't you let HTML5 Web App developers compete on an even playing field and create Apps that satisfy these common requirements?
> 
> The MBONE people seem to have made progress over the years and we all know that your Application Servers with simply be overwhelmed if you tickle potentially millions of clients so let's get on with the solution? 
>  
> 
> Are you telling me that pointing out omissions and scope deficiencies is not welcomed?
> 
>> On May 16, 2016, at 6:50 PM, Richard Maher <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Richard Maher <[email-masked]>
Date: Tue, 31 May 2016 14:58:10 +0800

Please also take the time to make submissions to the European Commission on
the lack of plug-n-play specification with WebPush facilitating the abuse
of monopoly positions by respective browser manufacturers to suppress
competition from third party Push Notification Services.

I've attached my submission to this case: -
http://ec.europa.eu/competition/elojade/isef/case_details.cfm?proc_code=1_40099

Each browser user must be unencumbered in their choice of Cloud Service
Provider(s) as they are for browsers, and search engines.

On Tue, May 31, 2016 at 11:52 AM, Shida Schubert <[email-masked]> wrote:

> As noted when I started the last call, please show your support by
> providing acknowledgement(s) if you are happy with the draft as is.
>
> Thanks!
> Shida
>
>>> Currently developers need to either deal with different spec/api for
>>> each of the push notification providers (GCM, Azure, APN etc.) to
>>> communicate to their subscribers or use third party service (urban airship
>>> etc.), which is fine for native apps but gets a little more complicated
>>> with the browser.
>>>
>>
>> A much better idea especially considering the number of Push Services
>> that don't happen to also manufacture a browser. But let's get it as
>> The MBONE people seem to have made progress over the years and we all
>> know that your Application Servers with simply be overwhelmed if you tickle
>>> The fact that quintessential Push Notification feature "Broadcasting"
>>> has been descoped from this protocol must be sufficient to reject the
>>> proposal.
>>>
>>>> If you have any issues or questions regarding the draft please submit
>>>> it to the list, when raising issues please provide constructive resolution
>>>> when possible.
>>>>

---

From: jr conlin <[email-masked]>
Date: Tue, 31 May 2016 12:00:58 -0700

There are some aspects of the published spec that are optional and seem
a bit "hand wavey"* (e.g. "subscription sets"), and I believe that the
recommendation for expired or removed push subscription endpoints was to
return 410, not 404 (see section 7.3). I note that 7.3.1 suggests 410
for expired subscription sets, so it might help if things were consistent.

Aside from those minor nits, I have no complaint with the draft as stands.

*The subscription set bits are an implementation detail that seems like
it's fairly vague compared to the detail that's provided for other parts
of the specification. I'm not terribly bothered by that, since how the
UA and PS handle exchange is probably going to be the most ignored
aspect of this specification. Various service providers will favor
existing channels over a new implementation.

On 5/30/2016 8:52 PM, Shida Schubert wrote:
>> On May 24, 2016, at 11:11 AM, Costin Manolache <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> +1 - we discussed my concerns on flow control for push promises, and
>> I think it's reasonable to have them addressed either 
>>         Currently developers need to either deal with different
>>         spec/api for each of the push notification providers (GCM,
>>         Azure, APN etc.) to communicate to their subscribers or use
>>         third party service (urban airship etc.), which is fine for
>>         native apps but gets a little more complicated with the browser.
>>
>>
>>         The IETF has agreed that we need a standardized protocol for
>>         this and that’s what we are chartered to work on. 
>>
>>
>>     A much better idea especially considering the number of Push
>>     Services that don't happen to also manufacture a browser. But
>>     let's get it as fit-for-purpose and as extensive as we can, eh?
>>     How many different specifications have there been so far dealing
>>     with Server Push, Simple Push, etc. Each time with developers
>>     having to deprecate and re-tool :-(
>>      
>>
>>
>>         As for Broadcasting, from my shallow understanding isn’t it
>>         merely the same payload sent to set or all of subscribers?
>>
>>
>>     I find that level of naivety astounding in anyone who is involved
>>     in formulation of this standard. Why do you seek to deliberately
>>     ignore the client-based subscription feature where any and all
>>     client-to-topic mapping is maintained solely by the Push Service
>>     and where the Application Server is oblivious to consumers and
>>     freed the need for a local mapping database? The Use-Cases are
>>     clear: - Sports results, Weather Updates, Stock Prices, Security
>>     Alerts, just to name a few. The strategy for encrypting an
>>     authenticating the payload/body is also clear(ish):
>>     - https://github.com/slightlyoff/ServiceWorker/issues/901
>>
>>         In which case, I believe it can be handled as an
>>         implementation matter likely at the application side.
>>
>>
>>      For some other use cases, managing subscriptions on the server
>>     is indeed an option. Horses for courses: -
>>         The protocol can be extended at later stage if wg agrees it
>>         is something that is necessary but I haven’t heard anybody
>>         else at the meeting or on the mailing list expressing this
>>         feature is a show-stopper.  
>>
>>
>>     I sorry to appear blunt but if the other members of the
>>     cloistered star chamber that is adjudicating on this are equally
>>     ignorant of the business requirements then there is no surprise
>>     they haven't come up with a solution.
>>
>>     But *please* don't listen to me. Just look at what solutions that
>>     are already in the wild with native apps. Why won't you let HTML5
>>     Web App developers compete on an even playing field and create
>>     Apps that satisfy these common requirements?
>>
>>     The MBONE people seem to have made progress over the years and we
>>     all know that your Application Servers with simply be overwhelmed
>>     if you tickle potentially millions of clients so let's get on
>>     with the solution? 
>>      
>>
>>
>>         Anyway, I would very much appreciate it, if you can refrain
>>         the comments to the technical contents of the draft. 
>>
>>
>>>         On May 16, 2016, at 6:50 PM, Richard Maher
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>         "5.4 Updating Push Messages" is based on the misconception
>>>         that "Topics" are "Collapse Keys". The standard as proposed
>>>         has been superseded by event on the ground by established,
>>>         successful, and more importantly scalable solutions: -
>>>
>>>         Whether the Topics are identified via HTTP headers or JSON
>>>         Tokens is the only moot point. What is clear is that the
>>>         proposed protocol attempts to conflate the Topic and
>>>         Collapse Key features: -
>>>         The fact that quintessential Push Notification feature
>>>         "Broadcasting" has been descoped from this protocol must be
>>>         sufficient to reject the proposal.
>>>
>>>         Please do not make the same mistake that you made with
>>>         Geofences. IETF and W3C credibility has already suffered enough.
>>>
>>>         On Tue, May 17, 2016 at 2:32 AM, Shida Schubert
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             All;
>>>
>>>             As discussed at the IETF 95, as last issue surrounding
>>>             the subscription re-use is addressed, we are starting a
>>>             Working Group Last Call for the webpush protocol. 
>>>
>>>             If you have any issues or questions regarding the draft
>>>             please submit it to the list, when raising issues please
>>>             provide constructive resolution when possible.
>>>
>>>             Please acknowledge on the list even when you are
>>>             content/happy with the status of the draft. 
>>>

---

From: Peter Beverloo <[email-masked]>
Date: Tue, 31 May 2016 20:42:30 +0100

I have just shared some comments, but none of them are significant enough
to defer WGLC.

As such, I can definitely support the draft as-is.

Thanks,
Peter

---

From: Brian Raymor <[email-masked]>
Date: Tue, 31 May 2016 23:25:46 +0000

On May 31, 2016, at 12:01 PM, JR Conlin <[email-masked]> wrote:

Thanks for your feedback.

> There are some aspects of the published spec that are optional and seem a bit "hand wavey"* (e.g. "subscription sets")

How do you feel this could be improved? What details are missing from your perspective?

> I believe that the recommendation for expired or removed push subscription endpoints was to return 410, not 404 (see section 7.3). I note that 7.3.1 suggests 410 for expired subscription sets, so it might help if things were consistent. 

Good catch.
7.3.1 should be 404 and not 410.
410 (Gone) is returned when a push service decides to cease delivery attempts before the TTL expires.
404 (Not Found) is returned when a push services expires a subscription or set.

---

From: JR Conlin <[email-masked]>
Date: Tue, 31 May 2016 16:50:39 -0700

I noted my opinion in the follow up. Basically, while the spec goes into
great detail about other aspects of the protocol, sets are left mostly as
"they may exist", and "it's up to the PS and UA".  I will also admit that I
was initially confused because I hadn't noticed it was only between UA and
PS, but a second read caught that.

I am fine as is, because I don't think that outside groups will be impacted
by my concern, nor do I believe that they would fail to implement a
solution if they misunderstood it.
On May 31, 2016 4:25 PM, "Brian Raymor" <[email-masked]> wrote:

> a bit "hand wavey"* (e.g. "subscription sets")
>
> > I believe that the recommendation for expired or removed push
> subscription endpoints was to return 410, not 404 (see section 7.3). I note
> that 7.3.1 suggests 410 for expired subscription sets, so it might help if
> things were consistent.
>
> Good catch.

---

From: Richard Maher <[email-masked]>
Date: Wed, 1 Jun 2016 09:36:22 +0800

So with the WGLC drawing to a close, I make that a whole 3 people,
excluding the authors, with anything positive to say about this draft
standard. Does that not tell you something? Or is "3" what passes for
quorum with you people?

Do you lot get paid per specification? Number of pages? Or do you actually
get tasked with delivering a spec that industry-standard, feature-rich, and
scalable solutions can be built upon? Or perhaps "Just describe whatever
Autopush does"?

Disbelief.

On Wed, Jun 1, 2016 at 7:50 AM, JR Conlin <[email-masked]> wrote:

> I am fine as is, because I don't think that outside groups will be
> impacted by my concern, nor do I believe that they would fail to implement
> a solution if they misunderstood it.