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

[Richard Maher <[e-mail]>]

Please see embedded comments: -

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