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

[Costin Manolache <[e-mail]>]

+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]>
wrote:

> 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
>>
>> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush
>