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

[jr conlin <[e-mail]>]

There are some aspects of the published spec that are optional and seem
a bit "hand wavey"* (e.g. "subscription sets"), and 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.

Aside from those minor nits, I have no complaint with the draft as stands.

*The subscription set bits are an implementation detail that seems like
it's fairly vague compared to the detail that's provided for other parts
of the specification. I'm not terribly bothered by that, since how the
UA and PS handle exchange is probably going to be the most ignored
aspect of this specification. Various service providers will favor
existing channels over a new implementation.

On 5/30/2016 8:52 PM, Shida Schubert 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]
> https://www.ietf.org/mailman/listinfo/webpush