From nobody Sun May 8 16:35:38 2016 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E326712B02E; Sun, 8 May 2016 16:35:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160508233534.17476.72583.idtracker@ietfa.amsl.com> Date: Sun, 08 May 2016 16:35:34 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-05.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 23:35:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web-Based Push Notifications of the IETF. Title : Generic Event Delivery Using HTTP Push Authors : Martin Thomson Elio Damaggio Brian Raymor Filename : draft-ietf-webpush-protocol-05.txt Pages : 31 Date : 2016-05-08 Abstract: A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-webpush-protocol-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 10 21:39:37 2016 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB1012D0AE; Tue, 10 May 2016 21:39:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511043935.400.92286.idtracker@ietfa.amsl.com> Date: Tue, 10 May 2016 21:39:35 -0700 Archived-At: Cc: shida@ntt-at.com, webpush-chairs@ietf.org, alissa@cooperw.in, webpush@ietf.org Subject: [Webpush] webpush - New Meeting Session Request for IETF 96 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 04:39:36 -0000 A new meeting session request has just been submitted by Shida Schubert, a Chair of the webpush working group. --------------------------------------------------------- Working Group Name: Web-Based Push Notifications Area Name: Applications and Real-Time Area Session Requester: Shida Schubert Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: httpbis, rtcweb, dispatch, mmusic, tls Second Priority: capport, modern, sipcore, ice, stir Special Requests: --------------------------------------------------------- From nobody Wed May 11 20:49:49 2016 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD50612D0AD; Wed, 11 May 2016 20:49:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160512034947.15264.48314.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 20:49:47 -0700 Archived-At: Cc: shida@ntt-at.com, webpush-chairs@ietf.org, alissa@cooperw.in, webpush@ietf.org Subject: [Webpush] webpush - Update to a Meeting Session Request for IETF 96 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 03:49:48 -0000 An update to a meeting session request has just been submitted by Shida Schubert, a Chair of the webpush working group. --------------------------------------------------------- Working Group Name: Web-Based Push Notifications Area Name: Applications and Real-Time Area Session Requester: Shida Schubert Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: httpbis rtcweb dispatch mmusic tls core Second Priority: capport modern sipcore ice stir Special Requests: --------------------------------------------------------- From nobody Mon May 16 11:33:02 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8586312D922 for ; Mon, 16 May 2016 11:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9UH-soMJM5o for ; Mon, 16 May 2016 11:32:58 -0700 (PDT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.150.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E4812D917 for ; Mon, 16 May 2016 11:32:56 -0700 (PDT) Received: from cm3.websitewelcome.com (unknown [108.167.139.23]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 064409E4F3BA5 for ; Mon, 16 May 2016 13:32:56 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm3.websitewelcome.com with id v6Yt1s00x3AKFgo016Yubu; Mon, 16 May 2016 13:32:56 -0500 Received: from [38.104.224.174] (port=53761 helo=[10.1.0.182]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b2NK1-000VyD-IB for webpush@ietf.org; Mon, 16 May 2016 13:32:53 -0500 From: Shida Schubert Content-Type: multipart/alternative; boundary="Apple-Mail=_D6713C99-B2E5-43A6-8ED0-935C89378D74" Message-Id: Date: Mon, 16 May 2016 11:32:51 -0700 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 38.104.224.174 X-Exim-ID: 1b2NK1-000VyD-IB X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.1.0.182]) [38.104.224.174]:53761 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 18:33:01 -0000 --Apple-Mail=_D6713C99-B2E5-43A6-8ED0-935C89378D74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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.=20 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.=20 The Working Group Last Call will end on June 6th (3 weeks).=20 Shida As co-chair= --Apple-Mail=_D6713C99-B2E5-43A6-8ED0-935C89378D74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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<= /div>

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
= --Apple-Mail=_D6713C99-B2E5-43A6-8ED0-935C89378D74-- From nobody Mon May 16 18:50:21 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4865D12DB43 for ; Mon, 16 May 2016 18:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bgtl2D3Ky9iy for ; Mon, 16 May 2016 18:50:14 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C98D12DB41 for ; Mon, 16 May 2016 18:50:14 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id w36so1056359qge.3 for ; Mon, 16 May 2016 18:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GMzKqfUUXf05IkcoAtbpbUxK+yBl4EGZVt4ovZ3n6dQ=; b=z6jgl/GVcN64aaFBKI9VmCYEWOpaNA1TlarwtmYXM11xgF3OmZ+hRnuH6ixWMDq3aF CN6SwSUst2rnqvPg4jcT1WNQGayU12sG2drhJWqUleDE8WRBp2v6uxbUqFanQwvOgQPU fNAmHpaJ6FPJzHRxwSPzn3HctkHkWbkiE33SRU0ZhQe0UuksFcXZFTuvhNrUPnpMEQch Y3rR6zcT2U9B7TlmrMBw1SudvxPrFXWCBYehLtw0G1jGhfWLkmsxm7hFu6/X6W1Slsxy 1MXOdhUGk+AOd7BTtq+DNsBgr50hc7FS5u/RcFzgWAqTpKZWt9O4Rg+Lk3+6HngqBd50 hIZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GMzKqfUUXf05IkcoAtbpbUxK+yBl4EGZVt4ovZ3n6dQ=; b=dE+26/+ermpv6CmfFNfZ6jfzF+1yC9ZtHs2TNIi0Tsl9pog0YGkEQA4E8BlljXGcMv Rh8XM/IOk5bwhpyvx3c3RZX+mB43Dxoon8enujqbVfj2a1s9eVWfsvrqdnyO72UzrL6p BSh5S8SjoPyHgqkirhf2UA5LvZyB0KgOtCCYRNyQnRodAZAOAAyubCW+ZDriUzHR0Y7x jWOV04w1XhcyzX5e797LwHqvISaVb2mwgDGly9T4xTM/xuVwtSCDxjD4+mD+3XwlpF9M Mx/rPG+7u+zfvl3iAkPuQmuItBI8okskIGiT2s/um0yoF8uuCVsYNL9Xm2rC98+LjSRg z5og== X-Gm-Message-State: AOPr4FUMvu9x9q1hYNa87LgZKvTl9jiR4azHMsIbfFWE9OnkGvXQVemYGFjH/EIwCBSkP8ZKRxpbTTKnOgjzBQ== MIME-Version: 1.0 X-Received: by 10.140.134.134 with SMTP id 128mr20787073qhg.63.1463449813610; Mon, 16 May 2016 18:50:13 -0700 (PDT) Received: by 10.55.104.194 with HTTP; Mon, 16 May 2016 18:50:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 May 2016 09:50:13 +0800 Message-ID: From: Richard Maher To: Shida Schubert Content-Type: multipart/alternative; boundary=001a1136f988497b6c0532fff6c6 Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 01:50:21 -0000 --001a1136f988497b6c0532fff6c6 Content-Type: text/plain; charset=UTF-8 "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 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 > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a1136f988497b6c0532fff6c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"5.4 Updating Push Messages" is based on the mis= conception that "Topics" are "Collapse Keys". The stand= ard as proposed has been superseded by event on the ground by established, = successful, and more importantly scalable solutions: -

G= oogle Cloud Messaging: -

Azure Notification Hubs: = -

Whether the Topics are identified = via HTTP headers or JSON Tokens is the only moot point. What is clear is th= at the proposed protocol attempts to conflate the Topic and Collapse Key fe= atures: -

The fact that quintessential = Push Notification feature "Broadcasting" has been descoped from t= his protocol must be sufficient to reject the proposal.

Please do not make the same mistake that you made with Geofences. IET= F and W3C credibility has already suffered enough.

On Tue, May 17, 2016 at 2:32 A= M, Shida Schubert <shida@ntt-at.com> wrote:
All;
As discussed at the IETF 95, as last issue surrounding the sub= scription re-use is addressed, we are starting a Working Group Last Call fo= r the webpush protocol.=C2=A0


If you have any issues or questions regarding the draft please submi= t it to the list, when raising issues please provide constructive resolutio= n when possible.

Please acknowledge on the list ev= en when you are content/happy with the status of the draft.=C2=A0

The Working Group Last Call will end on June 6th (3 weeks).= =C2=A0

Shida
As co-chair

= _______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--001a1136f988497b6c0532fff6c6-- From nobody Wed May 18 23:20:25 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9512D0BB for ; Wed, 18 May 2016 23:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZboIqX697sj for ; Wed, 18 May 2016 23:20:21 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A7512B04D for ; Wed, 18 May 2016 23:20:21 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id 90so38291878qgz.1 for ; Wed, 18 May 2016 23:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=G3pUcrnc4IIijPOr3hhTUutK3gNiXmO6+FJJppW4D7Y=; b=ifAKERokrcAkO6JwAuMDb2jT9DvMAheAx4zosYHOowR1rjHqDTnKe+IA/Q9aKvRJnJ +ThruDl09T1WAppDNQKr5PobPHvhiqPGlGRRP55bXvRtVTnR7JSqqXCkFDSDPqNoD8F7 eHQ1OcvhBvSYOO7rKmk6uKnGteqFDTQ26AIquTId8NhDJCYxoleH/HMAAFTcSK+N2feh 7g3EfGvO+xuFFZJzZSEnlBKE3qPpUDBvHWMzIE1A82FGpIelbWsXh8z+p6GVXJCWenxq FCInCH9OAxkWcpxMqRypSDPUOjST+NznzlRiKdFofm2c6GfkBZaT5F7PkdxCvvv0uFb/ qcLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=G3pUcrnc4IIijPOr3hhTUutK3gNiXmO6+FJJppW4D7Y=; b=YCkDKmE2YEzLl3pIYzkTf4Nvt/eHhrfb+giy53WXXV8rK94LEuGKWaGBD0po5NF0mW rs7ubKiOuaaxfwuctkJ0b8yDOIAt/bIRpo9xU0tMsq8yvD/9Xai8akXoPDi15qbri1j6 U6TZIWm7K06im6ViFs6kK3v5CHA7s/+Q6LsLXiw64YESh5YH+F8QyKlwvA0shHMSuFjL qGM2iIEefI8n7odRb4bxY375f4G/ZH5tEbiMjfwp9eWve10UatvNdqK6YRxOt26Jg/fp W8F/pu7k9IcQn2k+ocSu+GReF62WVakIZOEuCvp3FtHwnqVllYHfj2yoL0qjrTGdTZyS 9h6Q== X-Gm-Message-State: AOPr4FUYx4CwIHrfynZjrnE9Pea/FznsHWOXHE6GAmNxr2a2TkPjcz+PfWPQgJO3GD692SXClz+Mlpgf8KaKnw== MIME-Version: 1.0 X-Received: by 10.140.89.202 with SMTP id v68mr11548109qgd.95.1463638820232; Wed, 18 May 2016 23:20:20 -0700 (PDT) Received: by 10.55.104.194 with HTTP; Wed, 18 May 2016 23:20:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 May 2016 14:20:20 +0800 Message-ID: From: Richard Maher To: Shida Schubert Content-Type: multipart/alternative; boundary=001a11c1182ef5a8b905332bf78d Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 06:20:23 -0000 --001a11c1182ef5a8b905332bf78d Content-Type: text/plain; charset=UTF-8 Interesting developments: - GCM has been rebranded to Firebase Cloud Messaging (FCM). FCM inherits the reliable and scalable GCM infrastructure, plus new features! See the FAQ to learn more. If you are integrating messaging in a new app, start with FCM. GCM users are strongly recommended to upgrade to FCM, in order to benefit from new FCM features today and in the future. FIREbase - Hell of a catchy name! What's Mozilla's Autopush called? "Firebase the bullet-proof, scaleable, industrial-strength infrastructure behind Firefox." I like it. On Tue, May 17, 2016 at 9:50 AM, Richard Maher 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 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 >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> > --001a11c1182ef5a8b905332bf78d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting developments: -

GCM has been rebranded to Fir= ebase Cloud Messaging (FCM).=C2=A0FCM=C2=A0inherits the reliable and scalable GCM infrastructure= , plus new features! See the=C2=A0FAQ=C2=A0to learn more. If you are integr= ating messaging in a new app, start with FCM. GCM users are strongly recomm= ended to upgrade to FCM, in order to benefit from new FCM features today an= d in the future.

FIREbase - = Hell of a catchy name! What's Mozilla's Autopush called?

"Firebase t= he bullet-proof, scaleable, industrial-strength infrastructure behind Firef= ox." I like it.

On Tue, May 17, 2016 at 9:50 AM, Richard Maher &= lt;maherrj@goog= lemail.com> wrote:
"5.4 Updating Push Messages" is based on the misconcepti= on that "Topics" are "Collapse Keys". The standard as p= roposed has been superseded by event on the ground by established, successf= ul, and more importantly scalable solutions: -

Google Cl= oud Messaging: -

Azure Notificat= ion Hubs: -

Whethe= r the Topics are identified via HTTP headers or JSON Tokens is the only moo= t point. What is clear is that the proposed protocol attempts to conflate t= he Topic and Collapse Key features: -

The fact that quintessential Push Notification feature &qu= ot;Broadcasting" has been descoped from this protocol must be sufficie= nt to reject the proposal.

Please do not make the = same mistake that you made with Geofences. IETF and W3C credibility has alr= eady suffered enough.

On Tue, May 17, 2016 at 2:32 AM, Sh= ida Schubert <shida@ntt-at.com> wrote:
All;

As discussed at the IETF 95, as = last issue surrounding the subscription re-use is addressed, we are startin= g a Working Group Last Call for the webpush protocol.=C2=A0

<= /div>

If you have any issues or questions re= garding the draft please submit it to the list, when raising issues please = provide constructive resolution when possible.

Ple= ase acknowledge on the list even when you are content/happy with the status= of the draft.=C2=A0

The Working Group Last Call w= ill end on June 6th (3 weeks).=C2=A0

Shida
As co-chair

_________________________________= ______________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush



--001a11c1182ef5a8b905332bf78d-- From nobody Mon May 23 17:03:42 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46B012D52E for ; Mon, 23 May 2016 17:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ENPbCLSCui9 for ; Mon, 23 May 2016 17:03:37 -0700 (PDT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.148.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64EF12D566 for ; Mon, 23 May 2016 17:03:37 -0700 (PDT) Received: from cm3.websitewelcome.com (unknown [108.167.139.23]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 2153EABD08269 for ; Mon, 23 May 2016 19:03:37 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm3.websitewelcome.com with id y03b1s0083AKFgo0103cqZ; Mon, 23 May 2016 19:03:37 -0500 Received: from c-98-248-153-86.hsd1.ca.comcast.net ([98.248.153.86]:39322 helo=[10.0.96.17]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b4zos-000Ps6-MY; Mon, 23 May 2016 19:03:34 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_709EB948-9453-49F3-A34E-ADD0B97CCA78" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shida Schubert In-Reply-To: Date: Mon, 23 May 2016 17:03:32 -0700 Message-Id: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> References: To: Richard Maher X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 98.248.153.86 X-Exim-ID: 1b4zos-000Ps6-MY X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-98-248-153-86.hsd1.ca.comcast.net ([10.0.96.17]) [98.248.153.86]:39322 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 00:03:40 -0000 --Apple-Mail=_709EB948-9453-49F3-A34E-ADD0B97CCA78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. The IETF has agreed that we need a = standardized protocol for this and that=E2=80=99s what we are chartered = to work on.=20 As for Broadcasting, from my shallow understanding isn=E2=80=99t it = merely the same payload sent to set or all of subscribers? In which = case, I believe it can be handled as an implementation matter likely at = the application side. The protocol can be extended at later stage if wg = agrees it is something that is necessary but I haven=E2=80=99t heard = anybody else at the meeting or on the mailing list expressing this = feature is a show-stopper. =20 Anyway, I would very much appreciate it, if you can refrain the comments = to the technical contents of the draft.=20 Thanks Shida > On May 16, 2016, at 6:50 PM, Richard Maher = wrote: >=20 > "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: - >=20 > Google Cloud Messaging: - > https://developers.google.com/cloud-messaging/topic-messaging = >=20 > Azure Notification Hubs: - > = https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifica= tions-to-millions-of-devices-with-windows-azure-notification-hubs/ = >=20 > 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 = >=20 > The fact that quintessential Push Notification feature "Broadcasting" = has been descoped from this protocol must be sufficient to reject the = proposal. >=20 > Please do not make the same mistake that you made with Geofences. IETF = and W3C credibility has already suffered enough. >=20 > On Tue, May 17, 2016 at 2:32 AM, Shida Schubert > wrote: > All; >=20 > 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.=20 >=20 > https://tools.ietf.org/html/draft-ietf-webpush-protocol-05 = >=20 > 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. >=20 > Please acknowledge on the list even when you are content/happy with = the status of the draft.=20 >=20 > The Working Group Last Call will end on June 6th (3 weeks).=20 >=20 > Shida > As co-chair >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --Apple-Mail=_709EB948-9453-49F3-A34E-ADD0B97CCA78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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. The IETF has agreed that we need a = standardized protocol for this and that=E2=80=99s what we are chartered = to work on. 

As for Broadcasting, from my shallow understanding isn=E2=80=99= t it merely the same payload sent to set or all of subscribers? In which = case, I believe it can be handled as an implementation matter likely at = the application side. The protocol can be extended at later stage if wg = agrees it is something that is necessary but I haven=E2=80=99t heard = anybody else at the meeting or on the mailing list expressing this = feature is a show-stopper.  

Anyway, I would very much appreciate = it, if you can refrain the comments to the technical contents of the = draft. 

Thanks
Shida

On = May 16, 2016, at 6:50 PM, Richard Maher <maherrj@googlemail.com> 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-pu= sh-notifications-to-millions-of-devices-with-windows-azure-notification-hu= bs/

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#c= ollapsible_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 <shida@ntt-at.com> 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<= /div>

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
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush = mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

= --Apple-Mail=_709EB948-9453-49F3-A34E-ADD0B97CCA78-- From nobody Mon May 23 17:05:19 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06D412D5EB for ; Mon, 23 May 2016 17:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rw3b11FhQNX for ; Mon, 23 May 2016 17:05:17 -0700 (PDT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.148.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062FF12D52E for ; Mon, 23 May 2016 17:05:17 -0700 (PDT) Received: from cm6.websitewelcome.com (cm6.websitewelcome.com [108.167.139.19]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 7C9B1ABD1075D for ; Mon, 23 May 2016 19:05:16 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm6.websitewelcome.com with id y05E1s00V3AKFgo0105Fn6; Mon, 23 May 2016 19:05:16 -0500 Received: from c-98-248-153-86.hsd1.ca.comcast.net ([98.248.153.86]:44860 helo=[10.0.96.17]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b4zqU-000ROk-2e; Mon, 23 May 2016 19:05:14 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_3A1BADFE-A89D-4DAC-AF76-72DB18BE711B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shida Schubert In-Reply-To: Date: Mon, 23 May 2016 17:05:12 -0700 Message-Id: <3CA74329-7744-44D6-ACF1-4CEA586A2380@ntt-at.com> References: To: Richard Maher X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 98.248.153.86 X-Exim-ID: 1b4zqU-000ROk-2e X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-98-248-153-86.hsd1.ca.comcast.net ([10.0.96.17]) [98.248.153.86]:44860 X-Source-Auth: shida@agnada.com X-Email-Count: 3 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 00:05:19 -0000 --Apple-Mail=_3A1BADFE-A89D-4DAC-AF76-72DB18BE711B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Richard; This has nothing to do with the subject.=20 As mentioned in the other e-mail, please refrain your comments to the = draft in subject.=20 Thanks!=20 Shida as co-chair > On May 18, 2016, at 11:20 PM, Richard Maher = wrote: >=20 > Interesting developments: - >=20 > GCM has been rebranded to Firebase Cloud Messaging (FCM). FCM = inherits the reliable = and scalable GCM infrastructure, plus new features! See the FAQ = = to learn more. If you are integrating messaging in a new app, start with = FCM. GCM users are strongly recommended to upgrade to FCM, in order to = benefit from new FCM features today and in the future. >=20 > FIREbase - Hell of a catchy name! What's Mozilla's Autopush called? >=20 > "Firebase the bullet-proof, scaleable, industrial-strength = infrastructure behind Firefox." I like it. >=20 > On Tue, May 17, 2016 at 9:50 AM, Richard Maher > 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: - >=20 > Google Cloud Messaging: - > https://developers.google.com/cloud-messaging/topic-messaging = >=20 > Azure Notification Hubs: - > = https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifica= tions-to-millions-of-devices-with-windows-azure-notification-hubs/ = >=20 > 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 = >=20 > The fact that quintessential Push Notification feature "Broadcasting" = has been descoped from this protocol must be sufficient to reject the = proposal. >=20 > Please do not make the same mistake that you made with Geofences. IETF = and W3C credibility has already suffered enough. >=20 > On Tue, May 17, 2016 at 2:32 AM, Shida Schubert > wrote: > All; >=20 > 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.=20 >=20 > https://tools.ietf.org/html/draft-ietf-webpush-protocol-05 = >=20 > 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. >=20 > Please acknowledge on the list even when you are content/happy with = the status of the draft.=20 >=20 > The Working Group Last Call will end on June 6th (3 weeks).=20 >=20 > Shida > As co-chair >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = >=20 >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --Apple-Mail=_3A1BADFE-A89D-4DAC-AF76-72DB18BE711B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi = Richard;

This = has nothing to do with the subject. 

As mentioned in the other e-mail, = please refrain your comments to the draft in subject. 

Thanks! 
Shida as co-chair

On May 18, 2016, at 11:20 PM, = Richard Maher <maherrj@googlemail.com> wrote:

Interesting developments: -

GCM has = been rebranded to Firebase Cloud Messaging (FCM). FCM inherits the reliable and scalable GCM infrastructure, = plus new features! See the FAQ to = learn more. If you are integrating messaging in a new app, start with = FCM. GCM users are strongly recommended to upgrade to FCM, in order to = benefit from new FCM features today and in the future.

FIREbase - Hell of a = catchy name! What's Mozilla's Autopush called?

"Firebase the bullet-proof, scaleable, = industrial-strength infrastructure behind Firefox." I like it.

On Tue, = May 17, 2016 at 9:50 AM, Richard Maher <maherrj@googlemail.com> 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-pu= sh-notifications-to-millions-of-devices-with-windows-azure-notification-hu= bs/

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#c= ollapsible_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 <shida@ntt-at.com> 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<= /div>

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
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush



_______________________________________________
Webpush = mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

= --Apple-Mail=_3A1BADFE-A89D-4DAC-AF76-72DB18BE711B-- From nobody Mon May 23 17:53:44 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E8612DB53 for ; Mon, 23 May 2016 17:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUQWigEqy_e7 for ; Mon, 23 May 2016 17:53:39 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18C012DBB7 for ; Mon, 23 May 2016 17:53:38 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id f92so862470qgf.0 for ; Mon, 23 May 2016 17:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NIXa0aU428I4o037FxUGcLU8X+kgJ9kJF6hW7OsBI2k=; b=XvvKe52OFOTk/XSrSmlAjpj22bD/KOIc8mYokadWlmVBT08oW0h8XgHsdITLvIgPdj 2z5liIJVDip2GkGSTr6ctDyvDxCUJbYvRMVh/WLfbpCjlH57KfgnN3uDDb3RAngF8NSM Y5cf5/rFB/eNEf6D65MNDYaTPPcQUyhVYk715rMrfKUYr22b+T6ChWDKFCVFal2eb4Pd cfcpn46b8Soda/lZ1sX8yXkIqHgnHONibN9F6XEW3sx31vpuykKHE1yFNNMA5llA1l90 MnTuHafE/I7my99CypMW7MPcgSZSwAxxY8m998Rk8a6qxe2szoZPgThl+xi379WrAMbZ oy3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NIXa0aU428I4o037FxUGcLU8X+kgJ9kJF6hW7OsBI2k=; b=EnW2SWCRCTgK2KjR2IBcOpm1YGOn5joLhFL5qklDfgFQpeI7cdHCWeROfWcn/xSZHO sMoCA7ygRfLrDRjKhcl+n109inz4HkTH7ERdrNy4kBlHbNQfDnCEiM3JIC67Kah86TjH 8t4qvmAxFNfRtsMpECKClr5OjCDmrrg+DoIz5css2h5sCa0HcUDrkzxp+hqYuOqtgyGy fud+uNYu8Bg7LszIRc7VDcZX7lgDerxQDvMvPre+q1Z57xS90B0CDndEfpEPnpiap/NX QqX/tH4VmoCB1Q0LD8Yz9F4R4nvBH3ekUIdaf/xnTSjxsBuDRhcoRG35GhwDelRza0Ed 38WQ== X-Gm-Message-State: ALyK8tKU7afC71djJh09KSqh3DrOFWsLfVlMyoGxPzlh0B7ur3hsQ5zcMyjfxb9M2UeiOHkmfeMBoOjTA1cCzw== MIME-Version: 1.0 X-Received: by 10.140.134.134 with SMTP id 128mr951414qhg.63.1464051218058; Mon, 23 May 2016 17:53:38 -0700 (PDT) Received: by 10.55.104.194 with HTTP; Mon, 23 May 2016 17:53:37 -0700 (PDT) In-Reply-To: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> Date: Tue, 24 May 2016 08:53:37 +0800 Message-ID: From: Richard Maher To: Shida Schubert Content-Type: multipart/alternative; boundary=001a1136f988c91f0a05338bfc06 Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 00:53:43 -0000 --001a1136f988c91f0a05338bfc06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please see embedded comments: - On Tue, May 24, 2016 at 8:03 AM, Shida Schubert 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=E2=80=99s 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=E2=80=99t it merel= y 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_topi= c_subscriptions_from_the_server The protocol can be extended at later stage if wg agrees it is something > that is necessary but I haven=E2=80=99t 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 wrote= : > > "5.4 Updating Push Messages" is based on the misconception that "Topics" > are "Collapse Keys". The standard as proposed has been superseded by even= t > 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-notific= ations-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 proposa= l. > > Please do not make the same mistake that you made with Geofences. IETF an= d > W3C credibility has already suffered enough. > > On Tue, May 17, 2016 at 2:32 AM, Shida Schubert 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 >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a1136f988c91f0a05338bfc06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please see embedded comments: -

On Tue, May 24, 2016 at 8:03 AM, Shida S= chubert <shida@ntt-at.com> 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 subs= cribers 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 no= t the end of the world.
=C2=A0
The IETF has agreed that we need a standardi= zed protocol for this and that=E2=80=99s what we are chartered to work on.= =C2=A0

A much better idea espec= ially 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 exte= nsive as we can, eh? How many different specifications have there been so f= ar dealing with Server Push, Simple Push, etc. Each time with developers ha= ving to deprecate and re-tool :-(
=C2=A0
=

As for Broadcasting= , from my shallow understanding isn=E2=80=99t it merely the same payload se= nt to set or all of subscribers?

I find that level of naivety astounding in anyone who is involved in for= mulation of this standard. Why do you seek to deliberately ignore the clien= t-based subscription feature where any and all client-to-topic mapping is m= aintained solely by the Push Service and where the Application Server is ob= livious to consumers and freed the need for a local mapping database? The U= se-Cases are clear: - Sports results, Weather Updates, Stock Prices, Securi= ty Alerts, just to name a few. The strategy for encrypting an authenticatin= g the payload/body is also clear(ish): -=C2=A0https://github.com/slightlyoff/Servi= ceWorker/issues/901

Why do you people continue= to say "What elephant?"

In which case, I believe it can be ha= ndled as an implementation matter likely at the application side.

=C2=A0For some other use cases, managin= g subscriptions on the server is indeed an option. Horses for courses: -

The protocol can be extended= at later stage if wg agrees it is something that is necessary but I haven= =E2=80=99t heard anybody else at the meeting or on the mailing list express= ing this feature is a show-stopper. =C2=A0
I sorry to appear blunt but if the other members of the cloiste= red star chamber that is adjudicating on this are equally ignorant of the b= usiness requirements then there is no surprise they haven't come up wit= h 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 soluti= on?=C2=A0
=C2=A0

Anyway, I would very much appreciate it, if y= ou can refrain the comments to the technical contents of the draft.=C2=A0

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.
= =C2=A0=C2=A0

Thanks
S= hida

On May 16, 2016, at 6:50 PM, Richard Maher <maherrj@googlemail.com> = 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 gr= ound by established, successful, and more importantly scalable solutions: -=

Google Cloud Messaging: -
<= br>
Azure Notification Hubs: -
=C2=A0https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifi= cations-to-millions-of-devices-with-windows-azure-notification-hubs/

Whether the Topics are identified via HTTP headers o= r JSON Tokens is the only moot point. What is clear is that the proposed pr= otocol attempts to conflate the Topic and Collapse Key features: -
https://develop= ers.google.com/cloud-messaging/concept-options#collapsible_and_non-collapsi= ble_messages

The fact that quintessential = Push Notification feature "Broadcasting" has been descoped from t= his protocol must be sufficient to reject the proposal.

Please do not make the same mistake that you made with Geofences. IET= F and W3C credibility has already suffered enough.

On Tue, May 17, 2016 at 2:32 A= M, Shida Schubert <shida@ntt-at.com> wrote:
All;

A= s discussed at the IETF 95, as last issue surrounding the subscription re-u= se is addressed, we are starting a Working Group Last Call for the webpush = protocol.=C2=A0


If you = have any issues or questions regarding the draft please submit it to the li= st, when raising issues please provide constructive resolution when possibl= e.

Please acknowledge on the list even when you ar= e content/happy with the status of the draft.=C2=A0

The Working Group Last Call will end on June 6th (3 weeks).=C2=A0

Shida
As co-chair

______________= _________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush mailing list
= Webpush@ietf.org<= br>https://www.ietf.org/mailman/listinfo/webpush


__________________________________________= _____
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--001a1136f988c91f0a05338bfc06-- From nobody Tue May 24 11:11:27 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A377D12D8D3 for ; Tue, 24 May 2016 11:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEqRevwGbuYh for ; Tue, 24 May 2016 11:11:23 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CFE12B058 for ; Tue, 24 May 2016 11:11:23 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id tb2so8970420pac.2 for ; Tue, 24 May 2016 11:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TI7LnkTEPNv+o21t4XpUfWuKSmvVLeWWnN5JDp5SqCI=; b=ezR/jt0QCp2ZspNzp+1N4FrtfR2au8lbFbkJVtdN3viZbICfeZxrz6lh7VG9uUNyHJ KwobzOqNZBGCrsT5JYNwLtUuBPwqRrITETuHEmI9TnGakWJY2FgfgWoDQfJCvGAuhrHg umAzqBGyLVqCLQUcSDrHkOyYSZ270kzGWCiH1G+HXNsc/PmH/oonudTQ0fPUgHoDgrPH 0qNtsiQnqh1el+OOnAmoeB3XmjgiNJIOeskRZfxfssOgAQW3rO7FddbAUuksNP3SDvWr U7/lGwzwhQEAE6jdjfbnSXzw4HgtHdoLyHBItl0FqtbSO+ZHO2+Piq6zizvj+G8lI/e8 ndsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TI7LnkTEPNv+o21t4XpUfWuKSmvVLeWWnN5JDp5SqCI=; b=JP8QZEOFoY151k93fbAdLsbsEXbgUxHcZ3k4Jh/LFvnRr05iIx2f+GWZ7NbJhOJgnA e9BwfijaYvMsCHGeWxKH8pMdZeohmlTbDneYwEhoPC8V+cTrXz3C25YcgOZuCaN/FKi9 qG2x7/3sAD171Oy05humX2FRDC2BrZlDvXj3XbThxM0T60PwrMSBv2EIpnkRb9TKM/qy DtTKXz/UHeR0GGk5XIhM7NqYNjTspNtPZ3JI2/MXUasc7tAwNEFTtIJnBosT+aigcBRg DZXIzbyaTheTbaz+A9SjqpqiuPU/n+XHg7zjlMm1WCDyc3IxQJIlFPosVKlXVzZIr/YR w+Vw== X-Gm-Message-State: ALyK8tJTK4Q75dou48S6vhh/vlBVdlMqL8mbMiWtHuNnzfKluVMchFs72AMKlALxI17A+VVk1XVCYWHNy/LFig== X-Received: by 10.66.229.33 with SMTP id sn1mr8951586pac.49.1464113483098; Tue, 24 May 2016 11:11:23 -0700 (PDT) MIME-Version: 1.0 References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> In-Reply-To: From: Costin Manolache Date: Tue, 24 May 2016 18:11:13 +0000 Message-ID: To: Richard Maher , Shida Schubert Content-Type: multipart/alternative; boundary=047d7b15a5811237e205339a7cf1 Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 18:11:25 -0000 --047d7b15a5811237e205339a7cf1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +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 wrote: > Please see embedded comments: - > > On Tue, May 24, 2016 at 8:03 AM, Shida Schubert wrote: > >> >> Hi Richard; >> >> Thank you for your feedback. >> >> Currently developers need to either deal with different spec/api for eac= h >> 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=E2=80=99s what we are chartered to work on. >> > > A much better idea especially considering the number of Push Services tha= t > 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=E2=80=99t it mere= ly 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 mappi= ng > 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_to= pic_subscriptions_from_the_server > > > The protocol can be extended at later stage if wg agrees it is something >> that is necessary but I haven=E2=80=99t heard anybody else at the meetin= g 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 soluti= on. > > 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 kno= w > 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 >> wrote: >> >> "5.4 Updating Push Messages" is based on the misconception that "Topics" >> are "Collapse Keys". The standard as proposed has been superseded by eve= nt >> 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-notifi= cations-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#collapsibl= e_and_non-collapsible_messages >> >> The fact that quintessential Push Notification feature "Broadcasting" ha= s >> been descoped from this protocol must be sufficient to reject the propos= al. >> >> 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 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 i= t >>> 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 >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >>> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b15a5811237e205339a7cf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 - we discussed my concerns on flow control for push pro= mises, and I think it's reasonable to have them addressed either=C2=A0<= br>
as part of http2 or as a separate document.=C2=A0

Other than that I think it's reasonable and stable base - exten= sions and features can be added on top of it.

Cost= in


On Mon, May 23, 2016 at 5:53 PM Richard Maher <maherrj@googlemail.com> wrote:
Please see embedded comments: -
<= div class=3D"gmail_extra">
=
On T= ue, May 24, 2016 at 8:03 AM, Shida Schubert <shida@ntt-at.com> wrote:
Hi Richard;

Thank you for your feedbac= k.

Currently developers need to either deal with d= ifferent spec/api for each of the push notification providers (GCM, Azure, = APN etc.) to communicate to their subscribers or use third party service (u= rban airship etc.), which is fine for native apps but gets a little more co= mplicated with the browser.

<= /div>
Inconvenient but feature detection is not the end of the world.=
=C2=A0
The IETF has agreed that we need a standardized protoco= l for this and that=E2=80=99s what we are chartered to work on.=C2=A0
=

A much better idea esp= ecially considering the number of Push Services that don't happen to al= so manufacture a browser. But let's get it as fit-for-purpose and as ex= tensive 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 :-(
=C2=A0

As fo= r Broadcasting, from my shallow understanding isn=E2=80=99t it merely the s= ame payload sent to set or all of subscribers?

<= div class=3D"gmail_quote">
I find that level of naivety astounding in a= nyone who is involved in formulation of this standard. Why do you seek to d= eliberately 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 l= ocal mapping database? The Use-Cases are clear: - Sports results, Weather U= pdates, Stock Prices, Security Alerts, just to name a few. The strategy for= encrypting an authenticating the payload/body is also clear(ish): -=C2=A0<= a href=3D"https://github.com/slightlyoff/ServiceWorker/issues/901" target= =3D"_blank">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 i= mplementation matter likely at the application side.

=C2=A0For some other use cases, managi= ng subscriptions on the server is indeed an option. Horses for courses: -

The protocol = can be extended at later stage if wg agrees it is something that is necessa= ry but I haven=E2=80=99t heard anybody else at the meeting or on the mailin= g list expressing this feature is a show-stopper. =C2=A0

I sorry to appear blunt but if the = other members of the cloistered star chamber that is adjudicating on this a= re equally ignorant of the business requirements then there is no surprise = they haven't come up with a solution.

But *ple= ase* don't listen to me. Just look at what solutions that are already i= n 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&= #39;s get on with the solution?=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">

Any= way, I would very much appreciate it, if you can refrain the comments to th= e technical contents of the draft.=C2=A0

<= /div>
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.
=C2=A0= =C2=A0

<= /div>
Thanks
Shida
=

On May 16, 2016, a= t 6:50 PM, Richard Maher <maherrj@googlemail.com> wrote:

"5.4 Updating Push Messages" is based on the misconcepti= on that "Topics" are "Collapse Keys". The standard as p= roposed has been superseded by event on the ground by established, successf= ul, and more importantly scalable solutions: -

Google Cl= oud Messaging: -

Azure Notificat= ion Hubs: -

Whethe= r the Topics are identified via HTTP headers or JSON Tokens is the only moo= t point. What is clear is that the proposed protocol attempts to conflate t= he Topic and Collapse Key features: -

The fact that quintessential Push Notification feature &qu= ot;Broadcasting" has been descoped from this protocol must be sufficie= nt to reject the proposal.

Please do not make the = same mistake that you made with Geofences. IETF and W3C credibility has alr= eady suffered enough.

On Tue, May 17, 2016 at 2:32 AM, Shida Schubert <shida@nt= t-at.com> wrote:
All;

As discussed at the IETF 9= 5, as last issue surrounding the subscription re-use is addressed, we are s= tarting a Working Group Last Call for the webpush protocol.=C2=A0


If you have any issues or questi= ons regarding the draft please submit it to the list, when raising issues p= lease provide constructive resolution when possible.

Please acknowledge on the list even when you are content/happy with the = status of the draft.=C2=A0

The Working Group Last = Call will end on June 6th (3 weeks).=C2=A0

Shida
As co-chair

_______________________________________= ________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush mailing list
= Webpush@ietf.org<= br>https://www.ietf.org/mailman/listinfo/webpush


__________________________________________= _____
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush

_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush
--047d7b15a5811237e205339a7cf1-- From nobody Wed May 25 00:04:10 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6931F12D986 for ; Wed, 25 May 2016 00:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v_jpNrDu41V for ; Wed, 25 May 2016 00:04:07 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C37112D625 for ; Wed, 25 May 2016 00:04:07 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id n63so28342533qkf.0 for ; Wed, 25 May 2016 00:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=j69m9tk7MZsY8ZDuA00g790sjidi11XTzAkhBk/LGd8=; b=AbayOY8cclckn7WrRyvurhjNHu71UFe0lKQ71DNd+JuzWZBsBePhBzzklodVB6tGEQ iLfqLZG/oqDfwZMPYUlTU6rqPGjoOpqxGM5HXqX7XO0UPO5akryprkssWRuw7WUgRFyV OVQCODKZY0GBWocIqDvMAoJCt8AiVabhCKO9JbGQ0uFI5Fh1GNeEfDCaFTZvMIzhLw7f fwqp9vyNEqve4wmnTRCqJQH6j95cVWrl6EyuK1vhjBLTwDQeXByDyxfGPErLQEPlqOuP YOLxMaogJiz5TIhnamdtJKE0L//c7o3Onrpu5z6EafDe1GvXrYWNtUdzgCPKYBEsXUqW jNBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=j69m9tk7MZsY8ZDuA00g790sjidi11XTzAkhBk/LGd8=; b=dZRBjrmonRwaWdcaAGo1j1RF7q9DkbKguNpM3lC+ZEXmlVwgRZu6hNafo+IOCsjfhx vexuO+aJpexlxlqMCUIBpXxySsEia4Xih2Os6+J44rVEzCsk3RWXQy+TwLdAxwaZzLKF wy9Mk7NIEk6YDUGVUvaKDy13f/cMd811h15z36mVs2Or2D+ViSTyJBNGpmtx80N+xqmW 2KzX6Qn7sNmNfN32N58g7uMwKVxtOvnyaEJLQjZxbvlQV2hgjI4XOcrUQ5QCjsoiKtlm PfV2bE9gFLMeqiSSFReR1z1A+QpnC6eqgCadgQhPd2FcVrj+E/0OkxyZyUuaCaCp6IQ5 outA== X-Gm-Message-State: ALyK8tJNv7lTIWs4SDRc9Wm6OYOQ80xJH0DIS0xvFq2CKvLuqXQ5eeOxlGK5ls1GRQ3A5dBxexejK8qVKWbRFw== MIME-Version: 1.0 X-Received: by 10.55.80.131 with SMTP id e125mr1936469qkb.155.1464159846398; Wed, 25 May 2016 00:04:06 -0700 (PDT) Received: by 10.55.104.194 with HTTP; Wed, 25 May 2016 00:04:06 -0700 (PDT) In-Reply-To: References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> Date: Wed, 25 May 2016 15:04:06 +0800 Message-ID: From: Richard Maher To: Shida Schubert Content-Type: multipart/alternative; boundary=001a114a9ad08a3bab0533a547f1 Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 07:04:09 -0000 --001a114a9ad08a3bab0533a547f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For those who prefer to pain-by-numbers (see scalability): - https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern And, WRT the payload encryption options, maybe the following is the way to go? Defacto Javascript encryption standard? https://github.com/bitwiseshiftleft/sjcl C# and/or JAVA can encrypt and Javascrypt decrypt. A better solution? On Tue, May 24, 2016 at 8:53 AM, Richard Maher wrote: > Please see embedded comments: - > > On Tue, May 24, 2016 at 8:03 AM, Shida Schubert wrote: > >> >> Hi Richard; >> >> Thank you for your feedback. >> >> Currently developers need to either deal with different spec/api for eac= h >> 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=E2=80=99s what we are chartered to work on. >> > > A much better idea especially considering the number of Push Services tha= t > 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=E2=80=99t it mere= ly 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 mappi= ng > 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_to= pic_subscriptions_from_the_server > > > The protocol can be extended at later stage if wg agrees it is something >> that is necessary but I haven=E2=80=99t heard anybody else at the meetin= g 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 soluti= on. > > 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 kno= w > 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 >> wrote: >> >> "5.4 Updating Push Messages" is based on the misconception that "Topics" >> are "Collapse Keys". The standard as proposed has been superseded by eve= nt >> 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-notifi= cations-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#collapsibl= e_and_non-collapsible_messages >> >> The fact that quintessential Push Notification feature "Broadcasting" ha= s >> been descoped from this protocol must be sufficient to reject the propos= al. >> >> 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 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 i= t >>> 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 >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >>> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> > --001a114a9ad08a3bab0533a547f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For those who prefer to pain-by-numbers (see scalability):= -

And, WRT the payload encryption options= , maybe the following is the way to go?
Defacto Javasc= ript encryption standard?
https://github.com= /bitwiseshiftleft/sjcl
C# and/or JAVA= can encrypt and Javascrypt decrypt. A better solution?=C2=A0
<= /div>

On Tue, May = 24, 2016 at 8:53 AM, Richard Maher <maherrj@googlemail.com> wrote:
Please see embedded comments: -
=
On Tue, May 24, 2016 at 8:0= 3 AM, Shida Schubert <shida@ntt-at.com> wrote:

Hi Richard;

Thank you for your feedback.

Currently developers need to either deal with different spec/api for eac= h 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 browse= r.

Inconvenient but fea= ture detection is not the end of the world.
=C2= =A0
The IETF= has agreed that we need a standardized protocol for this and that=E2=80=99= s what we are chartered to work on.=C2=A0

=
A much better idea especially considering the number of P= ush Services that don't happen to also manufacture a browser. But let&#= 39;s get it as fit-for-purpose and as extensive as we can, eh? How many dif= ferent specifications have there been so far dealing with Server Push, Simp= le Push, etc. Each time with developers having to deprecate and re-tool :-(=
=C2=A0

As for Broadcasting, from my shallow = understanding isn=E2=80=99t it merely the same payload sent to set or all o= f subscribers?

I find t= hat level of naivety astounding in anyone who is involved in formulation of= this standard. Why do you seek to deliberately ignore the client-based sub= scription feature where any and all client-to-topic mapping is maintained s= olely 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 ar= e clear: - Sports results, Weather Updates, Stock Prices, Security Alerts, = just to name a few. The strategy for encrypting an authenticating the paylo= ad/body is also clear(ish): -=C2=A0https://github.com/slightlyof= f/ServiceWorker/issues/901

Why do you people c= ontinue to say "What elephant?"

In which case= , I believe it can be handled as an implementation matter likely at the app= lication side.

=C2=A0Fo= r some other use cases, managing subscriptions on the server is indeed an o= ption. Horses for courses: -

The protocol can be extended at later stage if wg agr= ees it is something that is necessary but I haven=E2=80=99t heard anybody e= lse at the meeting or on the mailing list expressing this feature is a show= -stopper. =C2=A0

I sorry= to appear blunt but if the other members of the cloistered star chamber th= at is adjudicating on this are equally ignorant of the business requirement= s 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 Ap= ps that satisfy these common requirements?

The MBO= NE people seem to have made progress over the years and we all know that yo= ur Application Servers with simply be overwhelmed if you tickle potentially= millions of clients so let's get on with the solution?=C2=A0
=C2=A0

Anyway, I would very much appreciate it, if you= can refrain the comments to the technical contents of the draft.=C2=A0

Are you telling me that poi= nting out omissions and scope deficiencies is not welcomed?

<= /div>
Either way 5.4 is completely wrong. You've been told.
=C2=A0=C2=A0

Thanks
Shida

On May 16, 2016, at 6:50 PM, Richard Maher <maherrj@googlemail.com&g= t; wrote:

"5.4 Updating Push Messages&q= uot; is based on the misconception that "Topics" are "Collap= se Keys". The standard as proposed has been superseded by event on the= ground by established, successful, and more importantly scalable solutions= : -

Google Cloud Messaging: -

Azure Notification Hubs: -

Whether the Topics are identified via HTTP header= s 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: -
=

The fact that quintessenti= al Push Notification feature "Broadcasting" has been descoped fro= m 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:3= 2 AM, Shida Schubert <shida@ntt-at.com> wrote:
All;

As discussed at the IETF 95, as last issue surrounding the subscription r= e-use is addressed, we are starting a Working Group Last Call for the webpu= sh protocol.=C2=A0


If y= ou have any issues or questions regarding the draft please submit it to the= list, when raising issues please provide constructive resolution when poss= ible.

Please acknowledge on the list even when you= are content/happy with the status of the draft.=C2=A0

=
The Working Group Last Call will end on June 6th (3 weeks).=C2=A0

Shida
As co-chair

___________= ____________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush mailing list
= Webpush@ietf.org<= br>https://www.ietf.org/mailman/listinfo/webpush


__________________________________________= _____
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush



--001a114a9ad08a3bab0533a547f1-- From nobody Mon May 30 14:35:31 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30CE12D1E5 for ; Mon, 30 May 2016 14:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opqy7mbPP9rg for ; Mon, 30 May 2016 14:35:27 -0700 (PDT) Received: from forward16p.cmail.yandex.net (forward16p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::bf]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8617E12D667 for ; Mon, 30 May 2016 14:35:27 -0700 (PDT) Received: from mxback6g.mail.yandex.net (mxback6g.mail.yandex.net [77.88.29.167]) by forward16p.cmail.yandex.net (Yandex) with ESMTP id 036252114E for ; Tue, 31 May 2016 00:35:23 +0300 (MSK) Received: from web18g.yandex.ru (web18g.yandex.ru [95.108.252.118]) by mxback6g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id xCeWyxoZw9-ZNWWUjlM; Tue, 31 May 2016 00:35:23 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1464644123; bh=LK+t69uxO1Dh9Q2IrqkliUQ87fjdzSvRFEOvWo6Vg/Q=; h=X-Yandex-Sender-Uid:From:To:Subject:MIME-Version:Message-Id: X-Mailer:Date:Content-Transfer-Encoding:Content-Type; b=UZD3MVHzOcQHPbTBzhD0JvLtx7GTHsKF7aVMTUDo/Q5PsLTBx1/bdUqJxlB7BVUqN cID3A5ujzZ8xzUOVg1wBoq+O+Xf9huhibcY9jWN2fJ78LfPAAiVFOkrH1EOZcFfp28 ob7DSsBRnCBjeQPvGfrkN9e1fXBlOiizx9XIa9Qs= Authentication-Results: mxback6g.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 492863893 X-Yandex-Sender-Uid: 161206619 Received: by web18g.yandex.ru with HTTP; Tue, 31 May 2016 00:35:23 +0300 From: Anton Tveretin To: webpush@ietf.org MIME-Version: 1.0 Message-Id: <1140911464644123@web18g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 31 May 2016 02:35:23 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: [Webpush] What to push? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 21:35:30 -0000 Hello All, I want to discuss what kind of information could be HTTP-pushed. For instance, HTML 6.0 once suggested to provide changes (delta) of the document. Maybe this does not fit well into current HTTP 2.0 spec - a new frame type is needed. I am not the author of HTML 6.0 (D. Tyurin is). Regards, Anton Tveretin From nobody Mon May 30 16:53:11 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7635012D6A5 for ; Mon, 30 May 2016 16:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HEa_YTjDbTe for ; Mon, 30 May 2016 16:53:07 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC9512D69E for ; Mon, 30 May 2016 16:53:07 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id x7so131888780qkd.3 for ; Mon, 30 May 2016 16:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=e78kbDG+/8Ak2U9K26wntGGpvYC3sqkmpz0W8hG/wmc=; b=G5xbzzGpLEDoavA3rIyjz1EstQK0V458bCwZWkeRVqx9uG2ibt7FOHMPII3UQO+7tE S2BX3al4t8LuhrCsFj38bzrEM5+Sy00zz8Wy5mlhCbd1nXW9s3StRFvRu7jsdivHCuUM qM7nQLq+XiM7TVJ01KflZ7E0jkJy2HEowzUL7g/CgzsTrDHdpj0DyiCkcaqWuMK+vfNF dRN/YXgO2qVwa8myiSg3GQbL0sL/KCN+eYo4xj/JBMe+6wfvCseVOC/nDMCh8HeOTmpD PI7TwZ8JdINkdqgyGO2xi5vTNsP9onQTLD5RuEJFpGbtGEUwHCTAgcgT6p0Km3wk53vD eiuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=e78kbDG+/8Ak2U9K26wntGGpvYC3sqkmpz0W8hG/wmc=; b=DV/jt1p5RcXSKo3DbPZ8qHiSVxRnkFjVmy8PuNb1o0spBqojEvclceBI6PPHz85LBI 0YFmQrOrmJa8m2uwm14eBflVbckJeouUWqNgSQZbiaUQlr55wWzoqtx8HGQdiVqv1IoF 5LbxRwhKDsgXD2DZ1MFnZuDVyx5Vr4s7okNMwletSu+zHIlFLz3PKV6HLUn7uB01WZCL QuT1ABlHpb1zYjhCe4lUZ9naW7klmqcUbAmH8Lh2FG5ATWoMKJi3UYgkhEdvgTsmSt9Z s4kf6I4tC/IaSwZiZRd4XMReODU4Pyd3OBrhBaJ8yrnqdKmo4zEr4v0U0WCP2cbmwnDp Cjpw== X-Gm-Message-State: ALyK8tLd6Lh7lzSm7/92jpRaQWWa6vGPGl5smRzXb8KGDZCbqXrpVVadYVobzHLPdzcPO5aB+HuRZLFmdPuA5A== MIME-Version: 1.0 X-Received: by 10.200.54.108 with SMTP id n41mr29728854qtb.18.1464652386578; Mon, 30 May 2016 16:53:06 -0700 (PDT) Received: by 10.140.104.110 with HTTP; Mon, 30 May 2016 16:53:06 -0700 (PDT) In-Reply-To: <1140911464644123@web18g.yandex.ru> References: <1140911464644123@web18g.yandex.ru> Date: Tue, 31 May 2016 09:53:06 +1000 Message-ID: From: Martin Thomson To: Anton Tveretin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] What to push? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 23:53:09 -0000 On 31 May 2016 at 07:35, Anton Tveretin wrote: > I want to discuss what kind of information could be HTTP-pushed. This isn't the right forum for discussing HTTP/2. If you have thoughts on how to improve or use HTTP/2 server push, try ietf-http-wg@w3.org From nobody Mon May 30 20:52:32 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D6312D0EF for ; Mon, 30 May 2016 20:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-Z-lJWDBYhZ for ; Mon, 30 May 2016 20:52:27 -0700 (PDT) Received: from gateway23.websitewelcome.com (gateway23.websitewelcome.com [192.185.50.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301C012D0AD for ; Mon, 30 May 2016 20:52:27 -0700 (PDT) Received: from cm4.websitewelcome.com (unknown [108.167.139.16]) by gateway23.websitewelcome.com (Postfix) with ESMTP id 99821BC50A0C0 for ; Mon, 30 May 2016 22:52:26 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm4.websitewelcome.com with id 0rsP1t0063AKFgo01rsQqD; Mon, 30 May 2016 22:52:26 -0500 Received: from c-98-248-153-86.hsd1.ca.comcast.net ([98.248.153.86]:44351 helo=[10.0.96.17]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b7aj8-0003VJ-Kw; Mon, 30 May 2016 22:52:22 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_3298B55B-FB45-4287-B3F7-65773462944A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shida Schubert In-Reply-To: Date: Mon, 30 May 2016 20:52:19 -0700 Message-Id: <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> To: webpush@ietf.org X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 98.248.153.86 X-Exim-ID: 1b7aj8-0003VJ-Kw X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-98-248-153-86.hsd1.ca.comcast.net ([10.0.96.17]) [98.248.153.86]:44351 X-Source-Auth: shida@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: Costin Manolache Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 03:52:31 -0000 --Apple-Mail=_3298B55B-FB45-4287-B3F7-65773462944A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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.=20 Thanks!=20 Shida > On May 24, 2016, at 11:11 AM, Costin Manolache = wrote: >=20 > +1 - we discussed my concerns on flow control for push promises, and I = think it's reasonable to have them addressed either=20 > as part of http2 or as a separate document.=20 >=20 > Other than that I think it's reasonable and stable base - extensions = and features can be added on top of it. >=20 > Costin >=20 >=20 > On Mon, May 23, 2016 at 5:53 PM Richard Maher > wrote: > Please see embedded comments: - >=20 > On Tue, May 24, 2016 at 8:03 AM, Shida Schubert > wrote: >=20 > Hi Richard; >=20 > Thank you for your feedback. >=20 > 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. >=20 > Inconvenient but feature detection is not the end of the world. > =20 > The IETF has agreed that we need a standardized protocol for this and = that=E2=80=99s what we are chartered to work on.=20 >=20 > 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 :-( > =20 >=20 > As for Broadcasting, from my shallow understanding isn=E2=80=99t it = merely the same payload sent to set or all of subscribers? >=20 > 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 = >=20 > Why do you people continue to say "What elephant?" >=20 > In which case, I believe it can be handled as an implementation matter = likely at the application side. >=20 > 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_top= ic_subscriptions_from_the_server = =20 >=20 > The protocol can be extended at later stage if wg agrees it is = something that is necessary but I haven=E2=80=99t heard anybody else at = the meeting or on the mailing list expressing this feature is a = show-stopper. =20 >=20 > 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. >=20 > 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? >=20 > 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?=20 > =20 >=20 > Anyway, I would very much appreciate it, if you can refrain the = comments to the technical contents of the draft.=20 >=20 > Are you telling me that pointing out omissions and scope deficiencies = is not welcomed? >=20 > Either way 5.4 is completely wrong. You've been told. > =20 >=20 > Thanks > Shida >=20 >> On May 16, 2016, at 6:50 PM, Richard Maher > wrote: >>=20 >> "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: - >>=20 >> Google Cloud Messaging: - >> https://developers.google.com/cloud-messaging/topic-messaging = >>=20 >> Azure Notification Hubs: - >> = https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifica= tions-to-millions-of-devices-with-windows-azure-notification-hubs/ = >>=20 >> 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 = >>=20 >> The fact that quintessential Push Notification feature "Broadcasting" = has been descoped from this protocol must be sufficient to reject the = proposal. >>=20 >> Please do not make the same mistake that you made with Geofences. = IETF and W3C credibility has already suffered enough. >>=20 >> On Tue, May 17, 2016 at 2:32 AM, Shida Schubert > wrote: >> All; >>=20 >> 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.=20 >>=20 >> https://tools.ietf.org/html/draft-ietf-webpush-protocol-05 = >>=20 >> 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. >>=20 >> Please acknowledge on the list even when you are content/happy with = the status of the draft.=20 >>=20 >> The Working Group Last Call will end on June 6th (3 weeks).=20 >>=20 >> Shida >> As co-chair >>=20 >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush = >>=20 >>=20 >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush = >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --Apple-Mail=_3298B55B-FB45-4287-B3F7-65773462944A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 <costin@gmail.com> 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 <maherrj@googlemail.com> wrote:
Please see embedded comments: -

On Tue, May 24, 2016 at = 8:03 AM, Shida Schubert <shida@ntt-at.com> 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=E2=80=99s 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=E2=80=99t 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#m= anaging_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=E2=80=99t = 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 = <maherrj@googlemail.com> 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-pu= sh-notifications-to-millions-of-devices-with-windows-azure-notification-hu= bs/

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#c= ollapsible_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 <shida@ntt-at.com> 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<= /div>

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
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush = mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush = mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

= --Apple-Mail=_3298B55B-FB45-4287-B3F7-65773462944A-- From nobody Mon May 30 23:58:15 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EF312B029 for ; Mon, 30 May 2016 23:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M29GYqAEp3uL for ; Mon, 30 May 2016 23:58:12 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B1E12B04A for ; Mon, 30 May 2016 23:58:11 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id e93so86888156qgf.2 for ; Mon, 30 May 2016 23:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=EYZcmng+A2VE3Td8agmzAFwJ2d8gohdFZ4ixqwp7q4o=; b=njb4FNfCrnI9H9fY6fb1GM46Z3B0JO+85BVpB7buKNC2Se0c8vnJ34PN+JuA1I3tSu n+6wOV2bKYDpfvvY+0mc60LitW+chDkW0UGkCdeD+ton10sq/rCrGlhhCKw3Dh+KPeKV P2mBj9XMVLk7xGPoUb3BzQt2n/yOAh0ojugrnAp28wIpfk8If90eRZBlhr04F3e/YT6V XQmjplTi+8YLRGuvTnlfmbyEzOr308y1mLzhhPVJNSmLmd4WOSZifkordhDnteCFa73k Ds+HxlRKDEN/XPIYfIz13sFbBZL6tDlM7HDzQDU7bbZLNeAT55IA1SHeXnxrbGwcaKcv +8RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=EYZcmng+A2VE3Td8agmzAFwJ2d8gohdFZ4ixqwp7q4o=; b=PzhJEnr/GaLdOTo9yIm9CS0nDE2e8oVldimKeyMZ+U25aqzBxIIUY5xf0eTmUUvYHP 5eGFPUgH0XuU32rHv2Y9GVnM3ZxR2nxiiIOW2mFobbsBk6U2p3wd/v2FWHlawx+0cvMG 30cmjRfWz/mCOcqh2rE7s2pyiTjo9kL36ygC6hdyfr1rB2qqbU02ppcXRRrDnUeK7R1T JaGTKFuNzXfk8b8U+AjsIgwFatwQlP2dCGGVHyei+VxEIrT1Sjk8htOI8qcJGOFb44UB Js8FbKQpTMUZ6Pn0WDEApFsuWxuMqGxaKIrghU7owwXLZIiSU1oTLm/CRmQSNq/lAsay o9Rw== X-Gm-Message-State: ALyK8tKpEncwX8jSvD6NZQh2inw+XPLrtDV9nT88ZkQaj1AiSbBMTDWwYuSb7UNRqmW6s4Yz+ZnQKBdyKOCTYQ== MIME-Version: 1.0 X-Received: by 10.140.134.134 with SMTP id 128mr30870064qhg.63.1464677890988; Mon, 30 May 2016 23:58:10 -0700 (PDT) Received: by 10.55.104.194 with HTTP; Mon, 30 May 2016 23:58:10 -0700 (PDT) In-Reply-To: <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> Date: Tue, 31 May 2016 14:58:10 +0800 Message-ID: From: Richard Maher To: Shida Schubert Content-Type: multipart/alternative; boundary=001a1136f98867249905341de596 Archived-At: Cc: Costin Manolache , webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 06:58:15 -0000 --001a1136f98867249905341de596 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please also take the time to make submissions to the European Commission on the lack of plug-n-play specification with WebPush facilitating the abuse of monopoly positions by respective browser manufacturers to suppress competition from third party Push Notification Services. I've attached my submission to this case: - http://ec.europa.eu/competition/elojade/isef/case_details.cfm?proc_code=3D1= _40099 Each browser user must be unencumbered in their choice of Cloud Service Provider(s) as they are for browsers, and search engines. On Tue, May 31, 2016 at 11:52 AM, 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 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 > wrote: > >> Please see embedded comments: - >> >> On Tue, May 24, 2016 at 8:03 AM, Shida Schubert 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 airs= hip >>> 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=E2=80=99s 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=E2=80=99t it mer= ely 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 mapp= ing >> is maintained solely by the Push Service and where the Application Serve= r >> is oblivious to consumers and freed the need for a local mapping databas= e? >> 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 indee= d >> an option. Horses for courses: - >> >> https://developers.google.com/cloud-messaging/topic-messaging#managing_t= opic_subscriptions_from_the_server >> >> >> The protocol can be extended at later stage if wg agrees it is something >>> that is necessary but I haven=E2=80=99t heard anybody else at the meeti= ng 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 busines= s >> requirements then there is no surprise they haven't come up with a solut= ion. >> >> 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 tic= kle >> potentially millions of clients so let's get on with the solution? >> >> >>> >>> Anyway, I would very much appreciate it, if you can refrain the comment= s >>> 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 >>> wrote: >>> >>> "5.4 Updating Push Messages" is based on the misconception that "Topics= " >>> are "Collapse Keys". The standard as proposed has been superseded by ev= ent >>> 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-notif= ications-to-millions-of-devices-with-windows-azure-notification-hubs/ >>> >>> Whether the Topics are identified via HTTP headers or JSON Tokens is th= e >>> only moot point. What is clear is that the proposed protocol attempts t= o >>> conflate the Topic and Collapse Key features: - >>> >>> https://developers.google.com/cloud-messaging/concept-options#collapsib= le_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 >>> wrote: >>> >>>> All; >>>> >>>> As discussed at the IETF 95, as last issue surrounding the subscriptio= n >>>> 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 resolu= tion >>>> when possible. >>>> >>>> Please acknowledge on the list even when you are content/happy with th= e >>>> status of the draft. >>>> >>>> The Working Group Last Call will end on June 6th (3 weeks). >>>> >>>> Shida >>>> As co-chair >>>> >>>> _______________________________________________ >>>> Webpush mailing list >>>> Webpush@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webpush >>>> >>>> >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >>> >>> >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >>> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a1136f98867249905341de596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please also take the time= to make submissions to the European Commission on the lack of plug-n-play = specification with WebPush facilitating the abuse of monopoly positions by = respective browser manufacturers to suppress competition from third party P= ush Notification Services.

=
I've attached my submission to this cas= e: -

Each= browser user must be unencumbered in their choice of Cloud Service Provide= r(s) as they are for browsers, and search engines.

On Tue, May 31, 2016 at= 11:52 AM, Shida Schubert <shida@ntt-at.com> wrote:
All;

We have heard very little regarding the actual content= s of the draft and WGLC is over this week.

As note= d when I started the last call, please show your support by providing ackno= wledgement(s) if you are happy with the draft as is.=C2=A0

Thanks!=C2=A0
=
Shida

On May 24, 2016, at 11:11 AM, Costin Manolache <costin@gmail.com> wr= ote:

+1 - we discussed my concerns on flow c= ontrol for push promises, and I think it's reasonable to have them addr= essed either=C2=A0
as part of http2 or as a separate document.=C2= =A0

Other than that I think it's reasonable an= d stable base - extensions and features can be added on top of it.

Costin


On Mon, May 23, 2016 at 5:53 PM Richard Maher <maherrj@googlemai= l.com> wrote:
Please see embedded comments: -

On Tue, May 24, 2016 at 8:03 AM, Shida S= chubert <shida@ntt-at.com> 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 subs= cribers 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 d= etection is not the end of the world.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
The IETF has agree= d that we need a standardized protocol for this and that=E2=80=99s what we = are chartered to work on.=C2=A0

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 differ= ent specifications have there been so far dealing with Server Push, Simple = Push, etc. Each time with developers having to deprecate and re-tool :-(
=C2=A0

As for Broadcasting, from my shallow unde= rstanding isn=E2=80=99t it merely the same payload sent to set or all of su= bscribers?

I fin= d 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 maintaine= d 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 Alert= s, just to name a few. The strategy for encrypting an authenticating the pa= yload/body is also clear(ish): -=C2=A0https://github.com/slightl= yoff/ServiceWorker/issues/901

Why do you peopl= e continue to say "What elephant?"

In which case= , I believe it can be handled as an implementation matter likely at the app= lication side.

= =C2=A0For some other use cases, managing subscriptions on the server is ind= eed an option. Horses for courses: -

The protocol can be extended at later stage if wg= agrees it is something that is necessary but I haven=E2=80=99t heard anybo= dy else at the meeting or on the mailing list expressing this feature is a = show-stopper. =C2=A0

<= div>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 solu= tion.

But *please* don't listen to me. Just lo= ok 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 an= d create Apps that satisfy these common requirements?

<= div>The MBONE people seem to have made progress over the years and we all k= now that your Application Servers with simply be overwhelmed if you tickle = potentially millions of clients so let's get on with the solution?=C2= =A0
=C2=A0

Anyway, I would very much appreciate = it, if you can refrain the comments to the technical contents of the draft.= =C2=A0

Are you te= lling me that pointing out omissions and scope deficiencies is not welcomed= ?

Either way 5.4 is completely wrong. You've b= een told.
=C2=A0=C2=A0

Thanks
Shida

On May 16, 2016, at 6:50 PM, Richard Maher <maherrj@googlemail.co= m> wrote:

"5.4 Updating Push Mes= sages" 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 so= lutions: -

Google Cloud Messaging: -


Whether the Topics are identified via = HTTP headers or JSON Tokens is the only moot point. What is clear is that t= he proposed protocol attempts to conflate the Topic and Collapse Key featur= es: -

The fact that q= uintessential Push Notification feature "Broadcasting" has been d= escoped 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 <shida@ntt-at.com> wrote:
=
All;
As discussed at the IETF 95, as last issue surrounding the sub= scription re-use is addressed, we are starting a Working Group Last Call fo= r the webpush protocol.=C2=A0


If you have any issues or questions regarding the draft please submi= t it to the list, when raising issues please provide constructive resolutio= n when possible.

Please acknowledge on the list ev= en when you are content/happy with the status of the draft.=C2=A0

The Working Group Last Call will end on June 6th (3 weeks).= =C2=A0

Shida
As co-chair

= _______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush mailing list
= Webpush@ietf.org<= br>https://www.ietf.org/mailman/listinfo/webpush


__________________________________________= _____
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush

_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
= Webpush@ietf.org<= br>https://www.ietf.org/mailman/listinfo/webpush


__________________________________________= _____
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--001a1136f98867249905341de596-- From nobody Tue May 31 12:09:34 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763A812D14B for ; Tue, 31 May 2016 12:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26CeRepBKqGO for ; Tue, 31 May 2016 12:09:29 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4567E12D0B3 for ; Tue, 31 May 2016 12:00:58 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id b124so77106555pfb.0 for ; Tue, 31 May 2016 12:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=Hazjv7hys1uFhsVC3fVRS7zS4i9VK9+3CcAi1zXPdfo=; b=w9GyGoRFWdOOsOJI/k+gFMe0N5xOMFWUAT8wyXGlovf4RJp147RW8PbBVDvaYSDGFA ieTEvYigQMC76AX5P/pENTiV8KRjjdIiixiUAR++jjqYX+Krp6+3ra/234sYjXYTDHpz rWvCOlUY9YQO6HsuMyxcZNSdwaNin56BFd6HimpSLjcGOlwX2RcMmeoijmY53FxlMDBR xEVTZKokezZ+z1jK56xkp4e/g+EVa+FhhnfIfGE7TAbKHCIvH0jmSYr03fV64Ms8p1HE B0g/XwN7Rcej1BFg29Rwvy1trN9rl8xkyQdLlhz8WUEj+J9tEFOB4SloGTEfuOTSaAgI PzfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Hazjv7hys1uFhsVC3fVRS7zS4i9VK9+3CcAi1zXPdfo=; b=BgTPmG8WJ39W+OaNkpgS0+NF1q+yoI67YYygAGzQDu8GDyKQo87TBebK/ztuNnBL27 fejceWNvtNYVHa6xsEtAaFgl2MmIfH8e/nAE9gXaiJdEWiHhMAiwRGOrXZA+HjiIn+Pv Qs9alRC1I6rEtDL91Dw7mXv2LspoXJba7KX97UTqgcCPWWsxUuSRuaNdI/+wKKhQYVGe T/EKxCG7n3hJCtNOQPllWFREyQVQzoUO326jLmlY60DL/fwWf3plsLu+rucvVCOZbzy2 Rlphs2L8F/8kUq8zYeVP0dsg6fFL3CO9gjLbCzAZs0XL5OBUl3HrlGuHIQpc6l+il2Fc xXTw== X-Gm-Message-State: ALyK8tJWbFynBTs/RFeN9M0m4Z00QkIFlIi/9j+M+hi630cbvLzJ39pHDy9Sg6pUnsDA2GLv X-Received: by 10.98.91.7 with SMTP id p7mr2137552pfb.8.1464721257542; Tue, 31 May 2016 12:00:57 -0700 (PDT) Received: from [10.10.105.109] (ip170.guelphtool.com. [207.35.6.170]) by smtp.gmail.com with ESMTPSA id ez6sm56703479pab.12.2016.05.31.12.00.55 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2016 12:00:56 -0700 (PDT) To: webpush@ietf.org References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> From: jr conlin Message-ID: <4467b402-a69f-fc0e-f699-00ca9f9f14e8@mozilla.com> Date: Tue, 31 May 2016 12:00:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Thunderbird/48.0a2 MIME-Version: 1.0 In-Reply-To: <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> Content-Type: multipart/alternative; boundary="------------4B6FAFD6E27B4769BB014477" Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:09:33 -0000 This is a multi-part message in MIME format. --------------4B6FAFD6E27B4769BB014477 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 > > 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 > > wrote: >> >> Please see embedded comments: - >> >> On Tue, May 24, 2016 at 8:03 AM, Shida Schubert > > 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 >>> > 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 >>> > 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 >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >>> >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --------------4B6FAFD6E27B4769BB014477 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
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 <costin@gmail.com> 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 <maherrj@googlemail.com> wrote:
Please see embedded comments: -

On Tue, May 24, 2016 at 8:03 AM, Shida Schubert <shida@ntt-at.com> 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: -

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 <maherrj@googlemail.com> 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: -

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: -

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 <shida@ntt-at.com> 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. 


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
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush



_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--------------4B6FAFD6E27B4769BB014477-- From nobody Tue May 31 12:40:35 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD85112D7F2 for ; Tue, 31 May 2016 12:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2rH5ZeRuxgv for ; Tue, 31 May 2016 12:40:31 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C052F12D63E for ; Tue, 31 May 2016 12:40:30 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id w16so85688036lfd.2 for ; Tue, 31 May 2016 12:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=4P+n1e8sW1nbZ4m36ntZjKdiBrbr6jQSYPtLRvB0UFU=; b=WGwAETLLmv0a243+0AihvGEqCin9C8fFnt7iCKx0wkl7bFzregDvno1J2GXp15eZw2 JKNAgYbwDvo6EsjDm8j59VGUaKWZXfFsZ8ru8FBYtcapIhTp3mK8RFe5yyjchY0iocB7 99/24buNST8saUbFNYcjo06FxnjNV8jp/cRlGkYX9Ny+sT8RvaO/gb7eTnN8UO2P8bbX gQqKbJWE1D4IiB1kLeTfUOiLnZ4x3yHfs9AEPgJN8Mgsq2sf2Ibspqyl9evqS8O0yWS7 IWPEYZ6SFXwLxf9rr62EBfpdyLehQqlYqtIEWb8T3IAq+bLuvQsJBMXwC1XvbGNBexoL UXHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4P+n1e8sW1nbZ4m36ntZjKdiBrbr6jQSYPtLRvB0UFU=; b=GgtaDqEN47HXCuSOAozUgj0Q9HznRM2LPjYI4QAGPSZ6dbNtmeVBG3Nc31wjmTQ2HU a18uuJFdoVIFakC7x+iZKFAEOoBV/mH7C5JqGrn8JrChLe6uHras6EnaVIBW5kCqgsfw 1+YnB2lck/fBCW8Qj8VPrl1Q0ixEljVPIYm0uEFoIXCmNOOKmet2Fg3t1mnEn5Wz+Cix 2vGB0Oj2z0UUPL2uMGEwWT2Y4cSIE7pmGN9EWS9WF4gQCWxFvk3pMiG+WukAxO1Mb4gZ cbtKELWPlTk0mzcu3Jvu9SCbVLaS6tgtmCHav763QjCVJDr3xqWzfDdB4c1klQOyY+PS iUJQ== X-Gm-Message-State: ALyK8tL9WcL1KESMyGoJ1Lp7/tBEtT1Tn/ZH/4/EPUE8ZIypt2td+g4NakwV/319JxatD4fnbsE+UOGj4mouP/7D X-Received: by 10.25.16.219 with SMTP id 88mr64007lfq.21.1464723628726; Tue, 31 May 2016 12:40:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.167.82 with HTTP; Tue, 31 May 2016 12:40:27 -0700 (PDT) From: Peter Beverloo Date: Tue, 31 May 2016 20:40:27 +0100 Message-ID: To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a11402d9c95f1310534288bae Archived-At: Subject: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:40:34 -0000 --001a11402d9c95f1310534288bae Content-Type: text/plain; charset=UTF-8 Hi Martin, Brian, Elio, As an implementer I can only express my gratitude for the fantastic creating and editing of the standard you have done - thank you *so* much! I have a few last-minute comments, none of which have to be blocking for the WGLC. I'll acknowledge agreement in Shida's thread momentarily. 1) Page 11, "A push message with zero TTL...push messages." This section is very loose in defining whether or not delivery receipts should be send for messages with TTL 0. In effect, behaviour of the Web Push services out there today may strong-arm future services by establishing developer expectations. Have we considered not sending receipts for messages with TTL=0 at all? 2) Page 21, "this can be signaled by returning a 400-series status code, such as 410 (Gone)." This is the only ambiguous status code reference in the standard. What is the reason for not settling on 404 or 410? The example of 410 for expiring subscriptions here is different from the 404 mentioned in 7.1 (Page 20), it would be good to make that consistent. I also have a few editorial comments: - Page 3, "Requesting the delivery of events is particularly important for the W3C Push API." It is not explained why it is particularly important. Is this assumed knowledge of the reader? I would suggest the following addition: "...for the W3C Push API as the developer may have to request push message delivery from any number of push services." - Page 4, definition of "application server" Nothing precludes an application from not needing a server side at all. I don't think we should change the term, but perhaps we can consider slightly rephrasing the definition as: "The component of an application that *usually* runs on a server and requests the delivery of a push message." - Page 7, "Confidentiality protection and application server authentication MUST be used to ensure that this URI is not disclosed to unauthorized recipients (Section 8.3)." Is it appropriate for the standard to dictate a MUST here when the distribution method is defined to be application-specific? (I do agree with the premise.) - Page 7, "[subscription sets] can represent a significant efficiency improvement for a push service." There are significant improvements for many types of user agents as well, so I would suggest rephrasing as "... improvements for push services and user agents." - Page 8, "The push message is included in the body of the request." While covered by Section 8.1 in the Operational Considerations, given the strong focus on security and privacy considerations throughout the rest of the standard I think it would be appropriate to mention the strong preference for encryption here? - Page 11, page 13: s/acknowledgement receipts/delivery receipts/. - Page 12, 13: Both "update" and "replace" are used to describe the same operation. I don't think that consistently using "replace" would change the meaning of this section- could we? One final thing that I'm on the fence about is that the push service MUST NOT forward the Urgency value to the user agent. I can see uses, but also concerns in the scenario of a compromised or malicious push service. Is this the reason behind the strong language? Thanks, Peter --001a11402d9c95f1310534288bae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin, Brian, Elio,

As a= n implementer I can only express my gratitude for the fantastic
c= reating and editing of the standard you have done - thank you *so* much!

I have a few last-minute comments, none of which hav= e to be blocking for
the WGLC. I'll acknowledge agreement in = Shida's thread momentarily.

=C2=A0 =C2=A0 1) P= age 11, "A push message with zero TTL...push messages."

This section is very loose in defining whether or not deliv= ery receipts
should be send for messages with TTL 0. In effect, b= ehaviour of the Web
Push services out there today may strong-arm = future services by
establishing developer expectations.

Have we considered not sending receipts for messages with T= TL=3D0 at all?

=C2=A0 =C2=A0 2) Page 21, "thi= s can be signaled by returning a 400-series status
=C2=A0 =C2=A0 = =C2=A0 =C2=A0code, such as 410 (Gone)."

This = is the only ambiguous status code reference in the standard. What is
<= div>the reason for not settling on 404 or 410?

The= example of 410 for expiring subscriptions here is different from the
=
404 mentioned in 7.1 (Page 20), it would be good to make that consiste= nt.


I also have a few editorial com= ments:

=C2=A0 =C2=A0 - Page 3, "Requesting th= e delivery of events is particularly important
=C2=A0 =C2=A0 =C2= =A0 for the W3C Push API."

It is not explaine= d why it is particularly important. Is this assumed
knowledge of = the reader? I would suggest the following addition:

"...for the W3C Push API as the developer may have to request push m= essage
delivery from any number of push services."

=C2=A0 =C2=A0 - Page 4, definition of "application ser= ver"

Nothing precludes an application from no= t needing a server side at all. I
don't think we should chang= e the term, but perhaps we can consider
slightly rephrasing the d= efinition as:

"The component of an applicatio= n that *usually* runs on a server and
requests the delivery of a = push message."

=C2=A0 =C2=A0 - Page 7, "= Confidentiality protection and application server
=C2=A0 =C2=A0 = =C2=A0 authentication MUST be used to ensure that this URI is not disclosed=
=C2=A0 =C2=A0 =C2=A0 to unauthorized recipients (Section 8.3).&q= uot;

Is it appropriate for the standard to dictate= a MUST here when the
distribution method is defined to be applic= ation-specific? (I do agree
with the premise.)

=C2=A0 =C2=A0 - Page 7, "[subscription sets] can represent a si= gnificant efficiency
=C2=A0 =C2=A0 =C2=A0 improvement for a push = service."

There are significant improvements = for many types of user agents as well,
so I would suggest rephras= ing as "... improvements for push services and
user agents.&= quot;

=C2=A0 =C2=A0 - Page 8, "The push messa= ge is included in the body of the request."

W= hile covered by Section 8.1 in the Operational Considerations, given the
strong focus on security and privacy considerations throughout the = rest
of the standard I think it would be appropriate to mention t= he strong
preference for encryption here?

=C2=A0 =C2=A0 - Page 11, page 13: s/acknowledgement receipts/delivery rec= eipts/.

=C2=A0 =C2=A0 - Page 12, 13: Both "up= date" and "replace" are used to describe the
=C2= =A0 =C2=A0 =C2=A0 same operation. I don't think that consistently using= "replace"
=C2=A0 =C2=A0 =C2=A0 would change the meanin= g of this section- could we?


O= ne final thing that I'm on the fence about is that the push service MUS= T
NOT forward the Urgency value to the user agent. I can see uses= , but also
concerns in the scenario of a compromised or malicious= push service. Is
this the reason behind the strong language?

Thanks,
Peter
--001a11402d9c95f1310534288bae-- From nobody Tue May 31 12:42:38 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C7B12D7F2 for ; Tue, 31 May 2016 12:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gG6GtUvun0H for ; Tue, 31 May 2016 12:42:34 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B0612D63E for ; Tue, 31 May 2016 12:42:33 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id k98so98076626lfi.1 for ; Tue, 31 May 2016 12:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b2fwjf4McMwk+DQD9cx8pj4ajzkrhyNfMX5rw53TarE=; b=WupYY+mAq5LGapqJrI0a38yZhuMQ07elHfGe3tpPI0YS9FvdAmRr1iIgLM76wnkV2R Do1/ZfqA7gHZ7vyyeNK0cDEWNLbkbmUq/Zk6zII6I1Bjg6kkxgflP1/B6pd1mGf4uYjT 72qH+vrz2/MpB+AeGnfmiMERYLua/Vzb4a9AetR7o7dFnPM3F98lyijwwpT3jQX8LSdY nO7xdYhfCQ1g6MNBbqMtiQHG+0xYNgRoDooi2Hi3KbhF5WyaG7iU8l3X03w9bL5BaLdG NwNfnRFu+8nhy1s7L+jUae54/5ZRM0VRlFVQdfYWXnCYLbJ/bctqAVbI0F9heL5Sm1u7 tInQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b2fwjf4McMwk+DQD9cx8pj4ajzkrhyNfMX5rw53TarE=; b=P7hO7MVMp7tmq0t9MhjTRio1aRXfeGroA+jA6gBXplQgwo9la1WcJEUTsvGRa6EEnB 6lL5XzsAbm8ijrflLCpj6Tz6OwLjICJw8sv2m6/iXzFyk51iyZBUDjd5cbe6CaEj12UH UBSqtq5Zjznjkr6pkjJq1tJLpJxZ/8om4e9L3ZMqDGM8/JD0ppYYpXYVo8KXa4OQRvJk OmC2ZWAUqQ73jfnL0V6qjv0erzeByy1ZuC8DAmuMy0CMJNd03fpWwL28wSUPPA7XkAkB 1jJr7sCAWzLNRniUG3bn554+2s614qk/cs9uZem6Za2OsJ2LdBRhrkU9m+Ih7D1c3yCE TYpA== X-Gm-Message-State: ALyK8tJU9zcdhQs4wnqX4+Wykfs1d2P8AjaBgp8ME6/LQj8C3XiVRIWYVBMWL9arqzKvrj3otJ2JAhpGmKvholev X-Received: by 10.25.163.8 with SMTP id m8mr69251lfe.144.1464723751776; Tue, 31 May 2016 12:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.167.82 with HTTP; Tue, 31 May 2016 12:42:30 -0700 (PDT) In-Reply-To: <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> From: Peter Beverloo Date: Tue, 31 May 2016 20:42:30 +0100 Message-ID: To: Shida Schubert Content-Type: multipart/alternative; boundary=001a114076b6eba2b6053428920d Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:42:37 -0000 --001a114076b6eba2b6053428920d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 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 > wrote: > >> Please see embedded comments: - >> >> On Tue, May 24, 2016 at 8:03 AM, Shida Schubert 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 airs= hip >>> 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=E2=80=99s 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=E2=80=99t it mer= ely 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 mapp= ing >> is maintained solely by the Push Service and where the Application Serve= r >> is oblivious to consumers and freed the need for a local mapping databas= e? >> 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 indee= d >> an option. Horses for courses: - >> >> https://developers.google.com/cloud-messaging/topic-messaging#managing_t= opic_subscriptions_from_the_server >> >> >> The protocol can be extended at later stage if wg agrees it is something >>> that is necessary but I haven=E2=80=99t heard anybody else at the meeti= ng 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 busines= s >> requirements then there is no surprise they haven't come up with a solut= ion. >> >> 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 tic= kle >> potentially millions of clients so let's get on with the solution? >> >> >>> >>> Anyway, I would very much appreciate it, if you can refrain the comment= s >>> 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 >>> wrote: >>> >>> "5.4 Updating Push Messages" is based on the misconception that "Topics= " >>> are "Collapse Keys". The standard as proposed has been superseded by ev= ent >>> 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-notif= ications-to-millions-of-devices-with-windows-azure-notification-hubs/ >>> >>> Whether the Topics are identified via HTTP headers or JSON Tokens is th= e >>> only moot point. What is clear is that the proposed protocol attempts t= o >>> conflate the Topic and Collapse Key features: - >>> >>> https://developers.google.com/cloud-messaging/concept-options#collapsib= le_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 >>> wrote: >>> >>>> All; >>>> >>>> As discussed at the IETF 95, as last issue surrounding the subscriptio= n >>>> 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 resolu= tion >>>> when possible. >>>> >>>> Please acknowledge on the list even when you are content/happy with th= e >>>> status of the draft. >>>> >>>> The Working Group Last Call will end on June 6th (3 weeks). >>>> >>>> Shida >>>> As co-chair >>>> >>>> _______________________________________________ >>>> Webpush mailing list >>>> Webpush@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webpush >>>> >>>> >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >>> >>> >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >>> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a114076b6eba2b6053428920d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have just shared some comments, but none of them are sig= nificant enough to defer WGLC.

As such, I can definitely= support the draft as-is.

Thanks,
Peter<= br>

On Tue, M= ay 31, 2016 at 4:52 AM, Shida Schubert <shida@ntt-at.com> wro= te:
<= div>All;

We have heard very little regarding the a= ctual contents of the draft and WGLC is over this week.

As noted when I started the last call, please show your support by pr= oviding acknowledgement(s) if you are happy with the draft as is.=C2=A0

Thanks!=C2=A0
Shida

=
On May 24, 2016, at 11:11 AM, Costin Manolac= he <costin@gmail.c= om> wrote:

+1 - we discussed my conce= rns on flow control for push promises, and I think it's reasonable to h= ave them addressed either=C2=A0
as part of http2 or as a separate d= ocument.=C2=A0

Other than that I think it's re= asonable and stable base - extensions and features can be added on top of i= t.

Costin


On Mon, May 23, 2016 at 5:53 PM Richard M= aher <maherr= j@googlemail.com> wrote:
Please see embedded comments: -

On Tue, May 24, 2016 at 8:03 = AM, Shida Schubert <shida@ntt-at.com> 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 i= s fine for native apps but gets a little more complicated with the browser.=

Inconvenient bu= t feature detection is not the end of the world.
= =C2=A0
The I= ETF has agreed that we need a standardized protocol for this and that=E2=80= =99s what we are chartered to work on.=C2=A0
<= br>
A much better idea especially considering the n= umber 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? Ho= w many different specifications have there been so far dealing with Server = Push, Simple Push, etc. Each time with developers having to deprecate and r= e-tool :-(
=C2=A0

As for Broadcasting, from my = shallow understanding isn=E2=80=99t 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 c= lient-based subscription feature where any and all client-to-topic mapping = is maintained solely by the Push Service and where the Application Server i= s oblivious to consumers and freed the need for a local mapping database? T= he Use-Cases are clear: - Sports results, Weather Updates, Stock Prices, Se= curity Alerts, just to name a few. The strategy for encrypting an authentic= ating the payload/body is also clear(ish): -=C2=A0https://github= .com/slightlyoff/ServiceWorker/issues/901

Why = do you people continue to say "What elephant?"
<= /div>

I= n which case, I believe it can be handled as an implementation matter likel= y at the application side.

=C2=A0For some other use cases, managing subscriptions on the se= rver is indeed an option. Horses for courses: -
Ar= e you telling me that pointing out omissions and scope deficiencies is not = welcomed?

Either way 5.4 is completely wrong. You&= #39;ve been told.

Shida

<= blockquote type=3D"cite">
"5.4 Updating = Push Messages" is based on the misconception that "Topics" a= re "Collapse Keys". The standard as proposed has been superseded = by event on the ground by established, successful, and more importantly sca= lable solutions: -

Google Cloud Messaging: -
<= a href=3D"https://developers.google.com/cloud-messaging/topic-messaging" ta= rget=3D"_blank">https://developers.google.com/cloud-messaging/topic-messagi= ng

Azure Notification Hubs: -

Whether the Topics are identified = via HTTP headers or JSON Tokens is the only moot point. What is clear is th= at the proposed protocol attempts to conflate the Topic and Collapse Key fe= atures: -

The fact th= at quintessential Push Notification feature "Broadcasting" has be= en descoped from this protocol must be sufficient to reject the proposal.

Please do not make the same mistake that you made w= ith Geofences. IETF and W3C credibility has already suffered enough.
<= /div>

On Tue, May = 17, 2016 at 2:32 AM, Shida Schubert <shida@ntt-at.com> 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 Cal= l for the webpush protocol.=C2=A0


=
If you have any issues or questions regarding the draft please s= ubmit it to the list, when raising issues please provide constructive resol= ution when possible.

Please acknowledge on the lis= t even when you are content/happy with the status of the draft.=C2=A0
=

The Working Group Last Call will end on June 6th (3 wee= ks).=C2=A0

Shida
As co-chair
=
_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush mailing list
= Webpush@ietf.org<= br>https://www.ietf.org/mailman/listinfo/webpush


__________________________________________= _____
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush

_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
= Webpush@ietf.org<= br>https://www.ietf.org/mailman/listinfo/webpush


__________________________________________= _____
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--001a114076b6eba2b6053428920d-- From nobody Tue May 31 16:26:11 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F7712D690 for ; Tue, 31 May 2016 16:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvgZsbqTiZ9r for ; Tue, 31 May 2016 16:26:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5597D12D123 for ; Tue, 31 May 2016 16:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RCD3pE7RgtduCfCMwU52djTGXqoefVUY65RqdRlBFlo=; b=THFSX3bDv/hz2w5QUWqpqz7hDzZ1Ud0H0TyaFIZReRBp8O7mx0jJP0+tCsexfYNy5J/g7OmblFykeARIkgA/LzKwE8xKwJnOqrpvZRMre6vSl46AelQBROTabS7OlYeqCA2uCjr0W33P9uwybKQQmxKj+T3i+YxtFFRHC6+SZ8A= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Tue, 31 May 2016 23:25:46 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0506.011; Tue, 31 May 2016 23:25:46 +0000 From: Brian Raymor To: jr conlin , "webpush@ietf.org" Thread-Topic: [Webpush] WGLC for draft-ietf-webpush-protocol-05 Thread-Index: AQHRr6Fk6tf8oZhpFkyyBTmIt1UPyZ+8XaSAgArigwCAAA3/gIABIeeAgAoQWICAAP3gAIAARHSA Date: Tue, 31 May 2016 23:25:46 +0000 Message-ID: References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> <4467b402-a69f-fc0e-f699-00ca9f9f14e8@mozilla.com> In-Reply-To: <4467b402-a69f-fc0e-f699-00ca9f9f14e8@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [24.16.23.27] x-ms-office365-filtering-correlation-id: a02657ce-1403-4f22-6adf-08d389aae4ea x-microsoft-exchange-diagnostics: 1; CO2PR03MB2407; 5:4aiBF2VXqQr4Y0546xRVndoAe19UpSSrY38lr4qgOK8ondhXE+3blhmZOIUPYXi1wEIty9EM0JW/sZSl9aDAytLazEATm52dWg+sBPE6CZM2Y+k8TiNWYvqa6ILRsDumyNFhDMzFlWhy8s0F4oF3Uw==; 24:Px+WcFtbLuU8UyO89YR75D/CZcLA1myd+PbEpuK0FHOZbJT45CPZwWVLzVbvSp1MmKYxLOR7tXZblA+kx22LgCcEc5jaPbAUqek1oKtZm7w=; 7:l19u6bxSH0euCqtehVvwUb90w0e5hnwyEn6Sff0n4wh5NwcThC64/HJRX1sxon2s/K8WLa7FZGDY9FUkr3F065TYQpaQKUJVwVpJ4xXbz0D01gKEx9Xw/q28IngNAGMeiHAcP0bB5zsX7JRaPFyEjPNQT9rosqthI0wDa0SQfhx4/W6jdvsnrfT3KGgSmaaMENLaxgP74BRnKicEJWgWHg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2407; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2407; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2407; x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(586003)(3846002)(102836003)(6116002)(86612001)(5002640100001)(11100500001)(76576001)(5004730100002)(99286002)(8936002)(19580395003)(77096005)(19580405001)(93886004)(2900100001)(2501003)(8676002)(2950100001)(122556002)(2906002)(81166006)(66066001)(50986999)(76176999)(54356999)(3280700002)(33656002)(5008740100001)(5001770100001)(5003600100002)(107886002)(92566002)(87936001)(189998001)(86362001)(10290500002)(9686002)(3660700001)(106116001)(5005710100001)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2407; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2016 23:25:46.4573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2407 Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 23:26:10 -0000 On May 31, 2016, at 12:01 PM, JR Conlin wrote: Thanks for your feedback. > There are some aspects of the published spec that are optional and seem a= bit "hand wavey"* (e.g. "subscription sets") How do you feel this could be improved? What details are missing from your = perspective? > I believe that the recommendation for expired or removed push subscriptio= n 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 wer= e consistent.=20 Good catch. 7.3.1 should be 404 and not 410. 410 (Gone) is returned when a push service decides to cease delivery attemp= ts before the TTL expires. 404 (Not Found) is returned when a push services expires a subscription or = set. From nobody Tue May 31 16:50:45 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5079112D8F8 for ; Tue, 31 May 2016 16:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDajMFhsVUvF for ; Tue, 31 May 2016 16:50:41 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D2312D0BE for ; Tue, 31 May 2016 16:50:40 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id j1so3620178oih.3 for ; Tue, 31 May 2016 16:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=DtKc65C7pqHJBlqF/CK/Qb9BgbOvMDd4NDUVj2ZC3EU=; b=GOj3jZ4ddK2YueMwiWxcuj0W40hPfcNaQp48WtXsbYYaouX4j5JRC0WU53p+8mhOBj jR4vu5oo0ZPskDoIKdRKBFRa+7Q8igOMTX4hyrPoQwNCDx2ip2n4ZfoXiqltbAA7cAuy eIdvz5X5kID/rjH4q/QZhiZPNu5A3l4YvEE1tItlY16IBVos4K7eOI16uRwi4VrQZJ+Z W6JoikN2vHb2TGnJqHQglufFPzcNCYNHifrwPYi0W0uhEsBR/tapwMegSEelSjS+u4jl 6GVOdNPkfTrKbjCuQgnsig1a6NjgZpbOMFLVScWaKtPT1kY04n14fOPrZvB9xgKNyHiP 4K1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=DtKc65C7pqHJBlqF/CK/Qb9BgbOvMDd4NDUVj2ZC3EU=; b=YqTz3k7nLb+NME4HTVnS7k5EiGV5s4+Keqk6kIAYzXhfFT8BxFO3bVfE//gWOMKTFU 0nBfhFMKomm+HvhFBKr2dze9VpZmo4eRRabY6Iut4tshATQD+OlszsyxFH6he3JRHdAI cZidLnc8CL7YDDYb22sZp0zVu5pqmAxkKLYC7+lZAQIbO8SFML4bSsiEkRwuyMOfN6sD 4StVvBAqAbNusKchy3kQytJ/ypsjAlAsSYz8UwAVS5PNloGgl84Zfx9oG/0qYGq1BotU 6vNPJTIPkNNruneIqymY8JUn45a4Uc0DPwTpJAzdh7ksRMYZI040ZV/O6p1hOEwX3C5X qLtQ== X-Gm-Message-State: ALyK8tKJBhuomFhs1ZPNkmJ69hGOjJW3figYW6x7/Nzli+ufn5uFKOyBPoIkDkV8AIjiy8oruBGjQE1C4kaRpmxK MIME-Version: 1.0 X-Received: by 10.202.98.133 with SMTP id w127mr19289458oib.136.1464738640071; Tue, 31 May 2016 16:50:40 -0700 (PDT) Received: by 10.202.212.213 with HTTP; Tue, 31 May 2016 16:50:39 -0700 (PDT) Received: by 10.202.212.213 with HTTP; Tue, 31 May 2016 16:50:39 -0700 (PDT) In-Reply-To: References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> <4467b402-a69f-fc0e-f699-00ca9f9f14e8@mozilla.com> Date: Tue, 31 May 2016 16:50:39 -0700 Message-ID: From: JR Conlin To: Brian Raymor Content-Type: multipart/alternative; boundary=001a113d356454af3805342c0a12 Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jrconlin@mozilla.com List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 23:50:44 -0000 --001a113d356454af3805342c0a12 Content-Type: text/plain; charset=UTF-8 I noted my opinion in the follow up. Basically, while the spec goes into great detail about other aspects of the protocol, sets are left mostly as "they may exist", and "it's up to the PS and UA". I will also admit that I was initially confused because I hadn't noticed it was only between UA and PS, but a second read caught that. I am fine as is, because I don't think that outside groups will be impacted by my concern, nor do I believe that they would fail to implement a solution if they misunderstood it. On May 31, 2016 4:25 PM, "Brian Raymor" wrote: > > On May 31, 2016, at 12:01 PM, JR Conlin wrote: > > Thanks for your feedback. > > > There are some aspects of the published spec that are optional and seem > a bit "hand wavey"* (e.g. "subscription sets") > > How do you feel this could be improved? What details are missing from your > perspective? > > > 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. > > Good catch. > 7.3.1 should be 404 and not 410. > 410 (Gone) is returned when a push service decides to cease delivery > attempts before the TTL expires. > 404 (Not Found) is returned when a push services expires a subscription or > set. > > > > > > > --001a113d356454af3805342c0a12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I noted my opinion in the follow up. Basically, while the sp= ec goes into great detail about other aspects of the protocol, sets are lef= t mostly as "they may exist", and "it's up to the PS and= UA".=C2=A0 I will also admit that I was initially confused because I = hadn't noticed it was only between UA and PS, but a second read caught = that.

I am fine as is, because I don't think that outside grou= ps will be impacted by my concern, nor do I believe that they would fail to= implement a solution if they misunderstood it.

On May 31, 2016 4:25 PM, "Brian Raymor"= ; <Brian.Raymor@microsoft.= com> wrote:
<= br> On May 31, 2016, at 12:01 PM, JR Conlin <jconlin@mozilla.com> wrote:

Thanks for your feedback.

> There are some aspects of the published spec that are optional and see= m a bit "hand wavey"* (e.g. "subscription sets")

How do you feel this could be improved? What details are missing from your = perspective?

> I believe that the recommendation for expired or removed push subscrip= tion 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.

Good catch.
7.3.1 should be 404 and not 410.
410 (Gone) is returned when a push service decides to cease delivery attemp= ts before the TTL expires.
404 (Not Found) is returned when a push services expires a subscription or = set.






--001a113d356454af3805342c0a12-- From nobody Tue May 31 18:36:27 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565D812D134 for ; Tue, 31 May 2016 18:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTj_IJxCjetY for ; Tue, 31 May 2016 18:36:24 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68F212D0A1 for ; Tue, 31 May 2016 18:36:23 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id q45so32966qtq.1 for ; Tue, 31 May 2016 18:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Zu9VIVJQK6/BoGrDlkigKCwHg+viTx4BSKi9CV9ql+0=; b=x2fQRhtTGHeQckAvXJPYnE/2CGY6/Q28HJ0dU6CNTPXvoeVpEiXJcU2kIHhJ68uTkN ccnqkz4uqp0wtqFkRa6dUbrDnIk7mq0Ry9I93gdbH94Tt1ZM0VFXJ3JJogHdfCbSbo5y uFTOF+XOw2+grYRS/sre6Jx6ZHdDGd50s6Bx4wuOsXRxFM7519agczL5ox8fLbnoWVvg 6/hs9sIzVLo9enQrp8Zw+0rOiFwo2A/KfyS3o2O4E4n9Q027O21gxXK/NZjEWvwHbPEL SzT3PxfIcGg4v7buT9b5bP7qcOYCToPphDKs+YR9SDxMpJPB4GM+WR4JM6p+bnEVXX83 Nn6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Zu9VIVJQK6/BoGrDlkigKCwHg+viTx4BSKi9CV9ql+0=; b=ZoXK4FcElZJyBtREsvJK+3bTSBwzqCyYnHGIa0M6uFmb6rX4MA03aqLloURrPAxXmq bhggIJrPuG8YTYpJTJ61w7qHWLQ2qN6v0DxxEqASCJwQVvMrm6U6a49tb7yUVF00Ifiv 7Slwh3cugil+jOWLVfVXMjLP+S6t/Ba9Uip6MQorrhQL5OWRVhwm7AIEDuIDKQDkmnzp u2nevUPzP9mdRbCVd5WrkQDkXpBqU6AyMX9KcEAOJDWVLgezzulzOQ9mj9EJpm5DYfQi 1WH30U45HCtgXmCpltRkMMgaSTKd0BxfNTHSXcWPWPERRCjCHdAi/avr+HM8PupQS76K Ya1A== X-Gm-Message-State: ALyK8tKtoWRNNdDyIj9x72KYeBu9tZWRocHk9HRuhFgFi42bKH6AIz+H+QdvO1reYeVDyP7MY4QKCwP0q1JSrQ== MIME-Version: 1.0 X-Received: by 10.200.42.249 with SMTP id c54mr1107259qta.6.1464744982757; Tue, 31 May 2016 18:36:22 -0700 (PDT) Received: by 10.55.104.194 with HTTP; Tue, 31 May 2016 18:36:22 -0700 (PDT) In-Reply-To: References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> <4467b402-a69f-fc0e-f699-00ca9f9f14e8@mozilla.com> Date: Wed, 1 Jun 2016 09:36:22 +0800 Message-ID: From: Richard Maher To: jrconlin@mozilla.com Content-Type: multipart/alternative; boundary=001a11406bec624b8605342d8452 Archived-At: Cc: Brian Raymor , webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 01:36:26 -0000 --001a11406bec624b8605342d8452 Content-Type: text/plain; charset=UTF-8 So with the WGLC drawing to a close, I make that a whole 3 people, excluding the authors, with anything positive to say about this draft standard. Does that not tell you something? Or is "3" what passes for quorum with you people? Do you lot get paid per specification? Number of pages? Or do you actually get tasked with delivering a spec that industry-standard, feature-rich, and scalable solutions can be built upon? Or perhaps "Just describe whatever Autopush does"? Disbelief. On Wed, Jun 1, 2016 at 7:50 AM, JR Conlin wrote: > I noted my opinion in the follow up. Basically, while the spec goes into > great detail about other aspects of the protocol, sets are left mostly as > "they may exist", and "it's up to the PS and UA". I will also admit that I > was initially confused because I hadn't noticed it was only between UA and > PS, but a second read caught that. > > I am fine as is, because I don't think that outside groups will be > impacted by my concern, nor do I believe that they would fail to implement > a solution if they misunderstood it. > On May 31, 2016 4:25 PM, "Brian Raymor" > wrote: > >> >> On May 31, 2016, at 12:01 PM, JR Conlin wrote: >> >> Thanks for your feedback. >> >> > There are some aspects of the published spec that are optional and seem >> a bit "hand wavey"* (e.g. "subscription sets") >> >> How do you feel this could be improved? What details are missing from >> your perspective? >> >> > 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. >> >> Good catch. >> 7.3.1 should be 404 and not 410. >> 410 (Gone) is returned when a push service decides to cease delivery >> attempts before the TTL expires. >> 404 (Not Found) is returned when a push services expires a subscription >> or set. >> >> >> >> >> >> >> > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a11406bec624b8605342d8452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So with the WGLC drawing = to a close, I make that a whole 3 people, excluding the authors, with anyth= ing positive to say about this draft standard. Does that not tell you somet= hing? Or is "3" what passes for quorum with you people?
Do y= ou lot get paid per specification? Number of pages? Or do you actually get = tasked with delivering a spec that industry-standard, feature-rich, and sca= lable=C2=A0solutions=C2=A0can be built upon? Or perhaps "Just describe w= hatever Autopush does"?
Disbelief.

On Wed, Jun 1, 2016 at 7:50 AM= , JR Conlin <jconlin@mozilla.com> wrote:

I noted my opinion in the follow up. Basica= lly, while the spec goes into great detail about other aspects of the proto= col, sets are left mostly as "they may exist", and "it's= up to the PS and UA".=C2=A0 I will also admit that I was initially co= nfused because I hadn't noticed it was only between UA and PS, but a se= cond read caught that.

I am fine as is, because I don't think that outside grou= ps will be impacted by my concern, nor do I believe that they would fail to= implement a solution if they misunderstood it.

On May 31, 2016 4:25 PM, "Brian Raymor"= ; <Brian= .Raymor@microsoft.com> wrote:

On May 31, 2016, at 12:01 PM, JR Conlin <jconlin@mozilla.com> wrote:

Thanks for your feedback.

> There are some aspects of the published spec that are optional and see= m a bit "hand wavey"* (e.g. "subscription sets")

 How do you feel this could be improved? What details are missing from your = perspective?

> I believe that the recommendation for expired or removed push subscrip= tion 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.

 Good catch.
7.3.1 should be 404 and not 410.
410 (Gone) is returned when a push service decides to cease delivery attemp= ts before the TTL expires.
404 (Not Found) is returned when a push services expires a subscription or = set.







_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--001a11406bec624b8605342d8452-- From nobody Tue May 31 19:49:09 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91F412D932 for ; Tue, 31 May 2016 19:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZMMGAZJ0LVB for ; Tue, 31 May 2016 19:49:05 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6446412B02B for ; Tue, 31 May 2016 19:49:05 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id c140so4454014qke.2 for ; Tue, 31 May 2016 19:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=doEMYT9RaewmLDds3YzzVdKviYOgeoKhTI524v5ZELk=; b=vD3zQDaDhVwfwH7evinnY7f38FQzzUKbPA5Mu0djqhF8uJyPUldxBIjtSG8lzHrOJY ubX3uO6/mIvDuLtp7jdjIgGyEhkcCNOLhtBu7l8CRL63UY0jpXp1zGroM9A/ZBn3N2OE Pyrej3tUjV7EiuQnS2YzE2hExbKgWDiGBNC4CA63ITCSII8DUJp2LEE9uHtj6dihSiku 8M8/9yZKWZScqmZ5pSGOnKmC8VXkuM8+BCZOfxM/P7MU2Ku5JtobKNKE7jhS1+AIcOL3 YB3hYOUt/oY0YJcBI1KgXgtd74C8cppjUJu/NAufOYNMepVluvkMH97SMcDK+QGIR6k+ ZdBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=doEMYT9RaewmLDds3YzzVdKviYOgeoKhTI524v5ZELk=; b=VgX1vmfyklxAI7wY2NCw7xNkCkIcBoNa8FO7NA12XEAwENAmzyWotBzmVTNXvrWB6z tK1RIWgw84ftOGeMXp5e4p5XJdccALWWHba2zUG7nSLeC1lgBh9jbk3L/j/8bgPXTzE4 H+wAy3AZCX04EOG44hk0T6HEfn7wWG6BpBZ+IXeit7hu+CEjzoKzIsNN+PgVNoPGcz9Q HTw7IKyK4tt3379jpyiCOgkvNEpwNaHouFqTsPSq7HDRxV+zoOdS0p3oj6x8x5x7tPzN eG63enlIY2OPfxirCSd5ghKD6hV1HbHdLaUOiEg++tsXbEj+RdE5qeTWZhk0IvuD64IL by8Q== X-Gm-Message-State: ALyK8tI14zF4DVp1epgkLCu3n4j6OEFLgJn4Jadb06BP7HGbpml3ShnIquUFWy3mIAK2K4cCMxIBlap67JRqZA== MIME-Version: 1.0 X-Received: by 10.55.138.194 with SMTP id m185mr36199199qkd.48.1464749344465; Tue, 31 May 2016 19:49:04 -0700 (PDT) Received: by 10.140.104.110 with HTTP; Tue, 31 May 2016 19:49:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2016 12:49:04 +1000 Message-ID: From: Martin Thomson To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 02:49:08 -0000 On 1 June 2016 at 05:40, Peter Beverloo wrote: > Hi Martin, Brian, Elio, > > As an implementer I can only express my gratitude for the fantastic > creating and editing of the standard you have done - thank you *so* much! > > I have a few last-minute comments, none of which have to be blocking for > the WGLC. I'll acknowledge agreement in Shida's thread momentarily. > > 1) Page 11, "A push message with zero TTL...push messages." > > This section is very loose in defining whether or not delivery receipts > should be send for messages with TTL 0. In effect, behaviour of the Web > Push services out there today may strong-arm future services by > establishing developer expectations. > > Have we considered not sending receipts for messages with TTL=0 at all? I'd be OK with that. It certainly reduces the cost of TTL=0, which I think is useful. PR: https://github.com/webpush-wg/webpush-protocol/pull/91 > 2) Page 21, "this can be signaled by returning a 400-series status > code, such as 410 (Gone)." > > This is the only ambiguous status code reference in the standard. What is > the reason for not settling on 404 or 410? > > The example of 410 for expiring subscriptions here is different from the > 404 mentioned in 7.1 (Page 20), it would be good to make that consistent. Yes, let's just settle on a single value. PR: https://github.com/webpush-wg/webpush-protocol/pull/92 > I also have a few editorial comments: PR: https://github.com/webpush-wg/webpush-protocol/pull/90 Commits in brackets below. > - Page 3, "Requesting the delivery of events is particularly important > for the W3C Push API." > > It is not explained why it is particularly important. Is this assumed > knowledge of the reader? I would suggest the following addition: > > "...for the W3C Push API as the developer may have to request push message > delivery from any number of push services." [0bf550e] "A standardized method of event delivery is particularly important for the W3C Push API, where application servers might need to use multiple push services." > - Page 4, definition of "application server" > > Nothing precludes an application from not needing a server side at all. I > don't think we should change the term, but perhaps we can consider > slightly rephrasing the definition as: > > "The component of an application that *usually* runs on a server and > requests the delivery of a push message." [e022200] > - Page 7, "Confidentiality protection and application server > authentication MUST be used to ensure that this URI is not disclosed > to unauthorized recipients (Section 8.3)." > > Is it appropriate for the standard to dictate a MUST here when the > distribution method is defined to be application-specific? (I do agree > with the premise.) There are no implications for interoperability, but there are for security. We do that sort of dodgy MUST-ing all the time when it comes to securing protocols. Even when it has interoperability penalties. (See RFC 7568, which says "SSLv3 MUST NOT be used.") > - Page 7, "[subscription sets] can represent a significant efficiency > improvement for a push service." > > There are significant improvements for many types of user agents as well, > so I would suggest rephrasing as "... improvements for push services and > user agents." [90307f9] > - Page 8, "The push message is included in the body of the request." > > While covered by Section 8.1 in the Operational Considerations, given the > strong focus on security and privacy considerations throughout the rest > of the standard I think it would be appropriate to mention the strong > preference for encryption here? [ee8ca46] "The ciphertext of the push message is included in the body of the request." Yes, there are cases where this won't be true because confidentiality and integrity are provided by other means, but those people can just say that they are using the double-rot13 cipher. > > - Page 11, page 13: s/acknowledgement receipts/delivery receipts/. [51ae2d0] > - Page 12, 13: Both "update" and "replace" are used to describe the > same operation. I don't think that consistently using "replace" > would change the meaning of this section- could we? [884fc85] That's a fairly big change. > One final thing that I'm on the fence about is that the push service MUST > NOT forward the Urgency value to the user agent. I can see uses, but also > concerns in the scenario of a compromised or malicious push service. Is > this the reason behind the strong language? The general rule that I've followed here is that anything that could be from an application server needs to be authenticated when it is sent to the user agent. Anything else is clearly from the push service and can be discarded. Maybe that's excessive paranoia and I've been spending too much time with cryptographers lately. If the information is important it can't be included in the payload. From nobody Tue May 31 20:43:09 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2E12D0E0 for ; Tue, 31 May 2016 20:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRRf5YzjZUJ5 for ; Tue, 31 May 2016 20:43:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB66712D0BD for ; Tue, 31 May 2016 20:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u/gqNWVhv0n37CaywY+nAx69k5WEC5VRydyzO3ZcYRA=; b=COhW6IwDNjV7rUbOC54Bcj5wqD7laz5WmlWvTRsLOyhrukvrjiwUD2DqWMXEZugt7bofTtBhQ/UFh63zp9O5ODzIg1e1aq3DYNbylA3eEg3XIOUke/N9PG2RLTlrJHeW97b0uj0iCzRmZhDNw1hUxSbkoQX8GajAg9oNfQtTybs= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2405.namprd03.prod.outlook.com (10.166.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Wed, 1 Jun 2016 03:42:44 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0506.011; Wed, 1 Jun 2016 03:42:44 +0000 From: Brian Raymor To: Martin Thomson , Peter Beverloo Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RQwDJq8LaJ6EaFkMQ0Dd4KCZ/T6WgAgAAK9+A= Date: Wed, 1 Jun 2016 03:42:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [24.16.23.27] x-ms-office365-filtering-correlation-id: 25d6ff03-4342-43bf-399b-08d389cecab3 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2405; 5:Yl+4XH1jOi/CZHmHfvvjAbptIR0I3+HnbTK+xo1267kW+6xzNVnng8p1hdVfQdMw2CUYD/t4yy+CBxOlqcwCuXn3IQjiQnniRQiNkMGLPZBUZNPozMW2a/EOf4OD0qOeND1QF66vo5Gxv2qDtEHN4g==; 24:rsqP1HgrkEXuhz2MokVkWB2gKmWos98WfXGcc2gGzTvZES+7SZXA0RCzw6ZDLomfPKJu7ZqpRy0ZbXLOdp69mte5PVGg9FHwrnIV5Ngqt3w=; 7:riNsii/zQ1P7HrKsZx36Ive655GsEQyphLoTbhHLVY8tXnzqWWl5YC2mNGYTdIuyvdeKNwmrXcnQnyUGoeJbvhOPFLXc+X4/BdoTd2pOQNXOlFSOx911ncoIrvpQHD8ObEP+YFC8A0ZaG0zTRVGaQM2z05l7NA2mYRhtKtWlTJbIbduZHshQH+jX6tsma38yUxwE2E6ss22sIqQ2SJiFag== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2405; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2405; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2405; x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(11100500001)(10090500001)(19580395003)(5002640100001)(122556002)(86612001)(189998001)(2950100001)(87936001)(5005710100001)(86362001)(99286002)(92566002)(19580405001)(5004730100002)(5001770100001)(10400500002)(5003600100002)(8676002)(10290500002)(106116001)(81166006)(8936002)(15975445007)(77096005)(3660700001)(33656002)(54356999)(102836003)(50986999)(66066001)(3280700002)(76176999)(6116002)(4326007)(3846002)(9686002)(2906002)(2900100001)(74316001)(586003)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2405; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2016 03:42:44.5602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2405 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 03:43:09 -0000 On May 31, 2016, at 12:40 PM, Peter Beverloo asked: > Have we considered not sending receipts for messages with TTL=3D0 at all? There was some early discussion in https://github.com/webpush-wg/webpush-pr= otocol/issues/24. There were no major objections at the time. It just felt odd to have a spec= ial case for TTL=3D0 in comparison to TTL=3D1.