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

From: RUELLAN Herve <[email-masked]>
Date: Wed, 1 Jun 2016 11:49:02 +0000

I also shared some comments and sent some pull-requests. I think the draft is in a pretty good shape and none of my comments or suggestions are blocking for its advancement.

Thanks,

Hervé

From: Webpush [mailto:[email-masked]] On Behalf Of Peter Beverloo
Sent: mardi 31 mai 2016 21:43
To: Shida Schubert <[email-masked]>
Cc: [email-masked]
Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05

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

On Tue, May 31, 2016 at 4:52 AM, Shida Schubert <[email-masked]<mailto:[email-masked]>> wrote:
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]<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
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]<mailto:[email-masked]>> wrote:
Please see embedded comments: -

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

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.

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?

Anyway, I would very much appreciate it, if you can refrain the comments 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.

Thanks
Shida

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: -

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]<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.

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

_______________________________________________
Webpush mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webpush

_______________________________________________
Webpush mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webpush

_______________________________________________
Webpush mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webpush

_______________________________________________
Webpush mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webpush

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 Jun 2016 16:50:59 -0700

(off-list)

I think at this point it would be appropriate for me to send Richard a message off-list to ask him to refrain from unprofessional behavior on the list, per BCP 25. What do you think?

Thanks,
Alissa

> On May 31, 2016, at 6:36 PM, Richard Maher <[email-masked]> wrote:
> 
> 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] <mailto:[email-masked]>> wrote:
> 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] <mailto:[email-masked]>> wrote:
> 
> On May 31, 2016, at 12:01 PM, JR Conlin <[email-masked] <mailto:[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.
> 
> 
> 
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/webpush <https://www.ietf.org/mailman/listinfo/webpush>
> 
> 
> [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 Jun 2016 21:37:12 -0700

Whoops. Obviously this went to the list rather than off it, but Shida and I are now in touch about this.

Alissa

> On Jun 1, 2016, at 4:50 PM, Alissa Cooper <[email-masked]> wrote:
> 
> (off-list)
> 
>> On May 31, 2016, at 6:36 PM, Richard Maher <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Shida Schubert <[email-masked]>
Date: Mon, 6 Jun 2016 10:41:57 -0700

All;

The WGLC is concluding today but with the number of pull-requests, despite many of them being a non-blocker with some normative changes, I am going to run another WGLC (this time 2 weeks) once the 06 is available and all issues on github are resolved. 

Thanks to you all for providing the comments.

Shida as co-chair

> On Jun 1, 2016, at 4:49 AM, RUELLAN Herve <[email-masked]> wrote:
> 
> From: Webpush [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Peter Beverloo
> To: Shida Schubert <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Tue, May 31, 2016 at 4:52 AM, Shida Schubert <[email-masked] <mailto:[email-masked]>> wrote:
> All;
>  
> On May 24, 2016, at 11:11 AM, Costin Manolache <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 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;
>  
> 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>
>  
>  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> 
>  
> On May 16, 2016, at 6:50 PM, Richard Maher <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 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/>
>  
> 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>
>  
> On Tue, May 17, 2016 at 2:32 AM, Shida Schubert <[email-masked] <mailto:[email-masked]>> wrote:
> All;
>  
> https://tools.ietf.org/html/draft-ietf-webpush-protocol-05 <https://tools.ietf.org/html/draft-ietf-webpush-protocol-05>
>