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

[RUELLAN Herve <[e-mail]>]

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:[e-mail]] On Behalf Of Peter Beverloo
Sent: mardi 31 mai 2016 21:43
To: Shida Schubert <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:
Please see embedded comments: -

On Tue, May 24, 2016 at 8:03 AM, Shida Schubert <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/webpush

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


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


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