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

[Peter Beverloo <[e-mail]>]

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